Node-RED, Modbus, and MQTT for Industrial IoT: Moving Field Data to Cloud Platforms
Node-RED Modbus MQTT workflows help industrial teams turn selected field-device values into structured messages for IoT platforms. The core task has 3 parts: read Modbus data, add meaning at the edge, and publish usable MQTT payloads upstream. Robustel EG5120 edge computig gateway is a practical reference for this workflow because it supports RobustOS Pro, Docker containers, 2× RS-232/RS-485 ports, native Modbus TCP/RTU, MQTT-to-cloud bridging, and RCMS remote management.
The main problem is not moving data from point A to point B. Modbus register values need at least 5 context fields—tag name, unit, timestamp, equipment ID, and quality status—before most IoT platforms can use them. Node-RED should be treated as the flow layer between Modbus collection and MQTT publishing. It can help map, filter, format, and route data, but protocol support depends on installed nodes, gateway model, runtime setup, and project configuration.
Why Modbus Register Data Needs an MQTT Message Plan
Many industrial devices already expose useful data through Modbus. PLCs, meters, drives, controllers, and field devices may provide production counts, alarm states, energy values, process variables, or equipment status through Modbus RTU or Modbus TCP.
The challenge is that a Modbus register is not automatically meaningful to an IoT platform. A value such as 40001 = 1 may represent a run status, alarm flag, relay state, mode code, or another project-specific meaning.
A better conclusion is this: Modbus data must be translated into a message model before it becomes useful for MQTT-based platforms. The work is not only protocol conversion; it is field-data interpretation.
The specific pain point: raw values do not explain themselves
A cloud system or IoT platform usually needs structured data. It needs to know which asset produced the value, what the value means, what unit applies, when it was collected, and whether the reading is valid.
A practical Modbus-to-MQTT message should include at least 5 fields: asset ID, tag name, value, timestamp, and quality. Without these fields, the MQTT broker may receive data, but the receiving application may not understand how to use it.
Modbus and MQTT solve different problems
Modbus is commonly used for field-side communication with PLCs, meters, and industrial equipment. MQTT is commonly used for lightweight publish/subscribe messaging between devices, brokers, applications, and cloud systems.
| Area | Modbus role | MQTT role |
| Main purpose | Read values from industrial devices | Publish structured messages upstream |
| Common location | Field device, PLC, meter, controller | Broker, IoT platform, cloud service |
| Data format | Registers, coils, device addresses | Topics and payloads |
| Main risk | Raw values lack context | Messages may be poorly structured |
| Edge task | Select and interpret values | Publish useful data models |
This comparison is important because Node-RED should not be described as simply “connecting Modbus to MQTT.” Its real value is helping define what happens between the Modbus read and the MQTT publish.
For readers who need a broader protocol background before designing a Modbus-to-MQTT workflow, Robustel’s article on IoT gateway protocols explains how Modbus, OPC UA, and MQTT play different roles between field-side equipment and cloud-facing systems.
The Flow Step Between Modbus Reads and MQTT Publishing
Node-RED is a low-code tool for event-driven applications and is positioned by the Node-RED project as a way to collect, transform, and visualize real-time data. That makes it relevant to industrial data workflows, but it does not remove the need for correct protocol setup and engineering review.
In a Modbus-to-MQTT workflow, Node-RED should sit between the data source and the upstream broker. It can read or receive values, transform them into structured payloads, and publish selected messages to MQTT topics.
A practical edge flow usually has 4 steps: collect selected Modbus values, normalize the data, add context, and publish MQTT messages. Each step should be defined before the flow becomes production logic.
The flow should start after the tag list is known
Node-RED should not be the first planning step. The first planning step is deciding which Modbus values matter. A project team should already know the register address, data type, unit, polling interval, and destination format.
A simple first version may focus on 10–30 selected values instead of every available register. This keeps the flow easier to test and reduces unnecessary polling load on PLCs, meters, serial links, and gateway resources.
Node-RED helps with mapping, not automatic understanding
Node-RED can help connect steps visually, but it does not automatically know what each Modbus register means. The engineering team still needs the device manual, register map, scaling rules, data type definitions, and test values.
This boundary should be explicit. Node-RED can help move data, but project teams must still validate register interpretation, error handling, retry behavior, and whether the MQTT payload represents the real equipment state correctly.
For a broader view of why Node-RED is often used in industrial applications, Robustel’s earlier Node-RED benefits article explains its role in protocol integration, visual programming, customization, and maintenance-friendly workflow design.
Designing MQTT Topics and Payloads That Carry Context
MQTT publishing should be designed around the receiving system. A broker can receive many messages, but an IoT platform still needs a consistent topic structure and payload format to connect data to assets, dashboards, alerts, or analytics.
The topic should usually identify where the value comes from. A simple pattern may include site, line, machine, and tag. The payload should carry the value and enough context for the receiving system to process it.
Topic design should match the asset hierarchy
A weak MQTT design sends values into generic topics such as data or modbus. A stronger design uses topic levels that match the factory or asset structure.
| Topic level | Example |
| Site | factory_a |
| Area or line | line_02 |
| Machine or device | compressor_04 |
| Data group | energy |
| Tag | power_kw |
A topic such as factory_a/line_02/compressor_04/energy/power_kw is easier to route and understand than a generic topic with no asset context.
Payloads should make register values readable
The payload should explain the value, not only transmit it. A practical JSON payload may include tag name, value, unit, timestamp, quality, and source register. This makes the message easier to validate and easier for upper systems to consume.
| Payload field | なぜそれが重要なのか |
| tag | Gives the value a readable name |
| value | Carries the measurement or state |
| unit | Prevents ambiguity in dashboards |
| timestamp | Shows when the value was collected |
| quality | Flags good, stale, bad, or uncertain data |
| source | Links the value back to a register or device |
The key conclusion is practical: MQTT does not make Modbus data cloud-ready by itself. The edge flow must turn raw field data into structured, named, and testable messages.
Robustel EG5120 Edge Gateway for Modbus-to-MQTT Edge Data Movement
Robustel EG5120 edge computing gateway fits this article because the workflow needs an industrial gateway layer, not only a visual flow editor. The product page describes EG5120 as an industrial edge gateway built on RobustOS Pro based on Debian 11, with Docker containers, Debian packages, protocol bridges, data buffering, and edge workloads.
The same page lists dual-SIM 5G/4G/3G/2G and Ethernet WAN with link backup, two software-configurable RS-232/RS-485 ports, 2× DI/2× DO, native Modbus TCP/RTU, MQTT-to-cloud bridging, and RCMS for monitoring, configuration, and updates.
Gateway Capabilities Needed for Modbus-to-MQTT Workflows
| Workflow need | Robustel EG5120 reference |
| Connect Modbus RTU devices | 2× software-configurable RS-232/RS-485 |
| Connect Modbus TCP devices | Ethernet LAN/WAN interface options |
| Run Node-RED or custom flow tools | RobustOS Pro, Debian 11, Docker containers |
| Bridge field data upstream | Native Modbus TCP/RTU and MQTT-to-cloud bridging |
| Keep data path connected | Dual-SIM 5G/4G/3G/2G and Ethernet WAN link backup |
| Secure backhaul | IPsec、OpenVPN、GRE、L2TP、PPTP、DMVPN |
| Manage deployed gateways | RCMS monitoring, configuration, and updates |
This table should be read as a product-fit reference, not as a claim that every Node-RED node or every industrial protocol is supported natively. Final capability still depends on firmware, installed packages, Node-RED nodes, configuration, and project validation.
Why this article uses Robustel EG5120 instead of a smaller gateway
A smaller gateway can be enough for basic PLC collection. This article is more specifically about Node-RED + Modbus + MQTT as an edge-to-cloud data flow. EG5120 is a better reference where the project may need Docker, protocol bridging, local buffering, cellular backhaul, and remote management together.
Robustel’s edge computing gateway portfolio also frames the series around Docker containers, standard Linux tooling, local apps, protocol bridging, and data publishing to brokers or cloud services. That portfolio context supports EG5120 as a suitable reference for application-layer industrial data workflows.
Validation Before Publishing Modbus Data Upstream
A Node-RED Modbus MQTT workflow should be tested before it becomes a production data path. It is not enough for the MQTT broker to receive messages once during commissioning. The project must check how the flow behaves when field devices, networks, or platforms fail.
A minimum validation plan should include 6 tests: normal read, Modbus timeout, bad register value, gateway reboot, MQTT broker outage, and network recovery. These tests help confirm whether the flow fails visibly or silently publishes misleading data.
Robustel’s how-to article on installing Node-RED on EG Series devices via Docker lists practical requirements such as an EG Series gateway, RobustOS Pro 2.4.0 or higher, SSH client access, Docker Engine, internet access for pulling the Docker image, and a sudo user account.
If the project uses a local MQTT broker during testing, Robustel also provides a how-to article on installing the MQTT broker service on EG Series devices. It is useful for validating Mosquitto service status, local publish/subscribe tests, and LAN client access, but its anonymous-access example should be treated as a testing setup rather than a production security model.
FAQs
Q1. How does Node-RED help with Modbus-to-MQTT workflows?
Node-RED helps by acting as the flow layer between Modbus data collection and MQTT publishing. It can read selected Modbus values where the right nodes and configuration are available, map raw registers into meaningful tags, add equipment context, and publish structured payloads to MQTT topics. The value is not just protocol movement. The real value is preparing field data so IoT platforms, dashboards, and applications can understand what each value means.
Q2. Does MQTT automatically make Modbus data cloud-ready?
No. MQTT is a useful publish/subscribe transport, but it does not automatically make raw Modbus values meaningful. A register value still needs context such as tag name, unit, timestamp, equipment ID, quality status, and topic structure. Without this context, a cloud platform may receive messages but still fail to interpret them correctly. A good Node-RED Modbus MQTT workflow should treat MQTT publishing as the final step after data selection, mapping, scaling, and validation.
Q3. Which Robustel edge computing gateway fits Node-RED Modbus MQTT workflows?
Robustel EG5120 edge computing gateway is a suitable reference for Node-RED Modbus MQTT workflows because it supports RobustOS Pro, Docker containers, 2× RS-232/RS-485 ports, native Modbus TCP/RTU, MQTT-to-cloud bridging, dual-SIM 5G/4G/3G/2G cellular, Ethernet WAN link backup, VPN options, and RCMS remote management. These features make it relevant where industrial teams need to collect selected field data, prepare it locally, and forward structured MQTT messages upstream. Final suitability still depends on project configuration.
Q4. Can Node-RED replace a full industrial protocol platform?
Not always. Node-RED is useful for selected data flows, prototyping, field-data mapping, lightweight transformation, and MQTT publishing. It may not be the right layer for every industrial protocol, high-volume historian workload, certified control function, or large-scale data governance requirement. Project teams should check whether the workflow needs a simple visual flow, a dedicated industrial protocol platform, a SCADA edge application, or a custom containerized service. Node-RED should be chosen for fit, not convenience alone.
Q5. What should teams test before sending Modbus data to MQTT?
Teams should test at least 6 conditions: normal Modbus read, wrong register value, device timeout, gateway reboot, MQTT broker outage, and network recovery. They should also confirm topic naming, payload structure, credentials, retry behavior, quality flags, and whether the flow publishes stale data during communication loss. A working demo is not enough for production. A reliable Node-RED Modbus MQTT workflow needs documented flows, controlled access, backups, and clear ownership.
Modbus-to-MQTT Deployment Takeaway
Robustel EG5120 provides a practical product reference because it combines industrial interfaces, native Modbus TCP/RTU, MQTT-to-cloud bridging, Docker-based application support, cellular/Ethernet backhaul, VPN options, and RCMS management in one edge gateway.
A Node-RED Modbus MQTT workflow is most useful when a factory has field-side data available through Modbus but needs structured MQTT messages for upper-layer platforms. The edge gateway becomes the point where raw values are selected, interpreted, formatted, and published.
The most important boundary is clear: Node-RED can support Modbus-to-MQTT data movement, but it should not be described as native support for every protocol, every device, or every gateway model. Project teams should verify the exact nodes, drivers, firmware, runtime, and security policy.
Related Reading on Edge Computing in Industrial IoT:
著者について
Robert Liao | Technical Support Engineer
Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.