DEV Community: Bhanuka Gamachchige

What Actually Matters When Choosing an ESP32 DIN-Rail Controller

Bhanuka Gamachchige — Thu, 03 Sep 2026 14:00:47 +0000

ESP32-based controllers are becoming more common in industrial automation, particularly for smaller machines, monitoring systems, data acquisition, and Industrial IoT applications.

However, choosing an ESP32 controller for an industrial panel is very different from choosing a development board for a prototype.

Once the controller is installed inside a cabinet, power requirements, I/O capacity, communication interfaces, mounting, and long-term maintenance become much more important.

Here are some of the main factors to consider when selecting an ESP32-based DIN-rail controller.

Start With the Power Supply

Many standard ESP32 development boards are designed around 5V or USB power.

That works well on a development bench, but industrial control panels commonly use 24VDC power supplies.

You can add a separate DC-DC converter, but this also adds more wiring, components, and potential failure points.

For industrial installations, it is usually better to choose a controller designed to work directly with the panel power supply.

Useful features include:

24VDC-compatible power input
Input protection
Industrial terminal connections
Stable operation inside control cabinets

This keeps the installation cleaner and avoids adapting a standard development board for an industrial environment.

Fixed I/O or Modular I/O?

The next question is how much I/O the application requires.

Fixed-I/O controllers can work well when the same machine or panel design is being produced repeatedly.

If every installation uses the same number of digital inputs, analog inputs, and outputs, fixed I/O can simplify both engineering and purchasing.

Modular systems become more useful when requirements change from one project to another.

A CPU-plus-expansion architecture allows the controller to be configured based on each machine's requirements.

Typical expansion options may include:

Digital inputs
Digital outputs
Relay outputs
Analog inputs
Analog outputs
RTD or temperature inputs
Additional communication interfaces

For OEMs and machine builders, modular I/O can reduce the need to redesign the controller architecture whenever the application changes.

Communication Interfaces Matter

Communication requirements are another important part of controller selection.

RS-485 and Modbus RTU are still widely used in industrial automation.

They are commonly used for communication with:

Variable frequency drives
Energy meters
Industrial sensors
Remote I/O modules
Legacy field devices

Ethernet becomes important when the controller needs to communicate with SCADA systems, Modbus TCP devices, local servers, or other equipment on the plant network.

Wi-Fi can also be useful for local monitoring or configuration.

Cellular connectivity becomes particularly valuable when the system is installed at a remote or unmanned location where Ethernet or Wi-Fi infrastructure is unavailable.

Check the Mechanical Design

Mechanical design may seem less important than processor specifications, but it can make a significant difference during panel assembly.

A controller designed for industrial use should ideally provide:

TH35 DIN-rail mounting
Screw or push-in terminals
Clearly identified I/O connections
A cabinet-friendly enclosure
Accessible communication ports

Trying to mount a standard ESP32 development board inside a finished electrical cabinet usually requires additional adapters, converters, terminal blocks, and mounting hardware.

A purpose-built DIN-rail controller avoids much of that extra work.

Consider Firmware and Long-Term Maintenance

One major advantage of ESP32-based controllers is access to open development environments such as Arduino IDE and ESP-IDF.

This can reduce dependence on proprietary PLC programming software and licensing.

However, there is also a trade-off.

With an ESP32 system, the development team may have more responsibility for:

Firmware development
Testing
Version control
Debugging
Firmware updates
Long-term software maintenance

A traditional PLC generally provides a more standardized programming and maintenance environment.

ESP32-based controllers provide greater flexibility, but the engineering team needs to consider who will maintain the firmware several years after the machine has been installed.

Comparing ESP32 DIN-Rail Controllers

Before selecting a controller, it helps to compare different architectures based on connectivity, I/O, expandability, and application requirements.

NORVI provides an overview of industrial ESP32 controller options, including fixed, modular, and communication-enabled configurations:

Explore ESP32 DIN Rail Controllers

This can provide a useful starting point when comparing controller architectures for industrial automation projects.

Final Thoughts

Selecting an industrial ESP32 controller should involve more than checking the processor, memory, or number of GPIO pins.

The complete installation needs to be considered.

Power supply compatibility, I/O architecture, communication interfaces, DIN-rail mounting, and long-term firmware maintenance can have a much greater impact on the finished system.

For many smaller automation and Industrial IoT applications, an ESP32-based DIN-rail controller can provide a flexible alternative to a traditional PLC, particularly when custom firmware and connectivity are important.

Disclosure: I work on content related to NORVI products. The NORVI link above is included as a relevant reference for comparing industrial ESP32 DIN-rail controller options.

Two Patterns for Unattended Industrial Monitoring: When There's No Power and When There's No Room for Cloud Dependency

Bhanuka Gamachchige — Tue, 01 Sep 2026 12:24:31 +0000

Most articles about industrial IoT talk about connectivity as if it's one problem. In practice, “remote monitoring” means very different things depending on what you're actually monitoring. A borehole in the middle of a field and a transformer panel in a substation both count as remote assets, but they fail you in completely different ways if you get the design wrong. One has no power and no network anywhere nearby. The other has both, but the cost of losing local control for even a few seconds is a transformer that overheats without anyone knowing.

We've been working through both cases recently, and the contrast turned out to be a useful way to think about edge design in general. Here's what we learned from each.

Case one: monitoring something with no power and no wired networks

Boreholes are a genuinely hard environment to instrument. Sites are often kilometers apart across a wellfield, there's no mains supply anywhere near the wellhead, and running a wired network out to each one isn't realistic. The traditional answer is a manual dip reading: someone drives out, drops a tape measure, writes down a number, and drives to the next site. It works, but it tells you nothing about what happened between visits, and by the time a level problem shows up on a clipboard, a pump may have been running dry for days.

The obvious fix is a battery-powered logger with its own cellular connection, so the site doesn't need mains power or a local network at all. That part isn't controversial. The harder part is making the battery actually last long enough that a deployment is worth doing in the first place. A node that needs a battery swap every six months across a wellfield of forty sites is not a solution, it's a maintenance burden.

The detail that actually matters here is how the device decides when to transmit. Logging the sensor frequently is cheap, since it just means waking up, taking a reading, and going back to sleep. Transmitting over cellular is expensive by comparison, since keying up a radio and holding a connection burns far more energy than a local read. So instead of transmitting every reading, a transmit-on-change approach only keys up the radio when the water level has moved meaningfully, plus a periodic heartbeat so you know the node is still alive. Battery life isn't a fixed number, it depends heavily on that interval. A fixed hourly reporting schedule typically lands in the 4-5 year range in NORVI's own field data. Transmit-on-change pushes toward the upper end of that, and beyond it, since most hours generate no transmission at all, but the exact gain depends on how often the water level actually moves at a given site.

The other variable worth mentioning is sensor choice. A 316L stainless submersible sensor lowered directly into the water column is the established approach and holds up well for long-term immersion. A tube-type sensor, where the sensing head stays accessible at the wellhead and reads the water column through a tube run into the borehole, keeps the sensing electronics out of the water, which can make servicing easier. Field life for either type comes down mainly to the sensor's own current draw, not where the head sits, and how consistently the installation gets maintained. Neither is universally right, it depends on the installation and how the site will be maintained over its life.

We wrote up the full comparison, along with real battery-life numbers from an 80-meter borehole deployment, in more detail here: NORVI's borehole and groundwater level monitoring solution.

One more thing worth calling out on this side of things is cellular technology choice. The modem used in this class of logger supports NB-IoT, LTE-M (Cat-M), and 2G fallback, and NB-IoT tends to be the best default where it's supported, since it's built for low-power, deep-coverage scenarios. Coverage quality itself also matters more than people expect. A node reaching for a weak signal transmits harder to get its data out, and that alone can meaningfully shorten how long the battery lasts, which is part of why matching the radio technology to the actual site conditions matters more than defaulting to whatever's newest.

Case two: monitoring something where local control has to survive a lost connection

Transformer winding temperature monitoring is close to the opposite problem. A transformer panel isn't short on power, and it's usually not far from a network connection either. The real constraint is that temperature monitoring on a transformer isn't just a nice-to-have data feed, it's tied to protection logic. If a winding gets too hot, something needs to happen locally and immediately, whether that's starting forced cooling, raising an alarm, or issuing a trip request. None of that can be allowed to depend on whether a cloud service happens to be reachable at that moment.

For dry-type and cast resin transformers, the sensing side is usually Pt100 or Pt1000 RTDs embedded in or near the winding, sometimes with an extra RTD for ambient temperature so you can tell a genuine winding heating event apart from a wider ventilation problem. A typical setup assigns three channels to the three phase windings and a fourth to ambient or another manufacturer-provided point, using a four-channel RTD input module feeding into the main controller - in our deployments, a NORVI X CPU with its built-in TFT display and microSD logging, paired with a relay expansion module for the alarm outputs.

The design principle that matters most here is keeping the alarm logic on the device itself, entirely independent of whether a network connection exists at that moment. The controller reads the RTDs and shows live winding and ambient temperatures directly on its built-in display, so a technician standing at the panel can see current status without needing a live network link at all. When a reading crosses a configured threshold, the controller latches a relay output on a relay expansion module - driving forced cooling, an alarm light, or a horn - and steps that response up through a cooling stage, a high alarm, and a high-high or trip condition as things get worse. None of that decision-making touches the network. At the same time, every reading is written to the onboard microSD card, so if connectivity drops out entirely, the device keeps a complete local record instead of leaving a gap: once the link comes back, historical trending picks up from an unbroken log rather than a blank stretch. Only after the alarm logic and local logging are already handled does the data get forwarded to a dashboard, SCADA system, or cloud platform for visibility and historical trending. That ordering is deliberate. Cloud connectivity is genuinely useful for trend analysis, remote visibility, and maintenance reporting, but it should never be a link in the chain that has to hold for a protective action, or even basic data continuity, to happen.

It's worth being direct about something here too: none of this replaces the transformer manufacturer's actual protection settings. Fan, alarm, and trip temperatures vary by transformer design and thermal class, so the values used in any deployment need to come from the transformer's own documentation rather than a generic table. The monitoring system's job is to apply those approved limits reliably, not to invent new ones.

We went into the wiring layout, channel assignment, and staged alarm approach in more detail here, including relevant standards like IEC 60076-11 and IEEE C57.134: NORVI's transformer temperature monitoring solution.

The common thread

These two cases sit at opposite ends of what “remote” means, but the underlying design principle ends up being the same: figure out what the site can't guarantee, and don't build the system's most important behavior around assuming it will be there. For the borehole, what's missing is power and a network, so the answer is a device that can run for years on a battery and only spends energy on communication when it actually needs to. For the transformer, power and network are usually fine, but a live cloud connection can't be guaranteed at the exact moment it matters, so the answer is keeping protective logic local and treating remote visibility as an addition on top, not a dependency underneath.

If you're working on a similar problem, whether it's pipeline pressure, remote pump stations, or any other asset where the site doesn't give you everything you'd like, the question worth asking early is which of these two failure modes you're actually designing around. The right answer usually isn't more connectivity everywhere, it's being precise about which parts of the system genuinely need to survive without it.

Choosing a Cellular Modem for Your ESP32 Industrial Controller

Bhanuka Gamachchige — Fri, 21 Aug 2026 15:46:33 +0000

Most connectivity problems on an industrial site aren't RF problems, they're organizational ones. The plant Wi-Fi is IT-guarded, the pump house is out of range, and the machine you're shipping to a customer has no idea what network it'll land on. The fix a lot of teams land on eventually is the same one: stop depending on someone else's network and put a modem on the board.

This is a rundown of how that plays out in practice across four device classes, LTE vs LTE-M vs NB-IoT, and the modems that actually ship in each. Every part number below is cross-checked against live datasheets, not written from memory.

The radio decision, before the product decision

Four radio classes cover almost every industrial deployment. Pick the radio for the job first, then match a product to it.

4G LTE (Cat 1 / Cat 4) — highest data rate, lowest latency. Use it for real-time control, heavy MQTT publish rates, or anything that can't tolerate a slow uplink.
LTE-M (Cat-M1) — a middle ground. Handles mobility, still reasonable on power, more headroom than NB-IoT for sensors that need it.
NB-IoT (Cat-NB1) — best coverage penetration, lowest power draw, worst throughput. The right fit for fixed, low-data, battery-powered nodes.
2G fallback — legacy, but still the coverage floor in some regions, and useful as a last-resort path to keep OTA/debug access alive when NB-IoT roaming is patchy.

Modem-to-product mapping

Four modems, four different jobs. This is the part worth checking before you spec a BOM:

Four device classes, one design principle

NORVI GSM — modem built into the PLC

A DIN-rail controller (9–32V DC) with the cellular modem on the same board as the I/O. Nine I/O configurations across relay, transistor, and analog outputs. Ships in 4G LTE (-L, Quectel EC25) and 2G (-G, SIMCom SIM800) variants, the latter aimed at regions where 2G is still the coverage floor. Backup links: Wi-Fi and Ethernet. This is the pick when you want the controller itself online with no separate gateway box.

NORVI X — modular PLC, cellular on the CPU

ESP32-S3 dual-core at 160MHz, up to 200 I/O points via hot-swap modules, 24V DC panel power. Every CPU variant ships with Ethernet, RS-485, Wi-Fi, and Bluetooth as standard; the cellular CPUs (X2 with SIMCom A7672, X3 with Quectel EC25) add two antenna connections on top of that. The base X1 CPU has no modem at all if you don't need one. This is the lineup's answer when you want cellular alongside Ethernet as fallback, or a full expandable gateway.

EC-M12 — battery-powered, no grid power required

An STM32L072 ultra-low-power MCU in an IP67 sealed node, running SIMCom SIM7070 (NB-IoT/LTE-M/2G fallback) against a 38,000mAh Li/SOCl2 pack rated for 5+ years unattended. Five I/O configurations: dual 4-20mA analog, RS-485/Modbus, dual digital, mixed digital+analog, and strain gauge. Notably it uses an internal antenna, a deliberate tradeoff to keep the IP67 seal intact rather than punching a hole for an external connector.

Agent One — Modbus/sensor bridge, no PLC replacement

A low-I/O node built to wire in parallel to an existing Modbus network or sensor set and push straight to MQTT. SIM7600 covers the 4G LTE variant family, with NB-IoT and LoRa variant families for power- or range-constrained deployments. If the goal is cellular telemetry on equipment that already exists, this skips replacing anything.

Antenna, SIM, and carrier notes that actually matter in the field

DIN-rail devices (GSM, X) ship with external antennas: SMA for cellular, RP-SMA for Wi-Fi/Bluetooth. X carries two separate antenna connections.
EC-M12 uses an internal antenna to preserve the IP67 rating, so there's nothing external to break, unseal, or get stolen.
All cellular NORVI devices take a nano SIM; eSIM is available on NORVI X and EC-M12.
Mount external antennas outside metal enclosures. A steel panel behaves like a Faraday cage, and cellular antennas should stay clear of VFDs and contactors to cut EMI.
NB-IoT roaming is genuinely patchy, it's a network-level reality, not a device limitation, which is why 2G or 4G fallback paths matter for keeping an OTA/debug path alive.
Field-tested global IoT SIM providers: 1NCE and Things Mobile.

When cellular is the wrong call

It isn't always the right answer. Skip it when the system needs to run fully offline with no future monitoring or remote-support requirement, when there's nobody on the team who can own embedded firmware work (see NORVI's GitHub for example firmware and libraries before ruling this out), or when recurring SIM costs don't make sense against a site that already has solid Ethernet or Wi-Fi. In that last case, a wired ESP32 controller does the same job for less ongoing cost.

Reference

Full spec sheets, the modem comparison table, and datasheet links for all four device classes are maintained on NORVI's ESP32 industrial IoT controller (cellular & 4G LTE range) page, cross-checked against live product datasheets rather than written from memory.
Documentation hub (per-device datasheets, application guides): https://norvi.io/docs/
GitHub (firmware examples, libraries): https://github.com/NORVIControllers
Contact / technical consultation: https://norvi.io/contact-us/
If you're speccing a build and want a second opinion on modem choice or antenna placement, NORVI's engineering team takes free technical consultations.

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

What Actually Matters When Choosing an ESP32 DIN-Rail Controller

Start With the Power Supply

Fixed I/O or Modular I/O?

Communication Interfaces Matter

Check the Mechanical Design

Consider Firmware and Long-Term Maintenance

Comparing ESP32 DIN-Rail Controllers

Final Thoughts

Two Patterns for Unattended Industrial Monitoring: When There's No Power and When There's No Room for Cloud Dependency

Case one: monitoring something with no power and no wired networks

Case two: monitoring something where local control has to survive a lost connection

The common thread

Choosing a Cellular Modem for Your ESP32 Industrial Controller

The radio decision, before the product decision

Modem-to-product mapping

Four device classes, one design principle

NORVI GSM — modem built into the PLC

NORVI X — modular PLC, cellular on the CPU

EC-M12 — battery-powered, no grid power required

Agent One — Modbus/sensor bridge, no PLC replacement

Antenna, SIM, and carrier notes that actually matter in the field

When cellular is the wrong call

Reference

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