Water Pipeline Leak Detector.

Project Overview

Uses pressure analytics across the water network to find leaks that waste an enormous share of treated water — pinpointing roughly where a pipe is losing, not just that the system leaks.

Water utilities lose a staggering amount of treated water to leaks — often a fifth to a third of everything pumped, so-called non-revenue water — and most of it drips away underground, unseen, for years. A burst main is obvious; the slow, hidden leaks that add up to the biggest losses are not, and finding them across kilometres of buried pipe is the hard part. This project attacks that with pressure analytics: pressure sensors across the network, and the insight that leaks leave a signature in how pressure behaves — so you can detect that a district is leaking and narrow down roughly where.

The physics is the lever. A leak is a continuous loss of water and pressure, so it shows up in the pressure field: a district with a leak has a characteristically lower and differently-behaving pressure than a healthy one, and the pattern of pressures across sensors, especially at night when legitimate demand is low, reveals leakage that daytime demand masks. Sudden pressure transients mark a new burst; a persistent depression localises to the leaking area. Combined with district metering (comparing water flowing into a zone against what is legitimately consumed — the difference is loss), pressure analytics can both quantify leakage and point to the district, and sometimes the stretch, where it is happening.

The nodes are pressure sensors at hydrants, valves and district boundaries, reporting over LoRa/cellular (buried infrastructure has no power or network), with analytics that compare pressures across the network and over time. The output is not "somewhere there's a leak" but "district 7 is losing ~X, concentrated toward the north end" — enough to send a crew with acoustic gear to the right place instead of the whole city. It is honest that pressure analytics localises rather than pinpoints to the exact fitting (final location needs acoustic correlation), that good results need adequate sensor density and modelling, and that this is one layer of a leakage-management programme. But as a pressure-analytics leak detector, it directs scarce leak-hunting effort at the districts and stretches actually losing water — turning a huge, invisible, expensive loss into a findable, prioritised one.

What this project does

• Senses pressure across the water network at key points
• Detects leakage from pressure behaviour (especially at night)
• Localises leaks to a district/stretch (pressure pattern + transients)
• Combines with district metering (inflow vs consumption = loss)
• Quantifies non-revenue water and prioritises leak hunting
• Reports over LoRa/cellular from buried, powerless infrastructure
• Directs crews with acoustic gear to the right area

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Pressure-analytics leak detection
• Night-flow/minimum-pressure analysis
• District localisation (not just "somewhere")
• District metering integration (NRW quantification)
• Burst-transient detection
• LoRa/cellular for buried infrastructure
• Honest: localises, acoustic gear pinpoints

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Network pressure sensing (buried, powerless)
• Pressure-analytics leak detection and localisation
• District metering and night-flow analysis
• LoRa/cellular telemetry
• Interpreting results for leak hunting

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹14,455, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 4441.5 mA. With a 1.5× design margin the supply should deliver at least 6700 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Fit pressure transducers rated for the main at hydrants, valves and DMA boundaries; multiple points enable localisation.
• Sample frequently enough to catch pressure transients (bursts) as well as slow trends.
• Battery + LoRa/cellular and solar where possible — buried water infrastructure has no power/network.
• Integrate a DMA inflow meter for non-revenue-water quantification (inflow vs legitimate consumption).
• Analytics run on a server correlating pressures/flows across the network and over time (especially at night).

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

The scale of the problem is what motivates a network approach: water utilities routinely lose a fifth to a third of treated water to leaks — non-revenue water — and the bulk of it is not dramatic bursts but slow, hidden leaks dripping away underground for years. The challenge is that these leaks are invisible and spread across kilometres of buried pipe, so the question is not usually "is the system leaking?" (it is) but "where, and how much, so we can fix the biggest ones first?". Digging up the whole network is impossible; the value is in localising the loss so scarce leak-hunting effort goes to the right place.

Pressure is the signal that makes this possible, because a leak is fundamentally a continuous loss of water and therefore leaves a signature in the pressure field. A district with significant leakage runs at a characteristically lower pressure and responds differently to demand than a tight one; a new burst causes a sudden pressure transient that propagates through the network; and a persistent, localised pressure depression points toward the leaking area. Reading the pattern of pressures across multiple sensors, and how it changes, converts an invisible underground loss into an observable, analysable phenomenon — you cannot see the leak, but you can see its effect on pressure.

The single most powerful technique is night analysis. During the day, legitimate consumption dominates the flow and pressure picture and masks leakage; but in the small hours, when almost no one is using water, whatever is still flowing and depressing pressure is overwhelmingly leakage. So the minimum night flow into a district, and the night-time pressure behaviour, are direct measures of how much that district leaks — a healthy zone goes quiet at night, a leaky one does not. Combined with district metering — comparing the metered inflow to a zone against the legitimate consumption within it, the difference being loss — pressure analytics both quantifies the leakage (litres per hour of non-revenue water) and, from the pressure pattern, localises it to a district and often a stretch.

The honest output and deployment shape complete the picture. The system does not pinpoint the exact leaking fitting — pressure analytics localises to an area, and the final metres are found by a crew with acoustic correlation gear (listening for the leak's sound) sent to that area rather than roaming the city. That division of labour — analytics to narrow it down, acoustics to pinpoint — is what makes leak hunting tractable and cheap. The nodes themselves must live in buried, powerless infrastructure, so they are battery-powered and report over LoRa or cellular, and good results depend on adequate sensor density and modelling. The design is candid that this is one layer of a broader leakage-management programme, and that localisation quality scales with how many pressure points you have. But the contribution is exactly what utilities need: turning a huge, invisible, expensive loss into a quantified, prioritised, localised one — telling you which districts and stretches are actually bleeding water, so you fix the biggest losses first instead of guessing.

The maths behind it

Minimum night flow (leakage)

At night, legitimate demand ≈ 0, so residual flow ≈ leakage:

  leakage ≈ min_night_flow(zone) − small legitimate night use

A healthy zone goes quiet at night; a leaky one keeps
flowing/depressing pressure → measure it in the small hours.

District metering (non-revenue water)

NRW(zone) = inflow − legitimate consumption

  inflow from the DMA meter; consumption from billed use.
  the difference is loss (leakage + theft + meter error).
Quantifies how much each district is losing.

Pressure localisation

A leak depresses/behaves-differently in the pressure field:

  compare pressures across sensors vs a healthy baseline/model
  a persistent local depression → leak in that area
  a sudden transient → new burst; timing across sensors hints
    at direction. Localises to a district/stretch (not exact).

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Deploy pressure sensing and metering

   Fit pressure transducers at hydrants/valves/DMA boundaries (rated for the main) and a DMA inflow meter, battery-powered with LoRa/cellular and solar where possible.

   Sample fast enough for transients and log/report to the analytics server.

2. Set up analytics

   On the server, baseline healthy pressures, run night-flow and pressure-pattern analysis, and integrate district metering for non-revenue-water quantification.

3. Localise and dispatch

   Localise leakage to a district/stretch, prioritise by quantified loss, and dispatch acoustic pinpointing to the right area.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Analyse night flow and pressure pattern

   Measure minimum night flow and compare district pressures to a healthy baseline to detect and localise leakage; catch transients for bursts.

   pythonleak-analytics.py Copy Download

   def minimum_night_flow(inflow_series, night_window):
       night = inflow_series.between(*night_window)     # e.g. 02:00-04:00
       return night.min()                               # residual ~ leakage
   
   def leakage_estimate(dma):
       mnf = minimum_night_flow(dma.inflow, ("02:00","04:00"))
       legit_night = dma.expected_night_use              # small
       return max(0, mnf - legit_night)                  # L/h leakage
   
   def localise(pressures, baseline_model):
       # persistent local depression vs healthy model => leak area
       dev = {sid: p - baseline_model[sid] for sid, p in pressures.items()}
       worst = min(dev, key=dev.get)                     # most depressed sensor
       if dev[worst] < -PRESS_THRESH:
           return area_around(worst)                     # district/stretch
       return None
   
   def detect_burst(pressure_series):
       dP = pressure_series.diff()
       return (dP < -BURST_STEP).any()                   # sudden drop = burst

   def minimum_night_flow(The minimum night flow into a district is measured when legitimate demand is near zero, so the residual is essentially leakage.

   return max(0, mnf - legit_night) # L/h leakageSubtracting the small legitimate night use gives a direct quantitative leakage estimate for the district.

   worst = min(dev, key=dev.get) # most depressed sensorThe sensor most depressed below the healthy model localises the leak to its area — turning "somewhere" into a district/stretch.

   return (dP < -BURST_STEP).any() # sudden drop = burstA sudden pressure drop flags a new burst quickly, distinct from slow background leakage.

2. Quantify NRW, prioritise and pinpoint

   Combine night flow and district metering to quantify non-revenue water per district, prioritise repairs by loss, and dispatch acoustic gear to the localised area for exact pinpointing.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Water Pipeline Pressure Node — ESP32, LoRa/cellular, solar

   Reports network pressure (and catches bursts) for server-side leak
   analytics: night-flow/pressure-pattern localises leakage to a
   district/stretch, quantified with district metering. Acoustic gear
   pinpoints the exact leak.
   ══════════════════════════════════════════════════════════════════ */

#include <LoRa.h>
#include <SPI.h>
#include <Preferences.h>
#include <math.h>

#define PIN_PRESSURE 34
#define P_FS 16.0f            // bar full-scale
#define BURST_STEP 0.5f       // bar sudden drop = burst
#define NODE_ID 7
#define SLEEP_S 300           // 5 min (faster if a transient)

Preferences prefs;
RTC_DATA_ATTR float prevP = NAN;

float readPressureBar(){
  long s=0; for(int i=0;i<64;i++) s+=analogRead(PIN_PRESSURE);
  return (s/64.0f)/4095.0f * P_FS;
}

void report(float p, bool burst){
  LoRa.beginPacket();
  LoRa.printf("{\"node\":%d,\"bar\":%.2f,\"burst\":%d}",
              NODE_ID, p, burst?1:0);
  LoRa.endPacket();
}

void setup(){
  Serial.begin(115200);
  analogSetPinAttenuation(PIN_PRESSURE, ADC_11db);
  SPI.begin(); LoRa.setPins(5,14,2); LoRa.begin(433E6); LoRa.setSpreadingFactor(10);

  float p = readPressureBar();
  bool burst = !isnan(prevP) && (p - prevP) < -BURST_STEP;   // sudden drop
  prevP = p;
  report(p, burst);

  // sample faster briefly after a suspected burst
  uint32_t sleep_s = burst ? 30 : SLEEP_S;
  esp_sleep_enable_timer_wakeup((uint64_t)sleep_s*1000000ULL);
  esp_deep_sleep_start();
}
void loop(){}

Configuration & Calibration

Configuration steps

• Configure pressure transducers and sampling (fast enough for transients), and DMA inflow metering.
• Set up server-side baselines, night windows, thresholds and localisation.
• Configure LoRa/cellular reporting and battery/solar supervision.
• Integrate consumption data for non-revenue-water quantification.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Pressure

   Calibrate transducers against a reference; verify readings across the network.

2. Baselines/night

   Establish healthy pressure baselines and typical night flows so anomalies stand out.

3. Localisation

   Validate localisation against known leaks/bursts; adjust density/model as needed.

Network Architecture & Connectivity

Communication protocol

Nodes report pressure on a cadence (faster on transients); the server runs night-flow and pressure-pattern analytics and district metering to detect, quantify and localise leakage.

Message contract between the device and the broker.

Cloud platform configuration

A leakage platform maps pressures/flows, detects and localises leaks (night analysis, pressure pattern), quantifies non-revenue water, and prioritises repairs; crews pinpoint with acoustics.

Dashboard setup

A network map of pressures/leakage, district NRW, burst alerts, and prioritised repair list.

Mobile app integration

Burst and leakage alerts with localisation; repair priorities.

Security considerations

• Authenticate node data; secure the analytics.
• Supervise battery/health; alert on silent nodes.
• Combine with acoustic pinpointing for final location.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The platform maps district pressures and night flows, flags/localises leakage, quantifies non-revenue water, and prioritises repairs; bursts alert quickly.

{
  "node": 7,
  "bar": 2.9,
  "burst": 0
}

Node 7's pressure feeds analytics that, with its neighbours and the DMA night flow, localise leakage to a district and quantify it — directing a crew with acoustic gear to the right stretch instead of the whole city.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Deep-sleep between pressure reads; sample faster on transients.
• Run night-flow and pattern analytics on the server; combine with district metering.
• Localise to a district/stretch; hand off to acoustics for pinpointing.
• Quantify and prioritise by loss.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• Use pressure transducers rated for the main; install safely on live water infrastructure (qualified work).
• Pressure analytics localises; final pinpointing needs acoustic correlation gear.
• Buried infrastructure has no power/network — design battery + LoRa/cellular for long life.
• This is one layer of a leakage-management programme.
• Mains voltage kills. Anything on the load side of the relay is at 230 V. Do not work on a powered circuit, and never leave exposed mains wiring on a bench where someone could touch it.
• Keep at least 6 mm of creepage between the mains and low-voltage sides of any board you make, and never route mains tracks under the microcontroller.
• Have a qualified electrician do the final installation into a consumer unit or wall fitting. In most jurisdictions this is a legal requirement, not a suggestion.
• Fit an RCD/RCBO upstream and fuse the load appropriately for its rating.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• Never power an RF module without its antenna fitted — the reflected power destroys the output stage. Check your local licence-free band and duty-cycle limits before transmitting.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Verify transducer calibration and node battery/health.
• Update healthy baselines/models as the network changes.
• Act on leak alerts; pinpoint and repair; verify loss reduction.
• Maintain district metering and consumption data.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Wash the panel every few weeks in dusty conditions; a visible dust film costs 15–25 % of the harvest.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add acoustic/correlating sensors for automated pinpointing.
• Add hydraulic modelling for better localisation.
• Fuse smart-meter consumption for tighter NRW.
• Add pressure management to reduce leakage rates.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Non-revenue waterReference
2. Water leak detectionReference
3. District metered areas / minimum night flowReference
4. Acoustic leak correlationReference
5. Pressure management in water networksReference