Recommended Edeg Computing Gateway for Modbus and MQTT: How Robustel Supports Field-to-Cloud Data Flow
Robustel EG5100 edge computing gateway is a practical recommendation when industrial teams need to collect Modbus data, prepare it locally, and publish structured information through MQTT. Modbus communicates with field equipment; MQTT distributes application-ready messages to brokers, cloud platforms, and monitoring systems.
The gateway sits between these two communication models. Its most important job is not changing one protocol name into another, but preserving asset identity, scaling, units, timestamps, and data quality as information moves from an industrial register to an upstream application.
Modbus and MQTT Do Different Work
Modbus and MQTT often appear in the same industrial IoT architecture, but they solve different communication problems. Modbus is commonly used to exchange data with PLCs, meters, drives, controllers, and other field equipment. A Modbus client requests specific coils or registers from a device, and the device returns the requested values.
MQTT uses a publish-and-subscribe model. A client publishes messages to a broker under defined topics, and authorised applications subscribe to the information they need.
| Data-Flow Question | Modbus Role | MQTT Role |
| Where does the value come from? | Reads a coil or register from a field device | Receives a prepared message from the gateway |
| How is data addressed? | Device ID, function code and register address | Topic hierarchy and client identity |
| What is the interaction pattern? | Request and response | Publish and subscribe |
| Where is it normally used? | Field and OT networks | Edge-to-cloud and application messaging |
| Does it define business meaning? | No; meaning depends on the register map | No; meaning depends on the topic and payload design |
Neither protocol automatically supplies the full engineering context.
Modbus may return the integer 2356, but it does not tell a cloud dashboard whether that number means 235.6 volts, 23.56 amps, a production counter, or an alarm code unless the project has a valid register definition. MQTT can transport the same number efficiently, but publishing 2356 to a broker does not make the value understandable. The Robustel gateway therefore needs a data interpretation layer between Modbus acquisition and MQTT publishing.
Modbus can retrieve field data, and MQTT can deliver prepared messages upstream, but the cloud should not be expected to interpret every raw register or manage every field-side polling decision. Watch Robustel’s video “Why Do We Need Edge Computing If We Have the Cloud?” for a concise explanation of why industrial projects process, filter, and structure selected data locally before sending it to cloud platforms.
Follow One Measurement from the Field to the Cloud
The clearest way to understand a Modbus-and-MQTT workflow is to follow one data point through the complete path. Consider an energy meter connected over RS485. The project needs to send its line-voltage measurement to a remote energy-monitoring platform.
1. Identify the Modbus Source
The meter documentation may define the measurement as:
- Device address: 7
- Function: read holding registers
- Register: 40001
- Data type: unsigned 16-bit integer
- Scaling factor: divide by 10
- Unit: volts
The Robustel EG5100 edge computing gateway polls the device using the required serial settings, such as baud rate, parity, stop bits, device address and register definition.
2. Read the Raw Register Value
The meter returns: 2356
At this stage, the number is only a raw Modbus value. It should not yet be published as cloud-ready data.
3. Apply the Engineering Definition
The local application applies the documented scaling: 2356 ÷ 10 = 235.6 V
It can also attach:
- Asset identifier
- Site identifier
- Source timestamp
- Gateway collection timestamp
- Data-quality state
- Register-mapping version
4. Build the MQTT Message
The application may publish the result under a topic such as: factory1/meter7/voltage/l1
A structured payload may contain:
{
"asset": "meter7",
"value": 235.6,
"unit": "V",
"quality": "good",
"source_timestamp": "2026-07-27T08:15:30Z",
"mapping_version": "1.2"
}5. Deliver the Message Upstream
The MQTT broker receives the message and makes it available to authorised subscribers, which may include:
- An industrial IoT platform
- An energy dashboard
- A historian
- A maintenance application
- A reporting service
- A cloud analytics pipeline
This journey shows that the critical work occurs between the raw register and the MQTT message. Robustel EG5100 edge computing gateway does not merely transport the original number; the deployed edge application can turn it into structured information that an upper-layer system can use.
Turn Continuous Polling into Useful Publishing
Modbus polling frequency and MQTT publishing frequency do not have to be the same. A gateway may poll a controller every second because local monitoring requires frequent updates. Publishing every unchanged value to the cloud every second may create unnecessary cellular traffic, broker load, and storage.
The local workflow can separate acquisition from reporting.
| Field-Side Activity | Possible MQTT Behaviour |
| Poll a measurement every second | Publish a one-minute average |
| Read equipment status every second | Publish only when the state changes |
| Poll an alarm register frequently | Publish immediately when an alarm appears |
| Read a cumulative counter | Publish the latest value at a defined interval |
| Detect a communication timeout | Publish a data-quality or device-status event |
This separation allows the Robustel gateway to maintain the field-side polling rate required by the application while controlling the amount of information transmitted upstream.
Publish Changes When Changes Matter
State-based data may only need to be published when a transition occurs. For example, instead of publishing machine_running = true every second, the gateway can publish:
- Machine started
- Machine stopped
- Machine entered a fault state
- Controller communication was lost
Aggregate Routine Measurements
Continuous measurements may be summarized using:
- Minimum
- Maximum
- Average
- Final value
- Number of valid samples
- Number of failed reads
- Time spent above a defined threshold
The aggregation method must fit the measurement. Averaging temperature may be reasonable, while averaging a cumulative energy counter would usually produce an unsuitable result.
Keep Critical Events Immediate
A reporting interval should not delay an important alarm. The data-flow design can publish ordinary telemetry in batches while sending selected faults or state changes as immediate MQTT events.
The objective is not to publish as little data as possible. It is to publish the information required by the upstream system without carrying repetitive raw traffic that adds no operational value.
Carry Engineering Meaning Across the Protocol Boundary
Reliable Modbus-to-MQTT integration requires a data contract. For every selected point, the project should define:
- Source device
- Modbus address
- Function code
- Register address
- Data type
- Byte and word order
- Scaling
- Engineering unit
- Valid range
- Polling interval
- MQTT topic
- Payload field
- Timestamp source
- Quality behaviour
- Mapping version
| Modbus Source | Local Interpretation | MQTT Output |
| Holding register 40001 | Line voltage ÷ 10 | site/meter/voltage |
| Holding register 40005 | Current ÷ 100 | site/meter/current |
| Coil 00012 | Motor-running state | site/motor/status |
| Input register 30020 | Process temperature | site/process/temperature |
| Modbus timeout | Device unavailable | site/device/communication |
Do Not Hide Invalid or Missing Data
When a field device fails to respond, the gateway should not continue publishing the last value as though it were current. A better data model includes quality states such as:
- Good
- Stale
- Timeout
- Invalid
- Out of configured range
- Device unavailable
- Replayed after reconnection
The receiving platform can then distinguish an actual process value from a communications or mapping problem.
Version the Mapping
Register definitions can change when equipment, firmware, or project requirements change. The mapping should therefore be version-controlled. If a value changes unexpectedly, engineers need to determine whether the cause was:
- A real process change
- A replaced meter or controller
- A new register map
- A modified scaling factor
- A changed data type
- An application update
Robustel Edge2Cloud provides one Robustel implementation path for this kind of workflow. It can read selected Modbus RTU or TCP points, apply configured scaling and intervals, normalize them into timestamped JSON, buffer records during link interruptions, and publish them through MQTTS to supported MQTT endpoints. The exact application availability and model compatibility should be confirmed for the selected deployment.
Keep Field, Gateway and Cloud Failures Separate
A field-to-cloud data path contains several failure domains. Treating all of them as one “offline device” condition makes troubleshooting slower.
| Failure Condition | What May Still Work | What Has Failed |
| Modbus device timeout | Gateway, WAN and MQTT connection | Field-device communication |
| Serial wiring problem | Gateway applications and cloud path | RS485 data acquisition |
| Gateway connector stops | PLC or meter continues locally | Data interpretation and publishing |
| Cellular or Ethernet WAN fails | Modbus polling and local processing | Upstream transmission |
| MQTT broker is unavailable | Field collection and gateway operation | Message delivery |
| Cloud consumer stops | Broker may continue receiving data | Application processing or visibility |
Robustel EG5100 edge computing gateway should expose or publish enough status information for teams to locate the fault. For example:
- Gateway online, Modbus device unavailable
- Modbus polling active, MQTT broker unreachable
- Messages queued, WAN unavailable
- Broker connected, cloud consumer not processing data
Buffering Cannot Recover Missing Field Data
A local buffer can retain records when the WAN or MQTT endpoint is temporarily unavailable. It cannot recreate a measurement that was never collected because the Modbus device or serial bus had failed. The data model should retain both the value and its collection status.
When buffered records are replayed, they should preserve their original timestamps and sequence. Historical data should not appear as new live telemetry merely because it reached the broker later.
MQTT Delivery Still Requires a Policy
MQTT provides delivery mechanisms, but the project must configure and validate:
- Quality of Service
- Persistent sessions
- Local queue size
- Reconnection interval
- Duplicate handling
- Broker acknowledgements
- Replay order
- Live-data priority
- Storage-full behaviour
The presence of MQTT does not by itself guarantee that no data will be lost or duplicated.
How Robustel EG5100 Edge Computing Gateway Supports the Field-to-Cloud Workflow
Robustel EG5100 edge computing gateway combines field interfaces, a Debian-based application platform, industrial networking and centralised management.
Its current product architecture includes:
| Product Area | Robustel EG5100 Capability |
| プロセッサ | ARM Cortex-A7 at 792 MHz |
| 記憶 | 1 GB DDR3 |
| Storage | 8 GB eMMC |
| イーサネット | 2 × 10/100 Mbps |
| Serial | 2 × software-configurable RS-232/RS-485 |
| Digital interfaces | 2 DI and 2 DO |
| セルラー | Dual-SIM 4G/LTE with supported 3G/2G fallback |
| Operating system | RobustOS Pro based on Debian 11 |
| Application environment | Docker, Debian packages and SDK |
| Native serial functions | Transparent mode, TCP/UDP and Modbus RTU-to-TCP |
| Fleet management | RCMS, web, CLI and SMS |
The EG5100 product page positions the gateway for RS485 aggregation, containerised protocol connectors, data normalization, local buffering and secure LTE or Ethernet delivery to SCADA and cloud environments.
RobustOS Pro allows a project to implement MQTT publishing through the suitable Robustel application, a compatible Debian package, a Docker container or a custom program. The implementation route must be stated clearly; not every Modbus-to-MQTT workflow should be described as a default built-in function.
For visual flow development, Robustel also documents Node-RED installation on supported EG-series gateways through Docker. Its use requires the applicable RobustOS Pro version, Docker environment, account permissions, compatible nodes and sufficient device resources.
RCMS can monitor Robustel EG5100 gateway fleets, distribute configurations and supported applications, perform updates and provide remote diagnostic access. It manages the gateway estate rather than the PLC logic, MQTT broker service or cloud business application.
The EG5100’s 1 GB RAM and 8 GB eMMC also define its workload boundary. It is well suited to focused protocol bridging, buffering and lightweight preprocessing, but it should not be treated as a large database server or unlimited application host.
よくある質問
Q1. What is the difference between Modbus and MQTT in an industrial gateway?
Modbus is mainly used to read or write data from field devices such as meters, PLCs, and controllers. MQTT is used to publish prepared messages to brokers and upstream applications. The gateway sits between them, interpreting registers, applying scaling and units, adding timestamps and quality status, and then creating an MQTT topic and payload that cloud or monitoring systems can understand.
Q2. Can a Modbus device publish MQTT data directly?
Usually not. Most Modbus devices expose coils or registers and respond to requests from a Modbus client. They do not normally create MQTT topics or connect to a broker. An industrial gateway or edge application polls the Modbus device, interprets the raw values, converts them into a structured payload, and publishes the result through MQTT using the required authentication and delivery settings.
Q3. How often should a gateway poll Modbus data and publish MQTT messages?
The polling and publishing intervals should be designed separately. A gateway may poll a critical register every second but publish a summary every minute, while alarms are sent immediately after a state change. The correct interval depends on device response time, bus capacity, data importance, cellular cost, and cloud requirements. Publishing every unchanged value usually adds traffic without improving operational visibility.
Q4. What information should be included in a Modbus-to-MQTT payload?
A useful payload should include the asset or device identity, measurement name, interpreted value, engineering unit, original timestamp, and data-quality status. Depending on the project, it may also include a site ID, sequence number, alarm state, mapping version, and delivery state. This context allows the receiving application to distinguish valid live data from stale, invalid, delayed, or replayed records.
Q5. What happens when the MQTT broker or WAN connection becomes unavailable?
When the broker or WAN is unavailable, the Robustel EG5100 edge computing gateway can continue local Modbus polling if the field network and application remain operational. Selected messages may be buffered and replayed after reconnection, but this behaviour must be configured and tested. Queue limits, original timestamps, acknowledgements, duplicate handling, replay order, and storage-full behaviour should all be defined before deployment.
Conclusion: Field-to-Cloud Data Flow Takeaway
Robustel EG5100 edge computing gateway is a practical recommendation when an industrial project needs to collect Modbus RTU or TCP data, interpret selected points locally and publish structured information through MQTT.
Modbus provides access to field-side coils and registers. MQTT distributes prepared messages to upstream applications. The Robustel gateway connects these two environments by preserving the asset identity, scaling, unit, timestamp and quality information required to make the data useful.
A successful field-to-cloud workflow is therefore not a simple protocol substitution. It is a controlled journey from a documented industrial data point to an application-ready message, with clear behaviour when the device, gateway, WAN, broker or cloud system becomes unavailable.
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.