The code supports the Atmega2560 microcontroller (eg. Arduino Mega2560 or CONTROLLINO MAXI boards) and it was ported to the ESP32 platform by @Gixy31

Four main metrics are measured and periodically reported over MQTT and a 3.5" Nextion touch screen: water temperature and pressure, pH and ORP values. Pumps states, tank-levels estimates and other parameters are also periodically reported Two PID regulation loops are running in parallel: one for PH, one for ORP An additional simple (on/off) regulation loop is handling the water temperature (it starts/stops the house-heating system circulator which brings heat to a heat exchanger mounted on the pool water pipes) pH is regulated by injecting Acid from a tank into the pool water (a relay starts/stops the Acid peristaltic pump) ORP is regulated by injecting Chlorine from a tank into the pool water (a relay starts/stops the Chlorine peristaltic pump) Defined time-slots and water temperature are used to start/stop the filtration pump for a daily given amount of time (a relay starts/stops the filtration pump) Tank-levels are estimated based on the running-time and flow-rate of each pump. Ethernet connectivity parameters can be set through a webpage accessible from the LAN at http://PoolMaster.local . If an ethernet connection is available, the internal clock (RTC) is synchronized with a time-server every day at midnight.

An API function enables telling the system what the outside air temperature is. In case it is below -2.0°C, filtration is started until it rises back above +2.0°C Communication with the system is performed using the MQTT protocol over an Ethernet connection to the local network/MQTT broker.

Every 30 seconds (by default), the system will publish on the "PoolTopicMeas1" and "PoolTopicMeas2"(see in code below) the following payloads in Json format: {"Tmp":818,"pH":321,"PSI":56,"Orp":583,"FilUpT":8995,"PhUpT":0,"ChlUpT":0} {"AcidF":100,"ChlF":100,"IO":11,"IO2":0} Tmp: measured Water temperature value in °C x100 (8.18°C in the above example payload) pH: measured pH value x100 (3.21 in the above example payload) Orp: measured Orp (aka Redox) value in mV (583mV in the above example payload) PSI: measured Water pressure value in bar x100 (0.56bar in the above example payload) FiltUpT: current running time of Filtration pump in seconds (reset every 24h. 8995secs in the above example payload) PhUpT: current running time of Ph pump in seconds (reset every 24h. 0secs in the above example payload) ChlUpT: current running time of Chl pump in seconds (reset every 24h. 0secs in the above example payload) AcidF: percentage fill estimate of acid tank ("pHTank" command must have been called when a new acid tank was set in place in order to have accurate value) ChlF: percentage fill estimate of Chlorine tank ("ChlTank" command must have been called when a new Chlorine tank was set in place in order to have accurate value) IO: a variable of type BYTE where each individual bit is the state of a digital input on the Arduino. These are :

- this code was developped for two main hardware configurations (see list in the hardware section below):

Notes: a/ the ORP sensor should theoretically not be calibrated nore temperature compensated (by nature its 0mV pivot point cannot shift) b/ the ORP reading is strongly affected by the pH value and the water temperature. Make sure pH is adjusted at 7.4 c/ prefer platinium ORP probes for setpoints >500mV (ie. Pools and spas) e/ the response time of ORP sensors can be fast in reference buffer solutions (10 secs) and yet very slow in pool water (minutes or more) as it depends on the water composition

In this project the Arduino PID library is used to start/stop the chemicals pumps in a cyclic manner, similar to a "PWM" signal. The period of the cycle is defined by the WINDOW SIZE parameter which is fixed (in Milliseconds). What the PID library does is vary the duty cycle of the cycle.

If the computed error in the PID loop is null or negative, the duty cycle is set to zero (the ouput of the function PID.Compute()) and the pump is never actuated. If the error is positive, the duty cycle is set to a value between 0 and a max value (equal to the WINDOW SIZE, ie. the pump is running full time).

So in practice the ouput of the PID.Compute() function is a duration in milliseconds during which the pump will be activated for every cycle. If for instance, the WINDOW SIZE is set to 3600000ms (ie. one hour) and the output of the PID is 600000ms (ie. 10mins), the pump will be activated for 10mins at the begining of every hour cycle.

On the default Kp,Ki,Kd parameter values of the PID: By default in this project, Ki and Kd are null for stability reasons and so the PID loop is only a P loop, ie. a proportional loop. Adding some Ki and Kd to the PID loop may theoretically increase regulation performance but is also more complex to adjust and could result in instabilities. Since a P-only loop worked well enough and that safety considerations should be taken seriously in this project, I left it as is.

For my 50m3 pool the Kp default values are 2000000 for the pH loop and 4500 for the Orp loop. They were chosen experimentally in the following way:

I experimentally checked how much chemical was required to change the measured parameter (pH or Orp) by a certain amount. For instance I determined that 83ml of acid changed the pH by 0.1 for my 50m3 pool. The flow rate of the acid pump being 1.5L/hour, we can then determine for how many minutes the pump should be activated if the pH error is 0.1, which are (0.083*60/1.5) = 3.3minutes or roughly 200000ms. And so for an error of 1 in the pH PID loop, the pump needs to be activated 10 times longer, ie. during 2000000ms, which should be taken as the Kp value. The same reasoning goes for the Kp value of the Orp PID loop.

On the WINDOW SIZE: Various parameters influence the speed at which an injected chemical in the pool water will result in a variation in the measured pH or Orp. Experimentally I measured that in my case it can take up to 30minutes and therefore the injection cycle period should be at least 30mins or longer in order not to inject more chemical over the following cycles thinking that it required more when in fact the chemical reactions simply needed more time to take effect, which would eventually result in overshooting. So in my case I setlled for a safe one hour WINDOW SIZE (ie. 3600000ms)

Below are the Payloads/commands to publish on the "PoolTopicAPI" topic (see hardcoded in code) in Json format in order to launch actions on the Arduino:

Below is a (quick and dirty) wiring diagram with the Controllino MAXI. Right click and display image in full screen to see the details.

See the NodeRed folder for more info and this tutorial on how to create a Grafana dashboard from MQTT data.

This is an Arduino-based pool monitoring system that can monitor the pH and chlorine levels in a pool and send the data to a mobile device or home automation system via Bluetooth or WiFi.

This solution uses an Arduino board with built-in Bluetooth capabilities, such as the Arduino Nano 33 IoT or the Arduino MKR WiFi 1010, to read data from pH and chlorine sensors and send it via Bluetooth to a mobile device or home automation system.

This solution uses an Arduino board with an ESP8266 or ESP32 WiFi module to connect to a WiFi network and send data to a server or cloud service for monitoring.

This project is licensed under the MIT License. See the LICENSE file for details.

The code samples for both solutions can be found in the solution1.ino and solution2.ino files in this repository. Copy the contents of the appropriate file and paste it into the Arduino IDE to upload it to your board.

Purchase the required components listed in the bill of materials. Set up your Arduino board and sensors according to the wiring diagram for your chosen solution. Install the Arduino IDE and set up your board and port in the IDE. Copy the code for your chosen solution from the solution1.ino or solution2.ino file in this repository. Paste the code into the Arduino IDE and upload it to your board. Install the mobile app or set up the server or cloud service to receive and store the data. Monitor the pH and chlorine levels in your pool from your mobile device or server. Note that additional configuration may be required for your specific mobile app or server/cloud service. Refer to the documentation for those products for more information.

This project is licensed under the MIT License. See the LICENSE file for details.

This project was inspired by the many DIY pool monitoring projects available online. Thanks to the open-source community for providing guidance and inspiration for this project.

Arduino-based pool monitoring system that measures pH and chlorine levels using sensors and sends data to a mobile device or server via Bluetooth or WiFi. Includes sample code for two different solutions, bill of materials, and setup instructions.

1. Executive Abstract and Engineering Problem Formulation for Arduino Pool Automation

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 Pool Automation 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 pool automation 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 Pool Automation 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 pool automation 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 Pool Automation 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.