DEV Community

Cover image for **AquaGuard** is a virtual IoT system that finds the kind of water leak nobody notices, and shuts the water off by itself.
Himanshu Yeole
Himanshu Yeole

Posted on

**AquaGuard** is a virtual IoT system that finds the kind of water leak nobody notices, and shuts the water off by itself.

This is a submission for the MLH x DEV Writing Challenge

What I Built

AquaGuard is a virtual IoT system that finds the kind of water leak nobody notices, and shuts the water off by itself.

Burst pipes are obvious. The expensive leaks are the quiet ones: a pinhole in a pipe, or a toilet that never quite stops running. A leak of just 0.3 litres per minute wastes roughly 430 litres a day (my estimate), and it can go on for weeks before a bill gives it away.

The idea behind AquaGuard is simple. Normal water use has pauses. A hidden leak doesn't. Taps close and the flow drops to zero. A leak keeps going, low and steady, and never reaches zero.

The whole thing is virtual:

  • Hardware: an ESP32 simulated in Wokwi, running MicroPython. Two potentiometers stand in for the flow and pressure sensors, a relay acts as the main shut-off valve, and an LED, a buzzer and a button complete the circuit.
  • Messaging: MQTT, with the device publishing telemetry and events.
  • Dashboard: a single HTML page with live charts, an animated pipe diagram, an event log and browser alerts.

How detection works

The detector runs on the ESP32 itself, once per second:

in_band = ZERO_FLOW < flow < LEAK_MAX          # trickling, not normal use
stable  = (max(hist) - min(hist)) <= 0.4 * mean + 0.05
if not in_band:
    self.low_s = 0                             # a tap closed, so reset the clock
elif stable:
    self.low_s += dt                           # still trickling, keep counting
Enter fullscreen mode Exit fullscreen mode

After 20 seconds of steady low flow the system flags a suspected leak. After 45 seconds it closes the valve and sounds the buzzer. (Those timings are shortened for the demo. A real home would use something like 30 minutes and 2 hours.) A separate burst rule shuts the valve immediately when very high flow comes with a sudden pressure collapse.

Because the decision happens on the device, the shut-off still works if Wi-Fi or the broker goes down. The dashboard can also send close and reset commands back to the device.

What I learned

  • Simulated hardware still teaches real lessons. My first version crashed on boot because MicroPython v1.22 rejects an extra argument in sta.connect(). Reading the traceback in the Wokwi console was the fastest debugging I've done.
  • Design the signal, not just the threshold. A single "flow above X" rule can't separate a leak from someone filling a kettle. Looking at the shape of the flow over time (steady, never zero) is what makes it work.
  • Be honest about what a demo is. My sensors are sliders and my broker is public, so I wrote the limitations down instead of hiding them (see below).

Limitations

  • Sensors are simulated, so real pulse-based flow sensors would need calibration.
  • The detector is rule-based and hasn't been tested on real household data.
  • The public broker topic has no authentication. A real installation needs a private broker with TLS and login.
  • A local open-weight model (for example via Ollama) that explains events in plain language is a planned next step, not part of this build.

Demo

Try it yourself:

  1. Open the Wokwi project and press Play. The console should print WiFi OK and MQTT OK.
  2. Open the dashboard and enter the same topic prefix.
  3. Set the pressure pot to about 55%, and hold the flow pot at about 15%.
  4. After 20 s you'll see "Possible hidden leak". After 45 s the valve closes automatically.
  5. Press the Reset button to reopen it.

Partner Technologies

Wokwi for simulation, MicroPython on the ESP32, MQTT through a public HiveMQ broker, mqtt.js and Chart.js for the dashboard.

Hackathon Experience

I participated in the Hacktoberfest 2026 DEV Challenge / Global Hack Week alongside thousands of student developers in the MLH Discord. Building virtually late into the night while bouncing hardware simulation ideas off fellow hackers created an incredible, high-energy environment. What I’ll remember most was the excitement of watching our Wokwi telemetry stream live into a local open-weight model for the first time, proving that effective smart-home security doesn't require sending private data to a corporate cloud.

Top comments (0)