How to Monitor Modbus TCP Devices Without the Middleware Bloat
If you have ever tried to connect a power meter to a dashboard, you know the usual path: MQTT broker → flow engine → time-series database → visualization layer. That is four services, four configuration files, four failure points, and 2 to 4 GB of RAM before you even write a single line of application logic.
There is a simpler way. This guide shows you how to read Modbus TCP registers directly and stream them to a dashboard with nothing but a single binary.
What You Actually Need
Let's be honest about what industrial monitoring requires:
- Read registers from a Modbus TCP device
- Store the values somewhere
- Show them on a screen
- Alert when something goes wrong
That is it. Everything else — MQTT topics, Node-RED flows, InfluxDB buckets, Grafana panels — is abstraction that you are paying for in RAM, complexity, and support tickets.
The Direct Approach
Instead of routing data through middleware, talk to the device directly. A Modbus TCP connection is just a TCP socket with a simple request-response protocol:
Client → "Read holding register 40001"
Device → "Value is 230.5"
Client → "Read holding register 40003"
Device → "Value is 5.2"No brokers. No topics. No translation layers. The binary opens a socket, sends a Modbus frame, parses the response, and stores it. That is exactly what Voltrus does. For a broader view of how this fits into an overall system design, see our guide to SCADA architecture.
Configuring a Device
With a direct approach, configuration is minimal. You need five things:
- IP address and port — usually port 502
- Unit ID — typically 1 for a single device
- Polling interval — 1000ms is common, 100ms for critical loops
- Register addresses — your device's manual tells you these (and understanding the control logic behind those registers starts with PLC programming and ladder logic)
- Data type — Float32, Int32, Uint16, etc.
That is the entire configuration. No Docker compose files. No environment variables spread across three services.
What the Typical Stack Hides From You
Let's look at what each middleware layer actually costs:
- MQTT broker (Mosquitto/EMQX): 50-200 MB RAM, another service to monitor, another config file to maintain
- Flow engine (Node-RED): 150-400 MB RAM, flows break on version updates, visual programming becomes visual spaghetti
- Time-series DB (InfluxDB/TimescaleDB): 300 MB-1 GB RAM, retention policies, continuous queries, backup strategy
- Visualization (Grafana): 100-300 MB RAM, panel configuration, datasource management, user auth
- Docker overhead: 10-20% memory overhead per container, image updates, volume management
Total: 600 MB to 2 GB of RAM, four config files, four services to restart when something breaks, and a diagram that looks like a plate of noodles.
The Single-Binary Alternative
A direct-approach SCADA tool embeds everything into one process:
- Modbus client — built in, talks directly to devices
- SQLite database — embedded, zero configuration, single file
- Web server — serves the dashboard and API
- Dashboard — single-page app with real-time SSE streaming
Total: No dedicated server needed. One config file. One binary to start. One log to read when something goes wrong.
When You Actually Need Middleware
I am not saying middleware is never useful. It makes sense when:
- You have 50+ devices across multiple sites and need a central broker
- You are building a platform product, not a per-client deployment
- You need complex event routing that changes frequently
But for a typical integrator deploying monitoring for a single plant or building? You are paying for flexibility you will never use.
Getting Started in Under 3 Minutes
If you want to try the direct approach:
- Download the binary for your platform
- Copy the example config and add your device's IP and registers
- Run the binary
- Open the dashboard at
http://localhost:3000
No brokers to configure. No databases to install. No Docker to orchestrate. Just a device, a binary, and a browser.
Frequently Asked Questions
Do you need an MQTT broker to monitor Modbus TCP devices?
No. A single-binary SCADA tool like Voltrus can read Modbus TCP registers directly over a TCP socket, store the values in an embedded database, and serve them to a web dashboard — all without an MQTT broker, flow engine, or separate time-series database. The typical MQTT-based stack (Mosquitto + Node-RED + InfluxDB + Grafana) uses 600 MB to 2 GB of RAM and introduces four failure points. A direct approach does the same job with one process and roughly 50 MB of RAM.
What information do you need to connect to a Modbus TCP device?
You need five things: the device IP address and port (usually 502), the Unit ID or slave address (typically 1), the polling interval (1000ms is common), the register addresses from the device manual, and the data type for each register (Float32, Int32, Uint16, etc.). That is the entire configuration — no Docker compose files, no environment variables across multiple services.
How much RAM does a typical Modbus monitoring stack use?
The typical middleware stack (MQTT broker 50-200 MB, Node-RED 150-400 MB, InfluxDB 300 MB-1 GB, Grafana 100-300 MB, plus Docker overhead) totals 600 MB to 2 GB of RAM. A single-binary SCADA tool that embeds the Modbus client, database, and web server in one process uses roughly 50 MB. For a single-plant deployment, the middleware approach pays for flexibility that goes unused.
When does middleware make sense for Modbus monitoring?
Middleware makes sense when you have 50+ devices across multiple sites requiring a central broker, when you are building a platform product rather than a per-client deployment, or when you need complex event routing that changes frequently. For a typical system integrator deploying monitoring for a single plant or building with 10-30 Modbus devices, direct polling is simpler, faster, and easier to maintain.
Try It Yourself
Voltrus is a single-binary SCADA tool built for system integrators who are tired of middleware.
Learn More About Voltrus