Case Study
4,000+ smart water meters, running in production
A municipal water utility moved from manual meter reading to automated LoRaWAN metering on our network server — with a further 1,000+ meters live in a second country.
- Smart water meters in production
- 4,000+
- Additional meters, second country
- 1,000+
- Regional band used for this deployment
- IN865
The challenge
Water utilities face a specific combination of problems that makes metering harder than it looks from the outside.
Manual reading did not scale
Every billing cycle required staff to physically visit each meter. Readings arrived late, transcription errors were common, and disputed bills consumed time that should have gone to network maintenance.
Meters sit where radio struggles
Water meters live in pits, basements, boundary walls and under covers. Cellular modules drain batteries quickly in these positions and often fail to connect at all, which rules out the obvious alternative.
Leaks were found late
Without interval data, a continuously running connection was typically only discovered when a bill looked wrong — often months of non-revenue water later.
Battery replacement is not an option
Sending a technician to swap batteries across thousands of meters would erase the savings automation is supposed to deliver. Devices have to last years untouched.
How it was deployed
Five things determine whether a metering rollout at this scale works or quietly degrades over its first two years.
-
Coverage planning
Gateway placement was planned against the distribution network so that dense urban areas had overlapping coverage. Because several gateways often hear the same meter, the network server de-duplicates those copies and keeps the strongest — redundancy without duplicate billing data.
-
Bulk device provisioning
Meters were registered through bulk import against shared device profiles rather than configured one at a time, so an entire meter model carries one consistent configuration. OTAA activation issues fresh session keys at join.
-
Payload decoding
Meter-specific byte formats are decoded on the platform into named fields — cumulative volume, flow rate, battery level, tamper and reverse-flow flags — so downstream systems consume structured data rather than raw hex.
-
Battery optimisation through ADR
Adaptive Data Rate tunes each meter individually. Meters near a gateway transmit quickly at low power; those at the edge of coverage use slower, more robust settings. Across thousands of devices this is the single biggest factor in fleet battery life.
-
Integration with utility workflow
Consumption data flows from the network server into the utility’s billing workflow over standard integrations, with scheduled reports and export covering routine operational reporting.
What the utility gained
The operational capabilities now running across the deployed fleet.
- Automated meter reading replacing manual site visits
- Interval consumption data available for billing
- Continuous-flow signals that surface probable leaks
- Tamper and reverse-flow detection per meter
- Fleet-wide battery health visibility
- Gateway health and signal quality monitoring
Why LoRaWAN rather than cellular
The deciding factors were battery life and signal penetration. Water meters sit in enclosed, below-ground positions where cellular modules both struggle to connect and drain batteries quickly. LoRaWAN’s low power draw and building penetration let meters report reliably for years without a technician visit — which is what makes the economics of automated metering work at this scale.