Live on the Thrissur Corporation water network
Clamp-on ultrasonic sensing and dual 4G / LoRa gateways feed an AI engine that audits the whole network every night and reports what it found. Hardware, firmware, software and the model server — all of it ours.
t₁ downstream, with flow — arrives sooner t₂ upstream, against flow flow ∝ t₂ − t₁
The pulse travelling with the water arrives sooner than the one sent against it. That difference — a few nanoseconds across a metre of main — is the flow. Nothing enters the pipe; the transducers clamp to the outside. Sample values from meter AMR254.
The problem
Urban India loses a large share of its treated water, yet most distribution networks run with almost no real-time metering — and no way to say where the water went.
And the instruments themselves fight you. Imported smart meters cost too much per point to deploy at network scale, and the coupling gel that clamp-on meters need is scarce and dries out within weeks — every dried joint is another truck roll.
The solution
Three stages, in order — each one built by us, so a problem at any stage is ours to fix.
01 — Sense
Rugged, low-cost flow and level sensing fitted to the pipes and tanks a city already has. No civil works, no cutting the main, no wetted electronics.
02 — Connect
Gateways read every meter over Modbus RTU and stream readings out over 4G or LoRa — whichever the site can hold — buffering to flash when the link drops.
03 — Decide
Inflow, storage and branch flows land time-aligned in one database, and the AI engine walks the topology every night to find the tier that doesn’t reconcile.
The stack
Four pieces, one vertically integrated system — from the wax on the transducer to the water balance on the screen.
Our own ESP32-S3 board, reading up to ten meters over RS485 and pushing self-describing JSON upstream.
TUF-2000 series clamp-on transit-time meters, on mains up to a metre in bore — and the couplant problem solved locally.
A contactless reed-ladder probe for storage tanks, so the balance has a storage term instead of an assumption.
A live dashboard, a map of the real pipe topology, historical reporting, and an AI server that audits the network nightly.
How it works
One meter, one JSON packet — the same bytes whether they leave over 4G/MQTT or as a LoRa frame. The packet carries its own device and slave ID, and the time it was measured, taken from the gateway’s on-board clock.
So when a link drops, nothing is lost and nothing is skewed: readings queue on flash and replay in order, and the server reconciles them by measurement time rather than arrival time. A gateway that spent the night offline still tells the truth about the night.
{
"DeviceID": "G242506",
"SlaveID": "2",
"FR": "5.19", // flow rate
"FV": "0.42", // velocity
"NetT": "13640.25", // totalizer
"Today": "118.60",
"SQ": "92", // signal quality
"DateTime": "2026-07-10 06:15:00"
}The AI engine
The sensors and gateways exist to feed it. Our own AI server reads the whole network every night, audits it meter by meter, and writes up what it found before anyone opens a laptop.
The engine walks the pipeline topology from the database — it isn’t hardcoded, so a new meter joins the audit the day it’s registered — and checks every flow meter and every segment between them. The finished report is a document in your inbox, not a dashboard you have to remember to open.
It runs on our own AI server. Readings never leave the network to reach a third-party model.
Varuna Pipeline Network —
Flow Data Quality Report
Generated: 2026‑07‑10 06:02
Devices analysed: AMR254, BFM1516, BFM17, BFM23
Emailed · delivered
Every meter, every night: totalizers frozen long enough to mean a stuck sensor rather than genuine zero flow, cumulative counters running backwards, single corrupted frames sandwiched between good ones, and flow rates beyond what the gauge can physically mean.
Where no tank sits between two meters, their daily totals must agree. When they hold a steady ratio instead of converging, that is a calibration fault — and it is exactly the kind of thing a human reading a table misses.
A per-zone balance narrows a leak from “somewhere in the city” to a few streets. Minimum nighttime flow that never falls to zero is hidden leakage, visible in the data long before it surfaces on a road.
Learned draw patterns schedule tank fills and pump runs — less overflow at the top of the tank, less energy burned at the pump.
What it caught
BFM23 and BFM1516 have no tank between them. Whatever passes the first must pass the second, so their daily totals should agree. Instead the downstream meter reported roughly 5.9× the upstream one, holding that same ratio two days running.
Water going missing is noisy and irregular. A ratio that stable is arithmetic — a scaling error in one meter’s configuration, not a leak. It had been sitting in the readings for weeks, invisible in a table nobody had time to read across.
| Day | BFM23 | BFM1516 | Ratio |
|---|---|---|---|
| 07 Jul | 8,064.00 | 26,687.50 | 3.31× |
| 08 Jul | 10,581.50 | 62,485.00 | 5.91× |
| 09 Jul | 8,394.00 | 49,872.50 | 5.94× |
How the engine is built
Every number is computed by code. Only the prose is written by the model.
Anomaly detection is deterministic — plain SQL and arithmetic over the readings, reproducible to the row. The language model is handed those finished numbers and asked to explain them; it is never asked to find them, and it is forbidden from restating a specific date or figure. So the tables in the report can be trusted absolutely, and the interpretation around them reads as what it is: a second opinion, for a human to sanity-check.
It is an unfashionable way to build with a language model. It is the only way we would put one in front of a utility.
In the field
Every device on the network reports its own health. An operator sees the network the way it actually branches — and hears about a dead meter by email, not by complaint.
Live flow and level gauges with a 24-hour trend under each. A meter that hasn’t spoken in twenty minutes is marked offline — distinct from one that has never reported at all.
Devices on their real coordinates, joined along the pipe topology they actually follow. A segment animates when the meter measuring it is passing water, so a stalled branch reads at a glance.
Any device, any date range: a trend chart, a sortable table, a clean print layout, and a CSV that opens straight into a spreadsheet for the corporation’s own records.
Total inflow against total outflow over a chosen period, from each meter’s own totalizer — with the assumptions it rests on stated on the page, not buried.
Email on the transition — when a device goes offline or comes back — never a repeated nag. Admins configure and register devices; viewers can see everything and change nothing.
Why Varuna
| Conventional approach | Varuna AIoT |
|---|---|
| Imported smart meters, high cost per point | Low-cost indigenous hardware on the pipes you already have |
| Commercial coupling gel — scarce, dries out in weeks | Persistent wax couplant, made in the field, holding for months |
| A single transport, usually cellular-only | 4G or LoRa chosen per site, with offline buffering either way |
| Black-box data, no built-in audit | Open JSON telemetry and a water-audit layer over it |
| Hard and expensive to service at fleet scale | Designed to be field-serviced, and to report its own health |
Traction
Hardware in the ground, streaming to a broker, on a real municipal distribution system — with the maintenance contract that comes with it.
NOW · DEPLOYED
Gateways, meters, the dashboard, and the AI engine auditing data quality every morning at 06:00.
NEXT
Per-zone balance, leak localisation, night-flow analysis and demand forecasting.
SCALE
Bulk provisioning, fleet-wide OTA, and NB-IoT / LTE-M and LoRaWAN uplink options.
HARDEN
MQTT over TLS, per-device authentication, and local SD-card logging across the fleet.
Get in touch
We’re looking for pilot sites and lab validation, utility and municipal partners across Kerala’s urban local bodies, and the incubation support to take a live deployment to a product.