How to Choose a Modbus-to-MQTT Gateway: Four Conversion Levels

A gateway that lists both Modbus and MQTT may still be the wrong gateway for your project.

The reason is conversion depth.

Some projects only need serial transport. Some need register mapping. Others need full normalization, timestamps, data quality, buffering, event logic, and a cloud-ready payload schema. These are not the same workload.

A Robustel edge computing gateway EG5120 can be a strong fit when an industrial team needs deeper Modbus-to-MQTT conversion, local data interpretation, buffering, and containerized application support. But the project still needs to define exactly what “conversion” means.

The best buying question is not “Does this gateway support Modbus and MQTT?” It is “How much meaning must the gateway add between the register and the message?”

Level 1: transport only

At the simplest level, the gateway provides a communication path.

This may include serial-to-IP forwarding, Modbus RTU-to-Modbus TCP conversion, transparent TCP or UDP transport, or remote access to a serial device.

This can be enough when an upstream SCADA system already understands the original Modbus device and register map. It is usually not enough for a modern MQTT cloud workflow.

A broker cannot look at register 40001 and know that it means line voltage. It cannot know scaling, byte order, unit, asset identity, or quality state unless the gateway application adds that information.

Level 2: register mapping

The next level reads selected Modbus points and assigns variable names.

Example:

Holding register 40001 → line_voltage_l1
Holding register 40005 → motor_current
Coil 00012             → machine_running
Input register 30020   → process_temperature

This is useful, but still incomplete.

A named value can still be wrong if the signed/unsigned format, scaling factor, byte order, timestamp source, or quality rule is missing. Register mapping makes data easier to identify, but it does not always make it cloud-ready.

Level 3: normalization and data quality

This is the minimum useful level for many industrial IoT and cloud integrations.

At this level, the gateway application interprets data types, combines multi-register values, applies byte and word order, scales the value, adds units, attaches asset and site identifiers, marks timeouts or invalid values, and builds a structured payload.

A normalized MQTT message may look like this:

{
  "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 is much more useful than a raw register. It preserves the engineering meaning of the value.

Level 4: context, aggregation, and events

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

The gateway may publish only after a value changes, calculate minimum or maximum values, combine PLC state with meter data, generate communication alarms, detect thresholds that persist for a defined period, retain diagnostic samples around events, or send routine data in batches.

This level requires more local logic, more testing, and clearer ownership. It should not be confused with PLC control. The gateway may generate monitoring events or summaries, while deterministic control and safety functions remain in the controller layer.

Confirm the software path

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

It may be a native gateway function, a Node-RED flow, an Ignition Edge deployment, a Debian package, a Docker container, or a custom application.

Each path creates different questions. Who owns the flow or code? How are credentials stored? Does the application restart after reboot? Where are mappings backed up? How are logs collected? How is the image updated? What happens if the broker is unavailable?

For Node-RED-style workflows, Robustel’s article on installing Node-RED on industrial IoT edge gateways is a useful implementation reference.

Where Robustel EG5120 fits

Robustel edge computing gateway EG5120 fits deeper conversion workloads where the project needs more application headroom than simple protocol forwarding.

It can support serial and Ethernet field equipment, local applications, Docker-based workflows, Modbus TCP/RTU and MQTT-to-cloud directions, buffering, 4G or 5G variants, and RCMS-based management.

Its role is to provide the edge platform. It does not guarantee that every Modbus device, Node-RED node, container image, broker, or cloud schema will work without validation.

For a concrete product reference, see the Robustel EG5120 product page.

Use a conversion scorecard

Before approving a Modbus-to-MQTT gateway, ask for evidence in the areas that matter:

• Modbus acquisition: tested with representative devices
• Register interpretation: approved point and scaling table
• Conversion depth: Level 1, 2, 3, or 4 defined
• MQTT contract: topics, payloads, timestamps, quality states
• Cloud compatibility: tested against the real endpoint
• Buffering: WAN and broker outage behavior verified
• Security: authentication, TLS, ACL, VPN, firewall design
• Maintenance: backup, update, rollback, and ownership process

Publishing one manually entered value to a test broker proves only that an MQTT connection can be established. It does not prove production conversion.

FAQ

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

A Modbus-to-MQTT gateway may convert raw Modbus registers into structured MQTT messages. Depending on the conversion depth, it may only transport data, map registers, normalize values with units and timestamps, or generate events and summaries. Buyers should confirm the exact conversion level before selecting a gateway.

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 payloads, and publish through MQTT when the right nodes and runtime are configured. Production use still requires backups, credential protection, access control, monitoring, and clear ownership.

Q3. When does Robustel edge computing gateway EG5120 fit?

Robustel edge computing gateway EG5120 fits when the project needs deeper conversion than transparent forwarding. It is relevant for structured Modbus acquisition, MQTT publishing, local buffering, Docker-based applications, and maintainable edge workflows. Final suitability depends on devices, mappings, message volume, broker requirements, and validation.