Smart Water Guardian AI

The Problem: Water You Can't See Going Bad

Two billion people worldwide drink water that isn't safely managed. The danger is rarely a single dramatic event. It's the slow, invisible drift: a gradual rise in dissolved solids, a small pH shift, cloudiness creeping in. By the time contamination is obvious, people have already been drinking it.

The tools that could catch this early are out of reach for the communities that need them most. Lab testing takes 24 to 48 hours and a trip to a city. Industrial probes cost thousands and lock their data behind proprietary dashboards. Neither works for a rural well, a village cistern, or a small water cooperative.

Smart Water Guardian AI is an attempt to close that gap: a low-cost device that watches water continuously, learns what normal looks like for that specific source, and raises a flag the moment things start to deviate. Everything runs locally, with no permanent internet connection required for the intelligence to work.

The goal isn't to replace a certified lab. It's to give a community an early, affordable, always-on warning that something has changed and the water deserves a closer look.

What It Does

The device continuously measures four parameters (pH, total dissolved solids, turbidity, and temperature) and combines two complementary layers of judgment:

A regulatory layer: fixed thresholds based on WHO guidance. If a value leaves the safe range, the water is flagged as critical immediately.

An AI layer: an Edge Impulse K-means anomaly detector that has learned the normal signature of this specific water source. It flags deviations from the learned normal, even when each individual value is still technically within range.

Results are shown three ways: a local web dashboard, a companion Android app, and a sync to Arduino Cloud for remote viewing. Local alerts (LED and buzzer) fire on the device itself.

The combination matters. Thresholds alone are blunt, they only react once a limit is already crossed. The anomaly detector adds a second, earlier signal: this no longer looks like your usual water. That's the difference between reacting and noticing.

Why Arduino UNO Q

This project would not run on a classic Arduino, and that's the point. The UNO Q has a dual-brain architecture: an STM32 microcontroller for hard real-time sensor reading and actuator control, and a Linux-capable QRB2210 processor that runs the full AI inference pipeline natively.

The microcontroller does what microcontrollers do well: read analog sensors, drive LEDs and a buzzer, respond instantly. The Linux side does what a microcontroller never could: run a real machine-learning model (Edge Impulse K-means), serve a local web dashboard, sync with Arduino Cloud, and store time-series history all without a separate computer. One compact board covers the entire chain from raw voltage to AI decision to dashboard, making it the only platform that could bring this project from concept to working prototype.

Arduino App Lab accelerated development by letting us prototype the web dashboard and orchestrate the hybrid STM32/Linux workflow in one environment, bridging the gap between real-time control and edge AI.

Layer 1 - Sensors (STM32 MCU, real-time)
pH | Turbidity | TDS | Temperature
Bridge RPC
Layer 2 - Edge processing (QRB2210, Linux)
Calibration | Conversion | Median filtering
Feature extraction
Layer 3 - AI inference (Edge Impulse K-means .eim)
Anomaly score
Decision
Layer 4 - Action
LED | Buzzer | CSV log
Network
Layer 5 - Interfaces
Web dashboard | Android app | Arduino Cloud

Hardware

• Arduino UNO Q (4GB) - Main board (STM32 + QRB2210)
• pH sensor (analog) - Water acidity
• Turbidity sensor (analog) - Particle suspension
• TDS sensor (DFRobot, analog) - Dissolved solids
• DS18B20 waterproof (OneWire) - Temperature and compensation
• RGB LED (GPIO) - Visual alert
• Active buzzer (GPIO) - Audible alert

A critical hardware lesson: sensor grounding. Early on, the pH reading went haywire whenever the other probes were submerged in the same water. After isolating each sensor and testing it alone, the culprit turned out to be the DS18B20: its metal stainless-steel sheath was electrically coupling the circuit ground to the water itself, corrupting the high-impedance pH measurement.

The fix was physical, not software: insulating the metal probe with heat-shrink tubing, sealed at the tip. This is the kind of problem you only find by building the real thing and watching it fail.

Note on logic levels: the UNO Q GPIO operates at 3.3V. Sensor selection and wiring must respect this.

Calibration: Making the Numbers Trustworthy

A sensor reading is worthless until it's calibrated against something real. This was a significant part of the work, and the honesty of the final numbers comes from it.

pH was calibrated against actual buffer solutions using a three-point calibration (pH 4, 7, and 10), fitted with a linear regression.

The fit quality is excellent: each buffer reads back within 0.04 pH units of its true value. A 15-sample median filter smooths electrical noise on each reading.

TDS was validated against a known standard. An Atlas Scientific 12880 microsiemens solution was diluted 1:10 to land near 644 ppm, using the 0.5 conversion convention. The probe read 650.8 ppm, an error under 1 percent. That gives real confidence in the TDS values.

Turbidity is the honest weak point. Without a formazine reference standard, the absolute NTU scale is not calibrated. The sensor reliably distinguishes clear water (NTU around 0) from visibly cloudy water (a milk test pushes it to hundreds of NTU), but the exact numerical value is indicative, not certified. This limitation is stated openly rather than hidden.

Temperature from the DS18B20 is used to compensate both pH and TDS, since both drift with temperature.

The AI: Learning Normal Instead of Guessing Thresholds

Why anomaly detection

Most water monitors are pure rule engines: if pH is below 6.5, alert. The flaw is that contamination often begins as a combination of subtle shifts across several parameters, none of which has yet crossed its individual limit.

A K-means anomaly detector takes a different approach. It's trained only on normal water, with no labeled contamination needed. It learns clusters describing the normal multivariate signature, then scores new measurements by their distance from those clusters. Far from every known cluster means anomalous.

The hard lesson: simulated data doesn't work

The first model was trained on simulated normal water. It failed. On real tap water, it produced a constant anomaly score of 24 to 49, a permanent false alarm. The simulated data simply didn't match the texture of reality.

The fix was to collect real data: a multi-hour overnight run logging actual tap water at a 10-second interval, yielding over a thousand clean normal samples after filtering out sensor glitches. Retrained on this real dataset, the model's normal-water score dropped to the expected low range. The lesson (train on reality, not on your assumptions about reality) is one of the most valuable takeaways of the whole project.

The feature-format bug

After deploying the retrained model, inference returned a constant error value of 1000 regardless of input. A long, methodical debugging session, testing the exact raw features copied from Edge Impulse against the on-device runner, revealed the cause: the model expects the current measurement (4 values) followed by zero-padding to fill its 48-feature input, a consequence of the very low sampling frequency of the 2-hour window. The Python code had been flattening a full window of real values instead. Correcting the feature layout fixed inference instantly. A bonus: the score is now computed from the very first measurement, with no warm-up window.

Impulse design

Input: time-series window, four axes (pH, TDS, turbidity, temperature)

Processing: Flatten, statistical features per sensor

Learning: K-means anomaly detection, 32 clusters

Deployment: Linux AARCH64.eim file, running natively on the QRB2210

The final model uses pH, TDS, and temperature features. Turbidity, being constant at zero in clean water, was excluded from the model and is instead handled by a direct threshold.

Decision Logic: Two Layers, Clearly Separated

IF a WHO threshold is violated, the status is CRITICAL (regulatory limit crossed)

ELSE IF the AI anomaly score exceeds its threshold, the status is PREDICTIVE ALERT (deviation from normal)

ELSE the status is NORMAL

The WHO layer is the regulatory backstop. The AI layer is the early-warning system that fires before a hard limit is crossed. They answer different questions: is this water legally unsafe, versus has this water changed from its normal self.

Results: Real Measurements

These are values measured on the actual device, not simulations.

Normal tap water: the AI anomaly score sits below the threshold and the status reads NORMAL.

Salt added (high TDS): as TDS climbed past the 500 mg/L WHO limit and on toward 1000, the status went CRITICAL on the threshold, and the AI score rose sharply at the same time. As the salt diluted and TDS fell, the score tracked it back down, confirming the model genuinely responds to TDS, not just pH.

Cloudy water (milk test): turbidity rose to several hundred NTU, triggering CRITICAL on the turbidity threshold.

Lemon juice (acidic contamination): the pH dropped to around 3, far below the WHO safe range. The system went CRITICAL immediately, and the AI score jumped to roughly 550, its strongest response of all the tests.

A clear, honest pattern emerged across these tests: the AI score rises smoothly as conditions move away from the learned normal and falls back as they return. That smooth correlation is the strongest evidence that the model is doing real work, not producing noise.

Limitations, Stated Openly

A monitoring device that hides its weaknesses can't be trusted. Here are this system's, plainly:

Turbidity is uncalibrated in absolute terms. Without a formazine standard, NTU values are indicative. The sensor detects that water is cloudy, not precisely how cloudy. Its raw signal is also electrically noisy, requiring a carefully placed threshold to avoid false triggers.

The AI is tuned to one water source. The model learns the normal of the water it was trained on. Refining the pH calibration after the model was trained shifted the measured values, which in turn shifted the anomaly scores. The detection threshold was adjusted accordingly, and a retraining on the current calibration is the clean next step to restore full sensitivity. This is worth stating plainly: an anomaly detector is only as stable as the calibration underneath it.

TDS saturates above roughly 1000 ppm. The module has a finite range; very high concentrations are detected as high but not precisely quantified.

The AI covers pH, TDS, and temperature. Turbidity is handled by the direct threshold, not the model.

None of these is fatal for the intended purpose (an affordable early-warning device) and each is a clear, honest direction for improvement.

Interfaces

The system surfaces its data three ways, each suited to a different situation.

Local web dashboard

Served on port 7000 and reachable from any browser on the local network, the dashboard shows four color-coded gauges (pH, TDS, turbidity, temperature), an AI anomaly-score bar with its threshold marker, 24-hour history charts for every parameter, a timestamped event log, and a global status badge. It's built with vanilla HTML and Chart.js, backed by a local time-series database, with no external service required.

Android companion app

A dedicated mobile app brings the same live monitoring to a phone, so a user doesn't need to keep a laptop open or stay on the same network as the board. Built with Flutter, it mirrors the dashboard's logic with a layout designed for a small screen:

Four sensor cards (pH, TDS, turbidity, temperature), each color-coded green, orange, or red against the same WHO thresholds used everywhere else in the system, so the app never disagrees with the web dashboard or the device's own LED.

An AI anomaly-score bar with the same threshold and scale as the backend.

Charts and an event-log screen for 24-hour history and a record of past alerts.

System notifications: when the water transitions into a critical state, the phone fires a native notification with sound and vibration, turning the device into something a user actually notices, even when the app is in the background.

Keeping the app's thresholds in lockstep with the Python backend was a deliberate design choice: a single anomaly threshold constant drives the bar color, the fill level, and the labels, so changing one value updates the whole app consistently. This avoids the classic trap of a dashboard that quietly contradicts the device it's monitoring.

Getting the app to talk to the board surfaced a small but instructive real-world bug. The release build failed every network request while the phone's own browser reached the same URL fine, the symptom of a missing INTERNET permission in the Android manifest. Flutter adds it automatically for debug builds, but not necessarily for release. Declaring the permission explicitly fixed it. Like the grounding issue earlier, it's the kind of thing you only hit by actually deploying to a real device.

Remote access via Cloudflare Tunnel

https://warranties-turtle-nice-mouse.trycloudflare.com/current

To monitor the water from outside the local network, which is the whole point of a remote guardian, the board exposes its local dashboard through a Cloudflare Tunnel. This gives the device a public HTTPS address without opening ports or configuring a router. The mobile app points at that address, so the same phone works whether it's next to the board or on the other side of the city over mobile data.

For this build, a quick account-less tunnel is used, which is perfect for demonstrating the concept, though its temporary URL and lack of uptime guarantee mean a production deployment would move to a named, persistent tunnel or proper hosting. The architecture, however, is exactly the one a real deployment would use: device, secure tunnel, phone, with the AI still running entirely on-device.

Arduino Cloud

In parallel, variables sync to Arduino Cloud, providing a second remote view and a hosted dashboard for monitoring from any internet-connected device.

Scalability and Next Steps

Calibrate turbidity with a proper formazine standard for certified NTU values.

Retrain the anomaly model on the refined pH calibration, and broaden the training set across seasons and times of day to make it robust to natural variation.

Multi-node deployment: each UNO Q is an independent node, and several can sync to a shared Arduino Cloud Thing, enabling geographic water-quality mapping and community-level alerts.

Offline-first operation: the AI already runs fully offline, and cloud sync is opportunistic, preserving all data locally when WiFi is unavailable. This is exactly what low-connectivity settings need.

Conclusion

Smart Water Guardian AI shows that meaningful edge-AI water monitoring is achievable with accessible, low-cost hardware. The Arduino UNO Q's hybrid design, a microcontroller for real-time control and a Linux processor for on-device AI, makes the whole pipeline fit on one board.

But the more important story is the engineering honesty behind the numbers: sensors calibrated against real standards, a model retrained when simulated data failed, an electrical grounding bug found by methodical testing, a feature-format bug traced to its root, and limitations stated plainly rather than hidden. The result isn't a polished demo that pretends to be perfect. It's a working system whose every claim is backed by a real measurement.

That, more than any single feature, is what makes it trustworthy.

#Arduino-Uno-Q, #Edge-Impulse, #Water-Quality, #Social-Impact, #Machine-Learning