Most write-ups on remote water monitoring start with the cloud dashboard. That's the wrong place to start. The dashboard is the easy part. The hard part is getting a reliable, timestamped reading out of a sewer manhole or an unpowered reservoir, every day, for the next five years, without sending anyone out to check on it.
That constraint (no mains power, no comms cable, no site visits) is really what decides the hardware architecture for water and wastewater monitoring. Here's how that architecture usually gets built, using a real deployment pattern as the reference.
Step One: Sort Your Sites by Power, Not by Sensor
Every water or wastewater asset in a network fall into one of two buckets.
- Powered sites. Pump stations, treatment plant sub-systems, anywhere with a panel and continuous electricity.
- Unpowered sites. Manholes, remote reservoirs, isolated sections of pipe, boreholes.
It's tempting to pick hardware based on the sensor first, a 4-20mA level transmitter here, an RS-485 flow meter there. But that's the second decision, not the first. The first decision is whether the enclosure needs to survive on batteries or can sit on a DIN rail drawing 9-32VDC all day. Get that wrong and you're either burning through battery replacements on a site that had power the whole time, or you've bolted a mains-only controller onto a pole with no outlet for a mile in any direction.
NORVI's water and wastewater monitoring architecture is a useful reference for this split. It's an IP67 battery-powered logger for unpowered sites, and a mains-powered cellular controller with relay outputs for sites that need to actuate a pump or valve as well as log a reading.
The Unpowered Case Is Where It Gets Interesting
Powered sites are the easy end of the job. You can run a beefier MCU, a bigger radio, and not worry much about duty cycle. Unpowered sites are where the actual engineering happens, because every milliamp has to be justified against a battery budget that's supposed to last years, not weeks.
The pattern that makes five-plus years on non-rechargeable cells realistic looks something like this:
LOOP:
wake_from_deep_sleep()
read_sensor() // 4-20mA loop, RS-485, or digital
timestamp = rtc.now()
buffer_to_sd(timestamp, reading)
if cellular_window_due():
modem.wake()
publish_over_nbiot(reading, timestamp)
modem.sleep()
enter_deep_sleep(interval)
Anything power-hungry, the cellular radio especially, stays off unless it's genuinely needed. A device built around that idea, like the NORVI EC-M12 battery-powered cellular data logger, pairs an ultra-low-power STM32L072 with a SIM7070 modem, so the MCU spends most of its life asleep and only wakes the radio for a short transmit window. With a 38,000mAh dual-cell pack behind it, that sleep-first cycle is what stretches a deployment out to 5-7 years depending on how often it reports.
Two details tend to matter more than they look at first glance.
Local storage isn't optional. A cellular link will drop sooner or later. If a device only transmits and never logs to a microSD card with an onboard RTC timestamp, a signal gap turns into a data gap, and for a utility that needs a defensible record for compliance reporting, that's a real problem rather than a minor inconvenience.
Model-specific I/O beats a universal board. A logger built with a dual 4-20mA analog front end for a level transmitter is a different product from one wired for RS-485 Modbus or a strain-gauge load cell. Trying to make one board handle all of it usually means extra parts drawing quiescent current on every unit, even the ones that never use them.
Where Each Pattern Shows Up in the Field
Mapping the two buckets onto real sites:
Reservoir and tank level. Usually off-grid, so a battery logger with a 4-20mA level transmitter reporting over NB-IoT or LTE-M can cover it for years without a battery change.
Sewer and manhole level. No power, and the enclosure has to survive a submersion-adjacent environment. IP67 isn't a nice-to-have here, it's the baseline. The job is mostly flagging surcharge risk before an overflow happens.
Pump stations. These almost always have mains power already, so the interesting move is combining monitoring with control: log wet-well level and use a relay output to start or stop the pump, or raise a high-level alarm, from the same device.
Treatment plant sub-systems. Powered, and usually pulling from RS-485 Modbus flow meters and quality sensors that need to be timestamped and stored for later audit.
A Minimal Payload Example
If you're prototyping the cloud side before the hardware even arrives, a reasonable NB-IoT/MQTT payload for a level-logging use case might look like this:
{
"device_id": "ecm12-reservoir-04",
"ts": "2026-08-12T04:15:00Z",
"battery_mv": 3612,
"readings": [
{ "channel": "level_4_20ma", "value_ma": 12.84, "value_eng": 3.21, "unit": "m" }
]
}
Keeping the payload small matters more on NB-IoT than it would on Wi-Fi or Ethernet. Every extra byte over a low-power wide-area network means more radio-on time, and that's usually the single biggest line item in the battery budget.
The Compliance Angle Utilities Actually Care About
For water and wastewater operators, “did we log the reading” isn't really the whole requirement. “Can we prove when it happened, even through a network outage” usually is. That's the practical case for RTC-backed timestamping at the hardware level instead of relying on server-side arrival time. A reading buffered locally during a cellular outage and sent later still carries the correct field timestamp, not just the time it happened to reach the platform.
Wrapping Up
If you're speccing something similar, the full water and wastewater monitoring architecture breaks down the powered versus unpowered hardware split in more detail, and the EC-M12 data logger page has the model-by-model I/O and battery specs for the unpowered side of that split.
Top comments (0)