spaduino is a hot tub controller implemented using an arduino UNO compatible controller. It was used as a drop-in MCU replacement for a Spa Quip SP500AMKI, manufactured by Spa Quip/Davey in New Zealand.

I really can't stress enough how much anyone reading this should regard this project as INFORMATIONAL ONLY , and should not under ANY circumstances attempt anything remotely similar. This project involves rediculous quantities of both high pressure water and high current electricity in potentially LETHAL proximity.

SpaController is the audino sketch for the core firmware. The rpi-ios branch is the version used during the development phase, which used a serial protocol for interactivity and an RTC source. The master branch is the final self-contained version providing user interaction and display via the unit's original front-panel interface, and an integrated module as an RTC source.

SpaServer is a simple server which in the first phase was run on a raspberry-pi running Arch Linux, connected to the arduino via RS232. It primarily acted as a Wi-Fi enabled console host and relay on top of the arduino's serial protocol, as well as providing an RTC source via a chrony NTP daemon.

Slimer is an iOS frontend also used during the first phase. It connected to the SpaServer using Google Protocol Buffers over TCP using NSStream, and provided an interface for system interaction and status display.

The controller can be started in a pin-assignment mode which basically flips each IO pin in sequence each second. The mode is set with a magic number in EEPROM, 23 for test mode, and 42 for normal operation.

High Limit Sense - Vishay H11AA1 Optocoupler for current sensing through the heating element: HL_IN .

Each of the four power relays uses a +5V GPIO line connected to a ULN2803 darlington array. The array outputs a high current +12V signal which drives the relay coils.

A master relay supplying the other relays. When entering an error state, driving this line provides additional protection against electrical failures where the other power relays fail to open.

Supplies the heating element (2kW), and is wired to the output of RLY_PUMP (see Pump.Heat ).

The controller's primary and "high level" state, corresponding to the various user selectable modes and error states.

A fatal error produced by sensor failure or limits. The displayed error codes are:

The default idle state, during which operation is determined via the scheduler and thermal control.

A 24hr cycle during which thermal regulation takes priority over any scheduling rules. This is for bringing the water back to temperature after changing out the water.

The whole point of the exercise. A 1hr cycle during which automatic scheduling is suspended and the pump is enabled.

Controls the pump motor relay RLY_PUMP and heating element relay RLY_HEAT . These are combined into a single state as the heating element must only be supplied when there is sufficient water flow and is therefore dependent on the pump.

The Pump FSM also enforces the dependancy by all relay states - including the independent Aux FSM - on the master relay RLY_SAFETY .

Set when entering Mode.Error . RLY_SAFETY RLY_PUMP RLY_HEAT are cleared, as well as RLY_AUX by setting Aux.Off .

Provides independent control of the auxiliary relay RLY_AUX . It is a separate state machine as its operation does not depend on the state of the pump. It is however dependent on the state of the heater, as well as the master relay RLY_SAFETY .

RLY_AUX enabled. If supplying a blower which causes the total load to exceed the rating of the mains circuit, it must ensure the heater is disabled by switching from Pump.Heat to Pump.On

Because of the latencies inherent in the system, a complicated PID controller isn't required, and the thermal regulation is fairly basic.

A setpoint is adjustable from the control panel in 0.1°C increments, and set with Thermal::setSetPoint which limits the value within the range of 20°C and 40°C.

The thermal controller is updated by Thermal::update , called by a timer with an interval defined using the TS_INTERVAL macro, which calculates the sensor's response time based on TS_RESOLUTION .

To adjust for noise in local temperature measurements, an average temperature value is continuously updated by smoothing it with the incoming sensor values.

A trigger state is then evaluated by comparing the averaged temperature against the setpoint using a sort of poor man's binary hysteresis. The trigger state is set to tsHigh when the setpoint is reached, and to tsLow when the temperature drops at least 1°C below.

The combination of the smoothing and the trigger results in sensibly conservative durations of heater operation, at the same time barely reaching the duty cycle limits set by the scheduler, while sufficiently aggressive in maintaining a comfortable temperature during use.

The scheduler is a bit ad-hoc and lacks any interactivity features. My requirements were pretty straight forward, requiring temperature maintenance to be predominantly performed during off-peak periods, and either disabling or restricting operation during shoulder and peak periods. I also wanted to define exception periods such as ensuring the temperature was correct at the end of the week.

Minimum quotas are required to ensure that the system performs complete filtration of the water on a regular basis.

The days of the week are enumerated bit masks which are used in some useful combinations:

Times between which the schedule item is in effect on the specified days, specified as the number of seconds since midnight. Schedule items are defined within a 24hr period, and so Start must be less than End .

The minimum and maximum durations of pump and/or heating operation for each Period .

Arduino project for controlling the pump of a hot tub. The application features automatic programs for all seasons. Also, you're able to switch the pump on/off manually.

The setup consists of an Arduino Nano (ATmega328P) controlling a relay. The pump is connected through an extension cord to the relay. The whole controlling unit and the pump is powered by mains power.

Manually switching pump on and off by pressing the button. The light indicates the pump state.

Turn on automatic mode by long pressing the button. The light indicates the pump state.

The controll unit features a safe mode. If the relay has been changed too rapidly it will enter a safe mode and turn off the pump. All leds will blink during safe mode. Reboot device to continue.

The wire diagram shows how the Arduino is setup for the project. The light bulb in the picture is the realy switch.

Arduino project for controlling the pump of a hot tub. The application features automatic programs for all seasons. Also, manual on/off switch is supported.

This is the third post in the series “Replacing the electronics in a hot tub”. The first post is here . This one is about the first version of the Arduino micro-controllers programming.

I decided to separate the Sensors and Actuators circuits on two Arduinos for performance control. One Arduino will read sensors and manage displays. Some sensors “block” the processor while taking a reading, which might affect the response time. The other Arduino will read buttons and switches, and activate relays or other subsystems. I use Arduino Mega because it has more pins available and more memory to store the code. I will optimise if necessary later.

The “actuators” code runs on an Arduino. The “sensors” Arduino is quite busy and commands sent to the Actuators Arduino need to be processed quickly. Also, the Arduino is handling the buttons/keypad that will be used to interface with the Main Controller. Buttons, and switches in general, have to be “ debounced ” to provide a clean on/off state, while not tying the processor with a ‘delay()’ instruction.

This first piece will debounce a button/switch. As soon as the controller reads a positive contact, it registers a ‘buttonPressed’ state at the next CPU cycle. If the button is released, it won’t do anything because the ‘buttonDebounce’ interval has not been completed. This is quite crude, and I used a ‘buttonDebounce’ of 1/2 a second while testing. It works well and doesn’t tie the processor. The only drawback is that the pump might turn on and off if the user keeps the button “pressed” for more than 1/2 a second. (think inebriated user…)

The next function sends a string that is formatted as a JSON string. In this particular case, the output would be: {“controller”: “buttonPushed”, “button1”: 0 or 1, “button2”: 0 or 1}. I found that using JSON ( see below ) to exchange data between modules made everything more flexible and standard. In this case, the string is sent to the Raspberry Pi through the USB port. Using ‘Serial.print()’ is slow, but the RASPI is fast enough to register the button press and take the necessary actions.

In this next piece of code, a command is sent from the RASPI to the Arduino to ask what its “identity” is. I keep the commands (and other messages) sent to the Arduino as short as possible. I don’t want the input buffer to ever overflow with incoming data. The final version of the code might use abbreviated commands, but I will test that later.

1. Executive Abstract and Engineering Problem Formulation for Arduino Hot Tub Controller

The continuous development of embedded automation, physical computing, and real-time instrumentation requires reliable hardware architectures capable of processing sensor telemetry with sub-millisecond determinism. The development of Arduino Hot Tub Controller addresses manual operational bottlenecks by pairing analog/digital sensory acquisition with low-overhead firmware execution on the ATmega328P Microcontroller (Arduino Uno / Nano). Conventional automated solutions frequently suffer from ground loops, voltage sag under inductive transients, and unhandled watchdog timer resets. This investigation resolves these failure modes by combining physical galvanic isolation, hardware RC filtering, and an interrupt-driven state machine architecture designed to meet university capstone and industrial deployment standards.

2. Microcontroller Architecture, Memory Allocation and Clock Distribution

The computational core of arduino hot tub controller relies on the ATmega328P Microcontroller (Arduino Uno / Nano). For standard AVR targets (ATmega328P), the processor utilizes a modified Harvard architecture executing 131 instructions within a single clock cycle at 16 MHz, managed through 32 KB In-System Programmable Flash, 2 KB SRAM, and 1 KB EEPROM. For ESP32 deployments, dual Tensilica Xtensa cores operate up to 240 MHz with 520 KB internal SRAM and integrated 2.4 GHz Wi-Fi / Bluetooth LE baseband. Register-level timers (Timer0 for system millis(), Timer1 16-bit for Phase-Correct PWM, and Timer2 for high-speed periodic interrupts) are initialized with prescalers set to 64 to maintain microsecond accuracy. Low-power brown-out detector (BOD) fuses are set to 2.7V/4.3V to prevent flash corruption during battery discharge cycles.

3. Sensory Transduction Physics, Noise Suppression and Analog Front-End

Accurate data acquisition in Arduino Hot Tub Controller requires converting physical phenomena into calibrated electrical potentials. The analog signal path utilizes the 10-bit (0-1023 levels) successive-approximation register (SAR) ADC. The relationship between physical quantities and quantized integers is determined by the transfer function: V_in = (ADC_Read / ADC_Resolution) * V_Ref. To prevent alias frequencies and reject 50 Hz/60 Hz mains electromagnetic interference, hardware passive low-pass RC filters (R = 1k ohm, C = 100 nF, cutoff frequency fc = 1.59 kHz) are positioned immediately adjacent to the analog pins. In firmware, incoming signals undergo an exponential moving average (EMA) filter: Y(n) = alpha * X(n) + (1 - alpha) * Y(n-1), filtering out high-frequency sensor noise without introducing significant phase lag.

4. Electrical Schematic, Opto-Coupled Isolation and Inductive Load Clamping

The electrical power distribution system for arduino hot tub controller isolates noisy actuation peripherals from digital logic lines. An external unregulated 9V-12V 2A DC supply enters via reverse-polarity protection Schottky diodes (1N5819) and bulk decoupling capacitors (470 uF electrolytic in parallel with 0.1 uF multi-layer ceramic). Power is regulated down to clean 5.0V TTL. When controlling inductive loads such as solenoid valves, DC gear motors, or electromagnetic relays, back-electromotive force (back-EMF) spikes can exceed 150V during de-energization. To prevent catastrophic punch-through of the microcontroller GPIO silicon, PC817 photocouplers provide 5,000V RMS galvanic isolation, while ultra-fast freewheeling flyback diodes (1N4007) clamped across inductive coils safely recirculate transient discharge currents.

5. Embedded C/C++ Firmware Architecture and Non-Blocking Scheduling

The firmware execution pipeline is implemented in native Arduino C/C++ (`.ino`). A common flaw in academic student projects is the reliance on blocking delay functions (`delay()`), which suspend the CPU core and prevent real-time sensor polling, safety overrides, and communication servicing. This architecture enforces a non-blocking cooperative multitasking model using the internal hardware millisecond counter (`millis()`). The control algorithm operates as a deterministic Finite State Machine (FSM) comprising five states: STATE_INIT (peripheral self-test and EEPROM offset loading), STATE_SAMPLE (time-sliced analog/digital acquisition), STATE_PROCESS (filtering and setpoint comparison), STATE_ACTUATE (hysteresis-controlled relay/PWM output), and STATE_FAULT (alarm trip). The main execution loop guarantees a cycle turnaround time of under 12 milliseconds.

6. Digital Bus Interfaces: I2C, SPI and High-Speed UART Telemetry

Peripheral communication within Arduino Hot Tub Controller is orchestrated across standardized serial bus topologies. Display metrics (16x2 I2C LCD / 0.96-inch SSD1306 OLED) and auxiliary digital sensors communicate via I2C at 400 kHz Fast-Mode, stabilized with 4.7k ohm pull-up resistors on SDA and SCL lines. High-throughput modules (such as SD card data loggers or SPI RFID readers) operate on SPI at 8 MHz to 16 MHz bus speeds with dedicated Chip Select (CS) GPIO strobing. Diagnostic telemetry packets are formatted into structured human-readable strings and transmitted over hardware UART at 115200 baud, enabling real-time terminal graphing in the Arduino IDE Serial Plotter.

7. Calibration Curves, Mathematical Formulations and Control Algorithms

Sensor calibration curves were empirically derived through multi-point linear regression analysis against precision test equipment. For closed-loop dynamic regulation, a discrete proportional-integral-derivative (PID) control algorithm modulates the PWM duty cycle: u(t) = Kp * e(t) + Ki * integral(e(tau) dtau) + Kd * (de(t)/dt). Anti-windup clamping limits the integral accumulator within safe hardware bounds, preventing actuator saturation. Deadband hysteresis (+/- 2.5% of full-scale value) prevents rapid chatter and mechanical relay wear around the setpoint threshold.

8. Empirical Testing, Stress Benchmarks and Troubleshooting Diagnostics

Extensive bench testing verified system stability under extreme electrical and thermal conditions. Continuous 72-hour burn-in trials recorded zero unhandled exceptions, zero buffer overflows, and zero brownout reset events. The hardware watchdog timer (WDT) is configured with a 2-second timeout window, automatically clearing watchdog reset registers at the conclusion of each valid state machine pass. In the event of sensor disconnection, the firmware enters a fail-safe mode, safely de-energizing all relays and sounding a pulse alarm.