Modbus and MQTT Are Not the Same Layer: A Practical Field-to-Cloud Data Flow

A Modbus-to-MQTT workflow is sometimes described as “protocol conversion.”

That is technically convenient, but it misses the real engineering work.

Modbus helps read values from field devices such as meters, PLCs, drives, and controllers. MQTT helps publish prepared messages to brokers, cloud platforms, dashboards, and applications. The difficult part is not changing one protocol name into another. The difficult part is preserving the meaning of the data as it moves from an industrial register to an upstream system.

A Robustel edge computing gateway EG5100 can be used as a practical reference for this type of field-to-cloud architecture. It can sit between field equipment and upstream systems, collect selected data, run local processing, and publish structured messages through a configured application path.

The key takeaway is simple: MQTT does not make Modbus data useful by itself. The edge layer must turn raw values into information.

Follow one value through the data path

Imagine an energy meter connected over RS-485. The project needs to send the line voltage to a remote energy-monitoring platform.

At the Modbus side, the register map might define the value like this:

Device address: 7
Function: read holding registers
Register: 40001
Data type: unsigned 16-bit integer
Scaling: divide by 10
Unit: volts

The gateway polls the meter and receives:

2356

That number is not cloud-ready data yet. It is only a raw field value. The edge application still needs to apply the engineering definition:

2356 / 10 = 235.6 V

Only after that can the system build a useful MQTT message.

{
  "asset": "meter7",
  "measurement": "line_voltage_l1",
  "value": 235.6,
  "unit": "V",
  "quality": "good",
  "source_timestamp": "2026-07-27T08:15:30Z",
  "mapping_version": "1.2"
}

This message tells the upstream system what the value is, where it came from, how it was interpreted, and whether it should be trusted.

Polling and publishing are different decisions

A common mistake is assuming that Modbus polling frequency and MQTT publishing frequency must be the same.

They do not.

A gateway may poll a local meter every second because the field application needs frequent updates. But publishing the same unchanged value to the cloud every second may waste bandwidth, broker resources, and storage.

A better workflow separates acquisition from reporting. The gateway may publish a one-minute average for routine measurements, send a state event only when a machine changes status, and publish alarms immediately when they occur.

For example:

Poll voltage every second → publish one-minute average
Read run status every second → publish only on state change
Detect Modbus timeout → publish device communication event
Alarm register changes → publish immediate alarm event

The goal is not to publish as little as possible. The goal is to publish information that the receiving system can actually use.

Build a data contract

Reliable Modbus-to-MQTT integration needs a data contract.

For each selected point, the project should define the source device, register address, function code, data type, byte order, scaling, engineering unit, valid range, polling interval, MQTT topic, payload field, timestamp source, quality behavior, and mapping version.

This contract is what prevents field data from becoming mystery data later.

A value that looks correct may still be wrong if the byte order is wrong. A temperature may look reasonable but use the wrong scaling factor. A stale value may look live if the system does not carry quality status.

The edge gateway should not hide invalid or missing data. If a Modbus device stops responding, the MQTT payload should show a timeout, stale state, or device-unavailable condition. Repeating the last value without quality context is how dashboards become misleading.

Separate failure domains

A field-to-cloud workflow can fail in several places.

The Modbus device may stop responding. The RS-485 wiring may be unstable. The gateway application may stop. The WAN connection may fail. The MQTT broker may be unavailable. The cloud consumer may stop processing messages.

These are different failures, and they should not all become one vague “device offline” alert.

A useful diagnostic message might say:

Gateway online, Modbus device unavailable
Modbus polling active, MQTT broker unreachable
Messages queued, WAN unavailable
Broker connected, cloud consumer not processing data

That level of separation helps the right team respond. A cloud engineer should not change MQTT topics when the RS-485 polarity is wrong. An automation engineer should not replace a meter when the local data is correct but the WAN path is unavailable.

Where Robustel EG5100 fits

Robustel edge computing gateway EG5100 fits focused Modbus-to-MQTT and field-to-cloud workflows where industrial teams need serial interfaces, Ethernet, local processing, Docker or Debian-based applications, LTE backhaul, and RCMS-based gateway management.

It is a practical fit for protocol bridging, local normalization, lightweight preprocessing, buffering, and secure delivery to SCADA or cloud environments. The product should not be treated as an unlimited application host or large local database server. Its workload should match the selected application, message volume, storage policy, and long-term maintenance plan.

For readers who want a concrete product reference, the Robustel EG5100 product page provides more detail on its interfaces, application environment, and remote-management options.

FAQ

Q1. What is the difference between Modbus and MQTT in an industrial gateway?

Modbus is usually used to read coils or registers 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 publishing structured MQTT payloads.

Q2. Can a Modbus device publish MQTT data directly?

Usually not. Most Modbus devices respond to requests from a Modbus client and expose values as registers or coils. An edge gateway or application typically polls the Modbus device, interprets the raw values, builds a structured payload, and publishes it through MQTT using the required topic, credentials, and delivery settings.

Q3. Where does Robustel edge computing gateway EG5100 fit?

Robustel edge computing gateway EG5100 fits as the site-side integration layer for focused Modbus-to-MQTT workflows. It can collect selected Modbus data, support local preprocessing, and forward structured messages upstream through a configured application path. Final suitability still depends on device mappings, message volume, buffering policy, and validation.