DEV Community: Bhanuka Gamachchige

Monitoring Water Networks Where There's No Power or Wi-Fi

Bhanuka Gamachchige — Sat, 15 Aug 2026 04:42:13 +0000

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.

Monitoring a Borehole With No Power, No Wi-Fi, and Nobody Standing Next to It

Bhanuka Gamachchige — Thu, 30 Jul 2026 03:54:00 +0000

A few months back I got pulled into a conversation about instrumenting a wellfield, and it reminded me how different "remote monitoring" looks once there's no mains power or Wi-Fi anywhere nearby. Boreholes are a good example of just how hard that gets. They're usually out in a field somewhere, or scattered across a wellfield, with nothing to plug into and no network to join. And the thing you actually care about, the water level, is happening tens of meters underground where nobody can see it.

Most sites still handle this the old fashioned way: someone drives out, drops a dip meter down the hole, and writes a number on a clipboard. It works, sort of, but it only tells you what's happening at that exact moment. If a pump has been running dry for three days before the next site visit, nobody finds out until it's already a problem.

So I wanted to write up how a battery powered, cellular connected logger actually solves this, and what the real engineering trade offs look like: sensor choice, power budgeting, and picking the right radio.

What's actually in the system

Strip it down and a remote borehole node is four things:

A hydrostatic pressure sensor sitting in or above the water column
A sealed, battery powered logger at the wellhead
A cellular radio, NB-IoT, 2G, or 4G LTE depending on the region
A dashboard and alerting layer, either your own or a vendor's

Sensor reads the level, logger stores and transmits it, network carries it back, and it lands on a dashboard or an SMS. NORVI's EC-M12 borehole and groundwater monitoring solution is a good real world example of this, mostly because the interesting decisions are all in how it handles power and connectivity rather than the sensor itself.

Sensor choice matters more than I expected

There are basically two ways to take a hydrostatic reading. You can lower a sealed 316L stainless sensor into the water on a cable, which is the classic direct immersion approach and usually holds up for around two years on battery. Or you can use a tube type sensor, where the sensing head stays up at the wellhead and reads the column through a tube run down the hole. Since the electronics aren't sitting in the water constantly, those tend to run past three years.

If you're only doing one or two sites it probably doesn't matter much which you pick. But if you're rolling out a fleet of nodes across a wellfield, that extra year or so adds up fast in fewer truck rolls and lower long term cost, and it's worth thinking about upfront rather than after the first round of battery swaps.

The real trick to multi year battery life

Getting years of battery life from a cellular device is not just about using a bigger battery. It is about reducing how often the cellular radio needs to transmit.

A well-designed data logger wakes up at regular intervals, records sensor readings locally, and only sends data when a meaningful change is detected. It also sends periodic heartbeat messages so you know the device is still online.

Cellular transmission uses far more power than taking sensor readings or storing data locally. By transmitting only when needed, increasing logging frequency when conditions change, and staying quiet when everything is stable, a battery-powered data logger can operate for years instead of months.

The table below shows the power consumption of the battery-powered data logger under different operating conditions.

Source: EC-M12-BC-C6-C LOW POWER APPLICATIONS – SLEEP MODE

One honest caveat here: signal strength matters a lot. A node reaching for a weak signal burns more power per transmission than one sitting under good coverage. So the choice between NB-IoT, which is lower power and reaches deeper into weak coverage areas, and 4G LTE, which draws more power but is available where NB-IoT isn't, really should be made per site rather than as a blanket default.

Alerts that don't depend on your cloud staying up

Since the cellular modem can send SMS directly, the alerting logic can live right on the device instead of in the cloud. It compares readings against thresholds and fires off a text the moment something crosses a line, whether or not your dashboard backend happens to be reachable at that moment. If you've ever had a cloud outage quietly swallow a critical alert, you'll know why that matters more than it sounds like on paper.

If you're building or speccing something similar

If you're a system integrator or just evaluating hardware for a groundwater project, it's worth reading through the full EC-M12 breakdown, which covers sensor options, cellular variants, and actual battery numbers from live deployments. Even if you end up building your own logger, the same constraints apply: no mains power, no local network, and a multi year battery target you have to design around from day one.

Curious what others have run into instrumenting off grid infrastructure like this. Sensor choice, radio choice, or something else entirely that bit you in the field? Have a remote monitoring project in mind? Contact the NORVI engineering team for expert guidance or request a free consultation.

Getting Started with Modbus RTU on ESP32

Bhanuka Gamachchige — Fri, 17 Jul 2026 12:50:31 +0000

Modbus RTU over RS-485 is the serial workhorse of industrial field wiring — the variant you'll meet when connecting an ESP32 directly to an energy meter, PLC, VFD, or temperature transmitter over a wired bus. This tutorial walks through wiring the hardware, installing a library, and flashing working RTU master code.

What You'll Build

A Modbus RTU master on ESP32 that polls holding registers from an RS-485 slave device over a wired bus.
An understanding of register types, addressing, and the reliability practices that separate a demo from a production deployment.

Prerequisites

Arduino IDE (or PlatformIO) with the ESP32 board package installed.
An ESP32 dev board, or an industrial ESP32 controller with a built-in RS-485 transceiver such as the NORVI X — this saves you from wiring a separate MAX485 module.
A Modbus RTU slave device (energy meter, sensor, or PLC).
Basic familiarity with the Arduino C++ syntax and serial monitor debugging.

A 60-Second Modbus Primer

Modbus is a master–slave protocol dating back to 1979. One master polls up to 247 slave devices, each with a unique address (1–247). Data lives in four register types, and knowing which one you need is half the battle:

Register Type	Access	Width	Typical Use
Coils (0x)	Read/Write	1-bit	Relay outputs, digital controls
Discrete Inputs (1x)	Read only	1-bit	Digital sensor inputs, switch states
Input Registers (3x)	Read only	16-bit	Analog sensor values, process data
Holding Registers (4x)	Read/Write	16-bit	Setpoints, configuration parameters

Modbus RTU over RS-485

Step 1 — Wire the Hardware

The ESP32's UART pins output 3.3V TTL logic, but RS-485 uses a differential voltage signal — so you need a TTL-to-RS-485 transceiver (typically a MAX485 or MAX3485 chip) between the ESP32 and the bus.

UART TX → transceiver DI (driver input)
UART RX ← transceiver RO (receiver output)
A spare GPIO → transceiver DE and RE tied together (direction control)
Transceiver A/B terminals → the RS-485 A+/B− pair on your slave device

Skip the transceiver wiring

Industrial controllers like the NORVI X have the TTL-to-RS-485 converter built into the board, so RS-485 slaves connect straight to a screw terminal — no breadboard, no separate module, and DE/RE switching is handled for you.

Two more wiring details that matter more than they look:

Place a 120Ω termination resistor at each physical end of the RS-485 bus if the run is longer than a few meters.
Give every slave device a unique address in the 1–247 range — duplicate addresses cause bus conflicts.

Step 2 — Install a Modbus Library

For RTU master mode on Arduino, ModbusMaster is the simplest starting point. Install it from the Library Manager:

Arduino IDE → Sketch → Include Library → Manage Libraries...
Search: "ModbusMaster" by Doc Walker → Install

Other options worth knowing about, depending on your needs:

modbus-esp32 — supports both RTU and TCP/IP, master and slave modes.
ArduinoModbus — the official Arduino library, straightforward setup.
esp32ModbusRTU — interrupt-driven and non-blocking, useful if your loop() is already busy.

Step 3 — Write the RTU Master Sketch

This sketch polls two holding registers from slave address 1 every half-second and prints the values to the serial monitor:

#include <ModbusMaster.h>

#define SLAVE_ID 1
#define RXD2 16  // ESP32 UART2 RX → transceiver RO / NORVI X RS-485 header
#define TXD2 17  // ESP32 UART2 TX → transceiver DI / NORVI X RS-485 header

ModbusMaster node;

void setup() {
  Serial.begin(115200);
  Serial2.begin(9600, SERIAL_8N1, RXD2, TXD2); // match your slave's baud/parity
  node.begin(SLAVE_ID, Serial2);
  Serial.println("Modbus RTU master ready");
}

void loop() {
  // Read 2 holding registers starting at address 0x0000
  uint8_t result = node.readHoldingRegisters(0x0000, 2);

  if (result == node.ku8MBSuccess) {
    uint16_t reg0 = node.getResponseBuffer(0);
    uint16_t reg1 = node.getResponseBuffer(1);
    Serial.printf("Register 0: %u | Register 1: %u\n", reg0, reg1);
  } else {
    Serial.printf("Modbus read failed — error code: 0x%02X\n", result);
  }

  delay(500); // respect the slave's minimum poll interval
}

A few things to adjust for your setup:

Baud rate, parity, and stop bits in Serial2.begin() must match your slave device exactly — check the datasheet. 9600 8N1 is the most common default.
The register start address (0x0000) and quantity (2) depend on your device's register map.
If you're using an external MAX485 module instead of a built-in transceiver, you'll also need to toggle a DE/RE GPIO to HIGH before transmitting and LOW after — libraries like esp32ModbusRTU handle this automatically.

Reliability Checklist for Production (RTU)

A working sketch on the bench is not the same as a stable deployment on a factory floor. Before you ship:

Termination: 120Ω resistors at both physical ends of an RS-485 bus longer than a few meters — omitting this causes reflections and intermittent read failures.
Unique addressing: every RTU slave needs a distinct 1–247 address.
Retry logic: treat a single failed poll as noise, not a fault. Retry two or three times before flagging an alarm.
CRC validation: RTU frames carry a CRC checksum — confirm your library validates it (most do by default) rather than trusting raw bytes.
Poll interval: don't poll faster than the slave's documented response time — 100–500 ms minimum is typical. Hammering the bus causes timeouts, not faster data.
Floating-point data: Modbus registers are 16-bit integers. Many analog sensors split a float across two consecutive registers in IEEE 754 format — check the datasheet's register map before assuming a raw integer.

Troubleshooting Common Issues (RTU)

Symptom	Likely Cause
Reads return `0xE2` or timeout errors	Baud rate, parity, or stop bits mismatch with the slave
Intermittent garbage on long RS-485 runs	Missing or incorrect 120 Ω termination resistors
Bus works with one slave, fails with several	Duplicate slave addresses on the bus
Values look scrambled or nonsensical	Register map mismatch — wrong start address or misreading a float as two integers

Wrapping Up

The ESP32 handles Modbus RTU comfortably, and the code in this tutorial is enough to get real data flowing from an RS-485 slave device today. RTU is the right call for field-level wiring to sensors, meters, and PLCs where a wired serial bus makes more sense than a network connection.

From here, the natural next steps are adding retry/backoff logic around each poll, mapping out your specific device's full register table, and — if you're moving from prototype to a real deployment — considering hardware that removes the RS-485 wiring step entirely.

Build a Smart Building Automation Controller Using NORVI X

Bhanuka Gamachchige — Fri, 27 Mar 2026 11:29:04 +0000

Introduction

Modern buildings are packed with systems — HVAC, lighting, access control, and energy metering — but most of them run on separate proprietary controllers that don't talk to each other. The result is a building that's instrumented but not truly intelligent.

In this Instructable, you'll learn how to build a flexible, open-source smart building automation controller using the NORVI X platform. It's built on the ESP32-S3 microcontroller, supports industrial I/O, speaks Modbus RTU natively, and connects to the cloud over WiFi, Ethernet, or 4G — all at a fraction of the cost of traditional BMS hardware.

This guide covers a practical HVAC zone control system with remote monitoring, but the same hardware can handle lighting automation, energy metering, and access control.

Step 1: Understand the Problem With Traditional Building Automation

Before building anything, it's worth knowing why this matters. Traditional Building Management Systems (BMS) come with some frustrating limitations:

Proprietary controllers that need vendor-certified technicians to configure
No interoperability between subsystems — each zone or floor operates in a silo
Little to no native cloud/API connectivity
High licensing costs that price out small-to-medium commercial buildings
Long lead times and expensive replacement cycles when hardware reaches end-of-life

The goal of this project is to replace that complexity with a single open platform that any engineer can program, configure, and scale.

Step 2: Gather Your Components

Hardware (per zone controller)

1x NORVI CPU-ESPS3-X1 (ESP32-S3 with WiFi, Ethernet, RS-485)
1x NORVI X-AI4 (4x analog inputs, 4–20 mA, 16-bit ADC)
1x NORVI X-R4 (4x relay outputs)
1x NORVI X-DI4 (fast digital inputs)

Sensors & Actuators

Temperature & humidity sensor (4–20 mA output)
CO2 sensor (for demand-controlled ventilation)
Fan coil unit (controlled via relay)
Door/window contact sensors

Tools & Software

Arduino IDE or ESP-IDF
MQTT broker (local or cloud — e.g., HiveMQ, Mosquitto, AWS IoT)
Optional: Node-RED or Grafana for dashboarding ** Estimated cost per zone controller: ~$135–145 USD**

Step 3: Understand the System Architecture

Here's how the layers of the system fit together:

Layer	Component	NORVI X Module
Sensing	Temp, Humidity, CO2 sensors	X-AI4 (4–20 mA)
Output Control	HVAC relays, Fan Coil	X-R4 relay module
Contact Monitoring	Door/Window Sensors	X-DI4 digital inputs
Communication	Modbus RTU to BMS	Built-in RS-485
Connectivity	WiFi / Ethernet / 4G	Built-in on CPU
Edge Logic	Schedules, Alarms, Setpoints	ESP32-S3 firmware
Module	NORVI X Module	Core processing and integration layer

Each CPU module connects to I/O expansion boards via a dedicated expansion bus. You can stack up to 200 I/O points across a single controller — no rewiring, no new CPU needed.

Step 4: Wire Up the Hardware

Mount the NORVI CPU-ESPS3-X1 on a DIN rail in your control panel.
Attach the X-AI4 expansion module — connect your 4–20 mA temperature, humidity, and CO2 sensors to the analog input terminals.
Attach the X-R4 relay module — wire your fan coil unit switching circuits to the relay output terminals.
Attach the X-DI4 — connect door/window contact dry contacts to the digital input terminals.
Wire RS-485 A/B terminals to your upstream BMS or SCADA system (Modbus RTU).
Connect Ethernet or configure WiFi for cloud/dashboard access.

Tip: For remote plant rooms or retrofit sites with no wired network, use the NORVI CPU-ESPS3-X2 or X3 variant, which adds 2G/4G cellular connectivity. No local network infrastructure needed.

Step 5: Program the Controller

All logic runs locally on the ESP32-S3. Use the Arduino framework or ESP-IDF — no proprietary IDE or vendor cloud dependency required. A basic control loop looks like this:

#include <ModbusMaster.h>
#include <PubSubClient.h>

float readTemperature() {
  int raw = analogRead(AI4_CH0_PIN);
  return map(raw, 0, 65535, 0, 100); // 4-20mA to temperature
}

void controlFanCoil(float temp, float setpoint) {
  if (temp > setpoint + 0.5) {
    digitalWrite(RELAY_CH1_PIN, HIGH); // Fan coil ON
  } else if (temp < setpoint - 0.5) {
    digitalWrite(RELAY_CH1_PIN, LOW);  // Fan coil OFF
  }
}

void loop() {
  float temperature = readTemperature();
  controlFanCoil(temperature, 22.5); // 22.5°C setpoint
  publishToMQTT("building/zone1/temp", temperature);
  delay(5000);
}

Define your schedules, setpoints, alarm thresholds, and failsafe behaviour in firmware. Optionally expose configuration parameters over MQTT or a lightweight REST API.

Step 6: Set Up Cloud / Remote Monitoring

One NORVI X CPU isn't limited to HVAC. Add more expansion modules to cover:

Lighting automation — X-Q4/X-Q8 transistor outputs for 0–10 V dimming
Occupancy sensing — X-DI8/X-DI16 for PIR sensors and pushbutton overrides
Daylight harvesting — X-AV4 analog inputs for photocell sensors
Energy metering — RS-485 Modbus RTU to commercial energy meters

A single NORVI X controller can simultaneously manage HVAC zone control, occupancy-based lighting, and access logging — eliminating the need for separate controllers per subsystem.

For a 12-zone office building across three floors, deploy one NORVI X unit per zone and connect them all to a central data concentrator or SCADA system over Modbus RTU.

Step 8: Test and Deploy

Before deploying to site, run through this checklist:

Verify all analog input readings match expected sensor output ranges
Test relay outputs — confirm fan coil switching responds to setpoint logic
Verify Modbus RTU communication with your upstream BMS
Confirm MQTT telemetry is flowing to your dashboard
Simulate a network outage — confirm local failsafe logic holds
Test OTA update path before final installation

NORVI X vs Traditional Smart Building Hardware

Here's how NORVI X compares against the alternatives engineers typically Evaluate:

Capability	Traditional BMS	Dev Boards	IoT Gateways	NORVI X
Industrial I/O (DI/DO/AI/AO)	✔✔✔	Limited	✖	✔✔✔
Open Programming (C/C++)	✖	✔✔✔	✖	✔✔✔
RS-485 / Modbus RTU	✔✔✔	Manual wiring	✔✔	Native built-in
4G / LTE Cellular Option	Requires add-on	DIY	✔✔	✔✔✔
Modular I/O Expansion	Vendor-locked	✖	✖	Up to 200 I/O
Price Point	High	Very Low	Medium	$80–$150 USD

Conclusion

With NORVI X, you get industrial-grade I/O, open ESP32 programming, native Modbus RTU, and cloud connectivity — all in a modular platform that scales from a single zone to hundreds of I/O points

Estimated hardware cost per zone controller: ~$135–145 USD — a fraction of a traditional BMS controller, with full programming flexibility retained.

This approach is ideal for system integrators, OEM machine builders, smart building startups, and retrofit projects where legacy BMS hardware needs to be replaced with something open and scalable.

Note: NORVI X is not suitable for applications requiring strict IEC 61131-3 Ladder Logic compliance or certified safety functions (SIL/PLd). Those applications require dedicated safety PLCs.

More Resources

NORVI X Product Page: norvi.io/norvi-x
NORVI Shop: shop.norvi.lk
GitHub (code examples): github.com/IndustrialArduino
Technical Support: support@norvi.io | +94 77 111 1776

Building Multi-Year IoT Deployments: Inside the NORVI EC-M12-BC-C6-C-A LTE-M Logger

Bhanuka Gamachchige — Fri, 13 Mar 2026 03:34:59 +0000

Deploying a remote IoT data logger sounds straightforward — until you factor in power constraints, unpredictable weather, and the cost of maintenance visits to a location 200 km away.

For engineers working on industrial remote monitoring, water utilities, environmental sensing, or agricultural automation, battery life and rugged connectivity are the two factors that make or break a deployment.

This article breaks down how the NORVI EC-M12-BC-C6-C-A solves both — and what hardware decisions actually drive multi-year field life.

Why Most Remote Loggers Fail in the Field

Here's the uncomfortable truth: most IoT sensors consume very little power during operation. The real power draw comes from cellular transmission — and this is where many logger designs fail.

Older 2G/3G modems draw hundreds of milliamps during data bursts. On a standard 6,000 mAh lithium pack sending readings every 15 minutes, you're looking at months, not years.

The root problems are almost always:

Wrong modem technology — GPRS/3G radios burn 5–10× more power than modern LPWAN alternatives.
Aggressive MCU idle current — mainstream microcontrollers don't have true ultra-low-power sleep modes
Wrong battery chemistry — alkaline and lithium-ion both suffer from high self-discharge and poor cold-weather performance

Modern low-power IoT standards like LTE-M (Cat-M1) and NB-IoT were developed precisely to address the modem problem. Combined with the right MCU and battery chemistry, multi-year field life becomes achievable.

The Hardware Stack: Key Decisions

MCU: STM32L072CZT6TR

The logger runs on the STM32L072 — part of STMicroelectronics' ultra-low-power L0 family. This is a deliberate choice. The L072 is not the fastest or most capable MCU you could put in an IoT device; it's the one that draws the least current between measurement cycles.

Multiple low-power modes allow the processor to dramatically reduce draw while waiting to take the next reading. For a logger sampling every few minutes and transmitting every hour, the MCU spends the vast majority of its time in deep sleep. That idle current matters far more than clock speed.

Battery: 38,000 mAh LiSOCl₂

The device uses two ER34615H lithium thionyl chloride cells (19,000 mAh each) for a combined 38,000 mAh capacity.

LiSOCl₂ is worth understanding if you're specifying hardware for field deployments:

Chemistry	Self-Discharge / Year	Cold Weather	Capacity
Alkaline	~3–5%	Poor (capacity drops sharply)	Moderate
Li-ion	~2–3%	Moderate	High
LiSOCl₂	~1% or less	Excellent	Very high

For a device that may sit in a field cabinet through 5–10 winters, LiSOCl₂ is the correct answer. The chemistry is non-rechargeable, which some engineers see as a limitation — but for a true low-power deployment, it's a feature: no charging circuitry, no charge cycle degradation, no BMS complexity.

Cellular Modem: SIMCOM A7672

The A7672 supports LTE Cat-M1, NB-IoT (NB1 and NB2), and GSM/GPRS fallback — a multi-mode approach that matters for deployments where network availability varies by region or operator.

Band support covers B1/B2/B3/B4/B5/B8/B12/B13/B18/B19/B20/B26/B28/B39, plus quad-band GSM. In practice, this means you're not locked to a single operator or region.

Data rates are well-matched to the use case:

LTE Cat-M1: up to 588 kbps DL / 1,119 kbps UL
NB-IoT: up to 26 kbps DL / 62.5 kbps UL

For a logger sending timestamped sensor readings every 15–60 minutes, NB-IoT bandwidth is more than sufficient. And NB-IoT's deep penetration characteristics make it valuable for underground or basement installations where LTE signal is weak.

The 4–20 mA Inputs: Industrial Standard, Implemented Properly

The 4–20 mA current loop is the backbone of industrial instrumentation — pressure transmitters, flow meters, level sensors, temperature probes, and hundreds of other field devices. Its noise immunity over long cable runs makes it ideal for outdoor deployments where signal integrity matters.

The EC-M12-BC-C6-C-A provides:

2 analog inputs (0–20 mA range, 26V DC max)
ADS1115 16-bit ADC over I2C — high-resolution conversions
Configurable sensor excitation supply: 12V / 5V / 3.3V outputs

That last point is significant. Many loggers require separate field power supplies for 2-wire transmitters. Having a configurable excitation supply built into the logger simplifies wiring considerably and reduces the BoM for a deployment.

Local Storage and Time Integrity

Two features that often get overlooked in logger specifications — and that cause real pain in the field:

DS3231 RTC — The DS3231 is a temperature-compensated real-time clock with ±2 ppm accuracy. Even through cellular outages or power interruptions, timestamps remain accurate. This matters when you're stitching together time series data from multiple loggers.

MicroSD card slot (SPI) — When connectivity is lost — due to network outage, coverage gaps, or cellular module failure — the logger buffers readings locally. When connectivity is restored, the buffered data uploads, preserving continuity in your time series. Without local storage, you get gaps. Gaps in environmental or industrial monitoring data are often unacceptable.

RS-485 (half-duplex) is also available, opening up Modbus RTU integration for deployments where you need to pull data from multiple sensors on a shared bus.

Enclosure and Environmental Specs

IP Rating: IP67 (fully dustproof, 1m immersion)
Operating Temp: –40°C to +85°C
Enclosure: ABS + Polycarbonate
Mounting: Wall / Pole
Connector: M8 12-pin with cable gland
Dimensions: 146 × 90 × 50 mm
Shock: 30g operating / 50g non-operating (11ms)
Certifications: CE (EN 61131-2:2007, EN 61010-1:2010)

IP67 is the minimum you should specify for any outdoor exposed installation. The –40°C lower bound matters for cold-climate deployments — and it's where LiSOCl₂ chemistry earns its place, since alkaline cells lose a significant fraction of their rated capacity at sub-zero temperatures.

Checklist: Evaluating Any Long-Life IoT Logger

When you're specifying a logger for a multi-year unattended deployment, five areas determine real-world performance:

Battery chemistry — LiSOCl₂ for long life and cold weather; check self-discharge spec
Total capacity — calculate your expected current budget and verify runtime
MCU idle current — look for dedicated ultra-low-power MCU families (STM32L0/L4, nRF9160, etc.)
Modem technology — LTE-M or NB-IoT over GPRS/2G/3G for meaningful power reduction
Local storage — microSD or equivalent; essential for maintaining data integrity through outages
IP rating — IP67 minimum for outdoor; check operating temperature range against your environment

Use Cases Where This Architecture Makes Sense

Water utilities — pressure and flow monitoring across distribution networks
Environmental monitoring — river level, soil moisture, air quality nodes
Agriculture — irrigation pump monitoring, tank level sensing
Oil & gas — remote well-head pressure and temperature logging
Smart cities — utility metering, infrastructure health monitoring
Industrial assets — vibration, temperature, pressure on remote plant

The common thread: locations with no mains power, intermittent maintenance access, and a requirement for continuous data.

Summary

Genuine multi-year battery life in a cellular IoT logger requires every layer of the hardware stack to work together. The NORVI EC-M12-BC-C6-C-A shows what that looks like in practice:

38,000 mAh LiSOCl₂ capacity (2× ER34615H)
STM32L072 ultra-low-power MCU
SIMCOM A7672 LTE-M / NB-IoT modem with GSM fallback
2 × 4–20 mA industrial analog inputs with ADS1115 16-bit ADC
1 x RS-485
Built-in sensor excitation (12V/5V/3.3V)
DS3231 RTC + microSD local storage
IP67 enclosure, –40°C to +85°C operating range
CE certified for industrial environments

For more details or to request a datasheet: norvi.io

Building a Multi-Year Battery Life IoT Data Logger: A Deep Dive into Ultra-Low-Power Design

Bhanuka Gamachchige — Tue, 10 Feb 2026 08:12:28 +0000

Introduction

Ever wondered how industrial IoT devices achieve multi-year battery life while transmitting data over cellular networks? In this article, I'll walk you through a real-world implementation of an ultra-low-power industrial data logger that monitors diesel fuel levels remotely and achieves an impressive 3-11 year battery life.

We'll be using the EC-M12-BC-C6-C-A, a battery-powered device with an STM32L0 series microcontroller and a SIM7070 LTE modem – a common setup in industrial monitoring applications.

The Challenge

Remote monitoring systems face a critical tradeoff: you need frequent data updates for real-time insights, but each transmission cycle drains your battery. Cellular modems are particularly power-hungry, with peak currents reaching 840mA during network initialisation.

The goal? Design a system that can:

Read analog sensor data accurately
Transmit to cloud dashboard via 4G/LTE-M
Operate for years on primary lithium batteries
Handle harsh industrial environments

System Architecture

[4-20mA Fuel Sensor] → [STM32L0 MCU] → [SIM7070 Modem] → [4G Network] → [ThingsBoard Dashboard]

Hardware Components

MCU: STM32L0
Cellular: SIM7070 NB-IoT/LTE-M modem
Power: 2× ER34615H lithium batteries (19,000mAh each)
Sensor: 4-20mA diesel fuel tank level sensor

The Power Consumption Breakdown

Here's where it gets interesting. The system operates in three distinct stages:

Stage 1: Modem Initialization (60 seconds)

Average Current: 17.71mA
Peak Current: 840mA (during network registration)
Energy: 3.93 J

This is the power-hungry phase. The SIM7070 needs to:

Power up the RF circuitry
Search for cellular networks
Register with the tower
Establish GPRS/LTE connection

Key Design Decision: A 1000µF tantalum capacitor placed near the modem acts as a local energy reservoir, smoothing out the 30-40ms current spikes that can exceed 300mA.

Stage 2: Sensor Read + Data Transmission (7.5 seconds)

Average Current: 11.24mA
Energy: 0.31 J

During this phase:

Read 4-20mA sensor (fuel level)
Read battery voltage
Publish telemetry to ThingsBoard via MQTT
Disable all peripherals

Stage 3: Deep Sleep (15 minutes)

Average Current: 1.05µA
Energy: 0.0035 J

This is where the magic happens. The STM32L0 enters shutdown mode:

All peripherals powered down
Only RTC remains active
Occasional 2-3mA spikes for RTC maintenance (negligible impact)

The Math Behind Battery Life

With 38,000mAh capacity, here's the battery life estimation:

Average Current Formula:

I_avg = (I_sleep × T_sleep + I_active × T_active) / (T_sleep + T_active)

Results:

The 4× increase in sleep time gives you a 3.4× improvement in battery life. This demonstrates the power of duty cycling in embedded systems.

Software Implementation Highlights

Low-Power Mode Configuration

// STM32L0 shutdown mode configuration
#include <STM32LowPower.h>
void setup() {
  Serial.begin(9600);
  LowPower.begin();                   //Initiate low power mode
}
void loop() {
  Serial.println("Entering low power mode...");

  SPI.end();
  delay(1000);
  Wire2.end();
  delay(1000);


  digitalWrite(BOOST_EN, LOW);
  delay(1000);

  // === Fully cut power to GSM ===
  digitalWrite(GSM_POWER, HIGH);  // Depending on your wiring,   HIGH disables modem regulator
  delay(2000);

LowPower.shutdown(900000);
}

Efficient MQTT Publishing

The system uses MQTT over LTE for minimal protocol overhead:

void publishTelemetry() {
 int16_t adc0, adc1, adc2, adc3;

  adc1 = ads1.readADC_SingleEnded(1) * mA_Factor;
  adc2 = ads1.readADC_SingleEnded(2);


  float voltage2 = adc2 * 0.125 / 1000.0 / VOLTAGE_DIVIDER_RATIO;

  Serial.print("AIN1: "); Serial.print(adc0); Serial.println("  ");
  Serial.print("AIN2: "); Serial.print(adc1); Serial.println("  ");
  Serial.print("Voltage: "); Serial.print(voltage2); Serial.println("  ");


  float fuel_percent = (adc1 - 4.0) * 100.0 / 16.0;
  fuel_percent = constrain(fuel_percent, 0, 100);

  // Fuel height
  float fuel_level_mm = (fuel_percent / 100.0) * 1000;

  // Fault detection
  bool fuel_sensor_fault = false;
  if (adc1 < 3.6 || adc1 > 22.0) {
    fuel_sensor_fault = true;
  }

  StaticJsonDocument<200> doc;
  doc["fuel_level_percent"] = fuel_percent;
  doc["fuel_level_mm"]      = fuel_level_mm;
  doc["battery_voltage"]    = voltage2;
  doc["fuel_sensor_fault"]  = fuel_sensor_fault;

  String jsonStr;
  serializeJson(doc, jsonStr);

  mqtt.publish("v1/devices/me/telemetry", jsonStr.c_str());
  Serial.print("Published: ");
  Serial.println(jsonStr);

}

Sensor Fault Detection

The system monitors for open/short circuits in the 4-20mA loop:

< 3.8mA: Sensor fault (open circuit)
> 20.5mA: Sensor fault (short circuit)
4-20mA: Normal operation

Real-World Considerations

Cellular Signal Strength
Poor signal = higher power consumption. The modem will retry connections and transmit at higher power levels, significantly reducing battery life.
Sensor Current Impact
The 4-20mA sensor itself consumes power proportional to the measured value. A full tank (20mA) drains more power than an empty tank (4mA).
Temperature Effects
Lithium batteries lose capacity in extreme cold. Consider temperature-compensated battery life calculations for outdoor installations.
Network Protocol Choice
NB-IoT and LTE-M are specifically designed for IoT applications with lower power consumption than standard LTE. Choose wisely based on your region's network availability.

Lessons Learned

Duty cycling is king: The difference between 15-minute and 1-hour intervals is massive (3.36 vs 11.4 years).
Modem initialization dominates: Even though it's only 1 minute per cycle, it consumes 85% of the total energy per transmission.
Hardware matters: The STM32L0's 1.05µA shutdown current makes multi-year operation possible. A standard MCU would drain batteries in months.

Future Improvements

Implement adaptive transmission intervals based on fuel level change rate
Implement predictive maintenance alerts based on battery voltage trends

Conclusion

Building ultra-low-power IoT devices requires careful consideration of every milliamp-hour. By combining:

Efficient duty cycling
Ultra-low-power MCU sleep modes
Optimized cellular communication
Smart peripheral management

We achieved a system that can monitor remote industrial assets for over 3 years on battery power alone, with the potential to extend that to 11+ years with less frequent updates.

The complete source code and detailed setup instructions are available on GitHub.

Check the product (EC-M12-BC-C6-C-A) documentation.

Introducing the NORVI M12-B: 5+ Years of Maintenance-Free Utility Telemetry

Bhanuka Gamachchige — Thu, 18 Dec 2025 03:24:15 +0000

NORVI is proud to announce the launch of the M12-B series battery-powered NB-IoT data logger, a breakthrough in remote utility monitoring. Designed for water, gas, and other utility applications, this device combines long-lasting battery life, rugged design, and reliable connectivity, offering a truly maintenance-free solution for developers and operators.

Long-Life Battery: Over 5 Years of Continuous Operation

At the heart of the NORVI M12-B is a high-capacity, energy-optimized battery designed to power the device for more than five years without any maintenance. This means utilities and industrial operators can deploy telemetry devices in remote or hard-to-reach locations without worrying about frequent battery replacements. Developers can explore the life estimation to see real-world battery performance data and plan deployments with confidence.

Power Consumption Analysis: How NORVI Achieves Multi-Year Operation

The long battery life of the M12-B is made possible by careful power optimization across two main stages:

Modem Initializing and Data Sending Stage

During the active phase, the device performs critical operations such as:

Initializing the NB-IoT modem
Connecting to the network
Reading the DJLK ultrasonic level sensor via RS-485
Transmitting data packets to the ThingsBoard cloud over MQTT

On average, the system draws 31.78 mA for about 70 seconds. The SIM7070 LTE modem generates high-current spikes up to 0.56 A, which are handled by two lithium batteries connected in parallel.

A 1000 µF tantalum capacitor placed near the modem acts as a local energy reservoir, supplying instantaneous surge current, while the batteries maintain the average load.

According to the ER34615H(D) lithium battery datasheet, each cell can safely deliver 300 mA pulses for 100 milliseconds every 2 minutes. Observed modem pulses (30–40 milliseconds) stay within this safe operating range, ensuring reliable initialization without battery stress.

MCU Sleep Mode (Shutdown Mode)

After data transmission, the MCU enters shutdown mode, powering down most peripherals and system clocks. Only the Real-Time Clock (RTC) remains active to track time.

In this low-power state, the system draws approximately 1.22 µA for a duration of 15 minutes.

Battery Life Estimation

EC-M12-BC-C6-C consists of two 19,000 mAh . So it has a total of 38,000 mAh battery power. As for the above collected data we have obtained battery life estimation when data is sent every 15 minutes and every 1 hour.

Below shows the formula to calculate average current and battery life for different intervals which help you to estimate the battery life for your application.

Overall System Power Profile

The average current flow across the full duty cycle is about 2.39 mA, with a charge consumption of 2.24 C, supporting multi-year operation on battery without maintenance.

Reliable NB-IoT Connectivity

The M12-B leverages NB-IoT Cat NB1/NB2 connectivity, providing stable and secure data transmission even in challenging environments. Its deep coverage ensures that basements, underground meters, and remote infrastructure remain connected, while its low-power design ensures long-term operational efficiency.

Rugged and Flexible Design

Built for demanding utility environments, the NORVI M12-B is IP67-rated, fully protected against dust and water. It supports a wide range of sensors, including:

Flow meters and pressure sensors
Pulse counters
Analog voltage/current inputs
RS-485 Modbus RTU devices

This flexibility allows developers to integrate the device with existing infrastructure or design custom telemetry solutions with ease.

Maintenance-Free Deployment

The combination of long-life battery, rugged housing, and NB-IoT connectivity enables true maintenance-free deployments. Once installed, the M12-B operates autonomously for 5+ years, transmitting real-time data without the need for field intervention. This drastically reduces operational costs and human resources, making it ideal for large-scale utility networks.

Custom IoT Solutions and White-Labeling

Looking to bring your own IoT product to market? NORVI offers end-to-end custom IoT product development, from hardware design to cloud integration. Whether it’s a smart water meter, gas monitoring solution, or industrial controller, our team can turn your ideas into reliable, ready-to-market products with NB-IoT, LoRaWAN, or Wi-Fi connectivity.

Need a white-label solution? NORVI’s offerings let you launch branded IoT devices quickly, while we handle engineering, design, and manufacturing. Focus on your business, while we provide proven, maintenance-free devices optimized for long-term performance.

Accelerate your projects further with rapid prototyping, flexible sensor interfaces, and developer-friendly platforms, ensuring seamless integration and faster time-to-market.

Conclusion

The NORVI M12-B NB-IoT Data Logger sets a new standard for utility telemetry. With 5+ years of maintenance-free operation, rugged IP67 design, and optimized power consumption, it empowers developers and businesses to deploy scalable, reliable, and long-term monitoring solutions.

Explore the life estimation for battery performance and plan your deployments with confidence. NORVI makes smart utility monitoring maintenance-free, developer-friendly, and ready for real-world applications.

DEV Community: Bhanuka Gamachchige

Monitoring Water Networks Where There's No Power or Wi-Fi

Step One: Sort Your Sites by Power, Not by Sensor

The Unpowered Case Is Where It Gets Interesting

Where Each Pattern Shows Up in the Field

A Minimal Payload Example

The Compliance Angle Utilities Actually Care About

Wrapping Up

Monitoring a Borehole With No Power, No Wi-Fi, and Nobody Standing Next to It

Sensor choice matters more than I expected

The real trick to multi year battery life

Alerts that don't depend on your cloud staying up

If you're building or speccing something similar

Getting Started with Modbus RTU on ESP32

What You'll Build

Prerequisites

A 60-Second Modbus Primer

Modbus RTU over RS-485

Step 1 — Wire the Hardware

Skip the transceiver wiring

Step 2 — Install a Modbus Library

Step 3 — Write the RTU Master Sketch

Reliability Checklist for Production (RTU)

Troubleshooting Common Issues (RTU)

Wrapping Up

Further Reading and Resources

Build a Smart Building Automation Controller Using NORVI X

Introduction

Step 1: Understand the Problem With Traditional Building Automation

Step 2: Gather Your Components

Hardware (per zone controller)

Sensors & Actuators

Tools & Software

Step 3: Understand the System Architecture

Step 4: Wire Up the Hardware

Step 5: Program the Controller

Step 6: Set Up Cloud / Remote Monitoring

Step 8: Test and Deploy

NORVI X vs Traditional Smart Building Hardware

Conclusion

More Resources

Building Multi-Year IoT Deployments: Inside the NORVI EC-M12-BC-C6-C-A LTE-M Logger

Why Most Remote Loggers Fail in the Field

The Hardware Stack: Key Decisions

MCU: STM32L072CZT6TR

Battery: 38,000 mAh LiSOCl₂

Cellular Modem: SIMCOM A7672

The 4–20 mA Inputs: Industrial Standard, Implemented Properly

Local Storage and Time Integrity

Enclosure and Environmental Specs

Checklist: Evaluating Any Long-Life IoT Logger

Use Cases Where This Architecture Makes Sense

Summary

Building a Multi-Year Battery Life IoT Data Logger: A Deep Dive into Ultra-Low-Power Design

Introduction

The Challenge

System Architecture

Hardware Components

The Power Consumption Breakdown

Stage 1: Modem Initialization (60 seconds)

Stage 2: Sensor Read + Data Transmission (7.5 seconds)

Stage 3: Deep Sleep (15 minutes)

Software Implementation Highlights

Low-Power Mode Configuration

Efficient MQTT Publishing

Sensor Fault Detection

Real-World Considerations

Lessons Learned

Future Improvements

Conclusion

Introducing the NORVI M12-B: 5+ Years of Maintenance-Free Utility Telemetry

Long-Life Battery: Over 5 Years of Continuous Operation

Power Consumption Analysis: How NORVI Achieves Multi-Year Operation

Modem Initializing and Data Sending Stage

MCU Sleep Mode (Shutdown Mode)

Battery Life Estimation

Overall System Power Profile

Reliable NB-IoT Connectivity

Rugged and Flexible Design

Maintenance-Free Deployment