How to Choose a Modbus-to-MQTT Gateway for Edge Data Conversion

Robustel EG5120 edge computing gateway is a strong fit when industrial teams need more than transparent protocol forwarding. It can support Modbus acquisition, local data interpretation, MQTT-to-cloud workflows, buffering, and containerized applications, but the exact conversion function must be defined and validated for each project.

A gateway that lists both Modbus and MQTT may still be unsuitable if it cannot interpret the required registers, preserve engineering context, handle outages, or deploy the application responsible for conversion. The purchasing decision should therefore begin with conversion depth, not a protocol checkbox.

Identify the Modbus Source Before Evaluating the Gateway

The gateway must first match the field-side Modbus architecture. The project should document:

• Modbus RTU or Modbus TCP
• RS-232, RS-485, or Ethernet interface
• Number of devices
• Number of independent serial buses
• Device addresses
• Function codes
• Register quantity
• Polling frequency
• Data types and byte order
• Read and write requirements
• Device timeout and retry behaviour

Modbus defines access to objects such as coils, discrete inputs, input registers, and holding registers. The standard describes how these values are read or written, but their engineering meaning remains device-specific and must come from the manufacturer’s register map.

A gateway specification stating “supports Modbus RTU” does not confirm that the complete project workload will operate correctly. Buyers still need to calculate whether the serial bus can poll the required devices and registers within the target update interval.

For Modbus TCP, the review should include:

• IP addressing
• Network segmentation
• Simultaneous device connections
• PLC communication limits
• Ethernet traffic
• Firewall rules
• Device reconnection behaviour

Robustel tips: The project should also state whether Modbus write functions are required. A monitoring gateway that only reads selected registers has a very different risk boundary from a gateway that accepts upstream instructions and writes coils or holding registers.

Choose the Required Conversion Depth

Modbus-to-MQTT conversion can be divided into four levels. This is the most important selection model for the project.

Conversion Level	Gateway Responsibility	Typical Output
Level 1: Transport only	Move serial or TCP data without interpreting it	Raw or transparent data path
Level 2: Register mapping	Read defined registers and assign names	Named variables
Level 3: Normalization and quality	Apply data type, scaling, units, timestamps, and status	Structured cloud-ready payload
Level 4: Context and event processing	Aggregate, filter, combine, and evaluate data locally	Events, summaries, or alarms

Level 1: Transport Only

At the most basic level, the gateway acts as a communications path. Examples include:

• Serial-to-IP forwarding
• Modbus RTU-to-Modbus TCP conversion
• Transparent TCP or UDP transport
• Remote access to a serial device

This level may be sufficient when an upstream SCADA or server already understands the original Modbus device and register map. It is generally not enough for a modern MQTT cloud application. A broker cannot determine that register 40001 represents line voltage or that the raw integer must be divided by ten.

Level 2: Register Mapping

At this level, the gateway or its application reads selected Modbus points and assigns useful variable names.

For example:

Modbus Definition	Mapped Variable
Holding register 40001	line_voltage_l1
Holding register 40005	motor_current
Coil 00012	machine_running
Input register 30020	process_temperature

Register mapping makes the data easier to use, but it may still be incomplete. The variable needs a data type, scaling factor, unit, timestamp, and quality definition before it becomes reliable application data.

Level 3: Normalization and Data Quality

This is the minimum suitable level for many industrial IoT and cloud integrations. The Robustel gateway application may need to:

• Interpret signed or unsigned values
• Combine multiple 16-bit registers
• Apply byte and word order
• Apply scaling
• Convert engineering units
• Add asset and site identifiers
• Add timestamps
• Mark timeouts or invalid values
• Build JSON or another agreed payload
• Publish to an MQTT topic

The result may look like:

{
  "asset_id": "pump-07",
  "measurement": "discharge_pressure",
  "value": 5.42,
  "unit": "bar",
  "quality": "good",
  "timestamp": "2026-07-30T09:15:24Z",
  "mapping_version": "2.1"
}

This message is usable because it preserves the engineering meaning of the Modbus value rather than forwarding only the raw register content.

Level 4: Context, Aggregation, and Event Logic

Some projects need the Robustel edge computing gateway to produce a smaller and more useful output before cloud transmission.

The application may:

• Publish only after a value changes
• Calculate minimum, maximum, or average values
• Combine PLC state with meter data
• Generate communication alarms
• Detect a threshold lasting for a defined period
• Retain diagnostic samples around an event
• Send routine data in batches
• Publish critical alarms immediately

This level requires more application logic, processing resources, testing, version control, and operational ownership.

It should not be confused with PLC control. The gateway may generate monitoring events or data summaries, while deterministic machine control, interlocks, and safety functions remain in the appropriate controller.

Define the MQTT Output Contract

Once the conversion depth is clear, the project should specify exactly what the MQTT side must receive. MQTT uses a publish-and-subscribe model in which clients exchange messages through a broker. Features such as Quality of Service and session state define messaging behaviour, but they do not determine the industrial meaning of the payload.

The MQTT contract should define:

• Broker address
• Client identity
• Topic namespace
• Payload schema
• Asset identity
• Units
• Original timestamps
• Quality states
• Sequence numbers
• Schema version
• Publishing interval
• Alarm behaviour
• Authentication and encryption
• Duplicate handling

A stable topic structure may use: region/site/asset/message-type

Examples include:

• eu/plant7/pump07/telemetry
• eu/plant7/pump07/alarm
• eu/plant7/pump07/communication
• eu/plant7/gateway01/health

The project should avoid creating topics directly from temporary IP addresses or unexplained register numbers. MQTT topics should represent assets and data responsibilities that remain understandable after equipment or network changes.

Polling and publishing frequencies should also remain separate. The Robustel gateway may poll a Modbus device every second while publishing a one-minute summary, but an important alarm may need immediate publication.

Check Buffering and Failure Recovery

A production Modbus-to-MQTT gateway must define what happens when one part of the data path becomes unavailable.

Failure Condition	Required Gateway Behaviour
Modbus device timeout	Mark the point unavailable or publish a communication event
Serial bus failure	Keep WAN and gateway health visible where possible
MQTT broker unavailable	Queue selected messages according to policy
WAN unavailable	Continue approved local polling and processing
Gateway application stops	Raise an application-health alarm
Gateway reboots	Restore the approved application and mappings
Local storage fills	Apply a documented priority and deletion policy

Buffering does not happen automatically because the gateway contains eMMC storage. The selected application must define:

• Which records are stored
• Maximum retention period
• Queue size
• Original timestamps
• Message expiry
• Replay order
• Broker acknowledgements
• Duplicate prevention
• Live-data priority
• Storage-full behaviour

When connectivity returns, the gateway may need to deliver new live messages while replaying historical records. An uncontrolled backlog can consume the WAN connection and delay current alarms.

Robustel EG5120 edge computing gateway provides 64 GB eMMC, but that capacity is shared with RobustOS Pro, applications, containers, logs, updates, and other local data. The usable buffering period must therefore be calculated from the actual message volume and software footprint.

Confirm How the Conversion Application Is Delivered

The words “supports Modbus and MQTT” do not explain where the conversion logic runs.

Implementation Method	What the Buyer Must Confirm
Native gateway function	Firmware version, mapping depth, and supported workflow
Node-RED flow	Runtime, installed nodes, flow ownership, security, and backup
Ignition Edge	Runtime package, licensing, drivers, modules, and resource use
Third-party Debian package	ARM compatibility, dependencies, license, and updates
Docker application	Image architecture, persistent storage, ports, and restart policy
Custom application	SDK, source ownership, testing, logs, and lifecycle support

Node-RED

Node-RED can read selected Modbus data, process values, build JSON, and publish messages through MQTT when the correct nodes and settings are installed. Robustel documents Modbus and MQTT nodes as part of Node-RED-based edge workflows.

The Robustel Node-RED guide for industrial edge gateways shows how Modbus and MQTT nodes can be added to a Robustel edge computing gateway data flow.

Production deployment still needs flow backups, credential protection, editor access controls, application monitoring, and a named owner. A visual flow does not remove the need for engineering documentation.

Ignition Edge

Robustel also documents the deployment of Ignition Edge on the EG5120. The installed software can connect to supported PLCs, use drivers such as Modbus TCP, and implement Modbus-to-MQTT or other local edge logic, subject to the selected Ignition modules and licensing.

The Robustel guide on how to deploy ignition edge on Robustel EG5120 provides one example of a third-party industrial application running on the gateway.

Custom or Containerized Application

RobustOS Pro is based on Debian 11 and supports Docker containers and Debian packages. This allows project teams to deploy a custom Modbus collector, MQTT client, local database, or conversion service when an off-the-shelf workflow does not meet the requirement.

The application must match the gateway’s ARM architecture, available RAM and storage, firmware baseline, security policy, and update process.

How Robustel EG5120 Edge Computing Gateway Fits Deeper Conversion Workloads

Robustel EG5120 edge computing gateway combines industrial interfaces, local processing, application hosting, and WAN connectivity in one platform.

Its current specification includes:

Product Area	Robustel EG5120 Capability
CPU	Quad-core Cortex-A53 at 1.6 GHz
Memory	2 GB or 4 GB LPDDR4
Storage	64 GB eMMC
Ethernet	2 × Gigabit Ethernet
Serial	2 × software-configurable RS-232/RS-485
Digital interfaces	2 DI and 2 DO
Cellular	Dual-SIM 5G or 4G variants
Software environment	RobustOS Pro, Docker, and Debian packages
Protocol direction	Modbus TCP/RTU and MQTT-to-cloud bridging
Management	RCMS monitoring, configuration, and updates

The EG5120 product page describes native Modbus TCP/RTU integration, MQTT-to-cloud bridging, protocol applications, local buffering, and Docker-based workloads. Its two serial ports and two Gigabit Ethernet ports allow the gateway to collect from both serial and Ethernet field equipment.

The Robustel EG5120 edge computing gateway product page provides the current interfaces, computing resources, RobustOS Pro environment, cellular options, and management specifications.

These resources make the Robustel EG5120 suitable for deeper conversion workflows involving several mappings, concurrent services, longer local retention, or third-party edge applications. They do not guarantee that every Modbus device, MQTT broker, Node-RED node, container image, or cloud schema will work without validation.

Use a Conversion Capability Scorecard

Before approving the gateway, require evidence for each important layer.

Selection Area	Evidence Required
Modbus acquisition	Successful polling test using representative devices
Register interpretation	Approved point and scaling table
Conversion depth	Clear definition of Levels 1–4 required by the project
MQTT contract	Tested topics, payloads, timestamps, and quality states
Cloud compatibility	Successful connection to the actual endpoint
Buffering	WAN and broker outage test
Replay	Verified ordering, acknowledgement, and duplicate handling
Security	Authentication, TLS, ACL, VPN, and firewall design
Application delivery	Named software, runtime, version, and licensing
Maintenance	Update, backup, rollback, logging, and ownership process

A demonstration should use the real register map and a representative message volume. Publishing one manually entered value to a test broker proves only that an MQTT connection can be established.

FAQs

Q1. What does a Modbus-to-MQTT gateway actually convert?

A Modbus-to-MQTT gateway like Robustel EG5120 edge computing gateway reads selected Modbus coils or registers, interprets data types, byte order and scaling, adds engineering units, timestamps and quality status, then publishes a structured MQTT message. A basic converter may only forward raw data, while a deeper edge workflow creates application-ready payloads. Buyers should therefore confirm the exact conversion level, polling logic, topic structure and failure handling included.

Q2. Can Node-RED be used for Modbus-to-MQTT conversion?

Yes. Node-RED can poll Modbus devices, process register values, apply scaling, add timestamps or asset IDs, build JSON and publish through MQTT. On a Robustel EG5120 edge computing gateway, it can run in a supported Docker environment. Production use still requires flow backups, credential protection, access controls, resource monitoring and a named owner. It should not replace deterministic PLC control or safety logic.

Q3. Does a Modbus-to-MQTT gateway need a local MQTT broker?

Not always. A gateway acting only as an MQTT publisher can connect directly to a remote broker. A local broker is more useful when several site applications must exchange messages without depending on the WAN. However, installing a broker does not automatically provide persistent storage or cloud replay. Queue limits, acknowledgement, reconnection, authentication, topic permissions, TLS or VPN and storage behaviour must still be designed explicitly.

Q4. How should Modbus registers be mapped to MQTT topics and JSON?

Start with a documented point table covering device address, register, function code, data type, byte order, scaling, unit, polling interval and quality behaviour. Then define an asset-based MQTT topic and a stable payload containing value, unit, timestamp, quality and schema version. Avoid using raw register numbers as cloud-facing labels. Good mapping lets upstream systems stay consistent even when devices or register maps change.

Q5. Can MQTT commands safely write data back to a PLC or Modbus device?

MQTT can carry an approved command toward a gateway, but it should not provide unrestricted cloud control of PLC or Modbus write functions. The gateway should authenticate the sender, restrict topics, validate values and operating state, log the request and return a clear result. Safety functions, interlocks and deterministic control should remain in the PLC. Read-only acquisition is the safer default unless writes are formally reviewed.

Conclusion: Modbus-to-MQTT Gateway Selection Takeaway

Robustel EG5120 edge computing gateway is a practical choice when an industrial project requires structured Modbus acquisition, MQTT publishing, local buffering, and a maintainable application environment rather than simple protocol transport.

The correct product should be selected according to conversion depth. Some sites need only Modbus RTU-to-TCP forwarding; others need register mapping, engineering normalization, data-quality states, aggregation, events, and controlled cloud replay.

A specification containing both “Modbus” and “MQTT” does not prove that the gateway meets those requirements. The strongest selection process verifies the real devices, point mappings, MQTT contract, failure behaviour, security controls, software implementation, and maintenance ownership before the Robustel gateway is deployed across the wider industrial fleet.

Related Reading on Edge Computing in Industrial IoT:

About the Author

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.