What is it
An industrial controller on DIN rail, prepared by us with the PlantPulse image already inside. It mounts in the panel, connects to the counters and starts sending data: there is no operating system to install or configuration to invent on site.
Why not a Raspberry Pi
The real question is not whether it works, but who answers three years from now. The module we use is built for the electrical panel and declares this with numbers: average time between failures of 30.7 years at 25 °C, EN 61131-2 compliance, UL certification, temperature range from -25 to +55 °C, and — what matters most in a multi-year contract — guaranteed model availability until 2036.
A hobbyist Pi goes out of production, changes revision, and the card you installed for a customer is no longer available as an identical replacement. Out of ten installations it becomes a maintenance problem; out of one hundred it becomes the main issue.
| Processor | ARM Cortex-A76 quad core 2.4 GHz |
| Memory | 4 or 8 GB LPDDR4X |
| Storage | 32 GB eMMC |
| Network | 2 × Gigabit Ethernet |
| Field | RS485 (Modbus RTU), optional CAN FD |
| Security | TPM 2.0, verified boot |
| Environment | -25 / +55 °C, DIN rail mount |
| Standards | EN 61131-2, UL, CE/UKCA |
| System | Debian with real-time kernel, containers |
| Remote Access | ObjZNet, zero trust network on OpenZiti |
How do we get there without the customer opening anything
A node in an electrical panel is behind the customer's firewall, and the request to open an incoming port is where many projects stall — rightly so, because an open door to a plant is a risk that the IT manager takes on for life.
The node mounts ObjZNet, our zero-trust network: it is the node to open the connection to the outside, and from that channel we pass through. The client exposes nothing, has no ports listening, does not touch its own network rules. Traffic is end-to-end encrypted — even our transit routers forward data they cannot read — and the agent is a single static binary, with no runtime or libraries to install on the device.
This is what makes the two promises below a reality: without a way to reach the node, "remote deployment" and "update channel" would be just words.
The base node reads Modbus RTU and TCP, which covers most counters. When the plant has signals that Modbus does not carry — a clean contact, a 4-20 mA sensor, a PROFINET bus — an additional module is added to the rail, without changing the node.
Inputs and outputs
| Module | What it does | Price |
|---|---|---|
| DI | 16 digital inputs | 181 € |
| DO | 16 digital outputs | 196 € |
| RO | 10 relay outputs, to control | 176 € |
| DIO | 14 digital inputs and 14 digital outputs | 225 € |
| MIO | mixed analog and digital inputs and outputs | 235 € |
| AIO | 4 analog inputs, 2 outputs, 4 RTD probes | 365 € |
| Module | What it does | Price |
|---|---|---|
| M-Bus 868 MHz | heat and water meters via radio | 136 € |
| CAN Multi-Master | existing CAN network in installation | 144 € |
| M-Bus VHP 169 MHz | long-range radio counters | 161 € |
| EtherCAT | access to an EtherCAT network | 210 € |
| PROFIBUS | older installations, still very common | 223 € |
| EtherNet/IP | Rockwell / Allen-Bradley world | 223 € |
| PROFINET IRT | access to a PROFINET network | 235 € |
L-M-Bus deserves its own line: it is the standard for heat and water meters, and in most buildings it is already installed. Often nothing needs to be touched — just read it.
The modules are mounted alongside the node and are powered from the same connector: they are recognized at startup, there is no configuration to redo.
The pre-configured image, remote deployment, and update channel: the same version arrives on all installed nodes without having to manually configure each one.

