MQTT and Modbus usually answer different questions in an industrial system. Modbus can read a device’s data areas, while MQTT distributes records obtained by a collector. They do not have to be alternatives: a gateway can connect them as separate layers of one data flow.
Give each protocol the right role
A Modbus client requests specific data and receives a device response. An MQTT publisher sends a message on a topic and the broker routes it to subscribers. The bridge between them often needs to do more than move bytes. It must define what the raw field value means.
If a register contains 184, whether it means 18.4 °C depends on the device documentation. The collector applies verified scaling, units and quality information. Without a documented transformation, downstream services may interpret the same register differently.
Responsibilities by layer
| Question | Device / Modbus layer | Messaging / MQTT layer |
|---|---|---|
| Where is the value obtained? | Register and device map | Topic and publisher identity |
| How is the unit understood? | Manufacturer definition | Payload data contract |
| What happens on disconnection? | Read timeout and quality | Session, buffer and replay |
| How are repeats recognised? | Measurement/event model | Application event identity |
Separating these responsibilities also improves diagnosis. A missing broker message does not prove that a Modbus sensor failed. Inspect the serial link, collector, broker connection and record service independently. Each needs a meaningful last-successful-operation indicator.
Illustrative combined flow
A cold-room measurement module is read over Modbus RTU. The gateway converts the value to the agreed unit, adds source identity and time, then publishes a record through MQTT. The application validates it and stores the history. The dashboard uses that record to display a trend.
Serial collection may continue when the upstream network is down. The gateway retains records in a bounded buffer. On reconnection, records keep their original timestamps and identifiers. The server places them in history rather than presenting them as fresh measurements; repeated delivery does not create a second observation.
Why a protocol converter is not enough
A failed Modbus read, a device-reported sensor fault and an unreachable broker are distinct conditions. Converting all of them to zero or an undifferentiated null makes troubleshooting difficult. Preserve the quality category, last valid measurement time and source health where those facts are available.
QoS selection likewise does not ensure that a downstream database writes only once. Message acceptance, record processing and alarm evaluation form separate boundaries. The OASIS MQTT delivery rules should not be confused with the application’s transaction and deduplication requirements.
Validate both connections
Discovery should establish the register map, which signals are events rather than periodic observations, acceptable data loss, clock management and topic permissions. The gateway’s finite storage and behaviour at capacity must also be understood. More buffering cannot recreate measurements that were never collected.
Acceptance tests should interrupt both the device-to-gateway connection and the gateway-to-server connection. Record expected quality states, replay order and duplicate handling. Also test an invalid device value and a malformed message. The result should be an explainable data flow whose limitations are visible, rather than a pair of protocols that merely appear connected.
Write the bridge contract before configuring topics
For the illustrative cold-room flow, map each normalised field back to its origin. The temperature comes from a documented device quantity; the engineering unit comes from the verified conversion; equipment identity comes from the configuration inventory. The time may be supplied by the device or assigned when the collector reads it. These are different sources of evidence and should not become one ambiguous timestamp labelled live.
The gateway also needs a rule for creating observation identity. A new read can produce a new observation even when the numerical value has not changed. Resending an earlier observation after disconnection should preserve its existing identity. Otherwise the application cannot reliably distinguish unchanged temperature from duplicated delivery. Document whether repeated equal values are retained, summarised or suppressed, because the choice affects both history and freshness checks.
Treat a mapping change as a versioned event. If a technician corrects a scale factor, future payloads and historical records must remain interpretable. Silently applying the new factor to a mixture of raw and already-normalised values can corrupt a report. Keep the transformation boundary explicit, and decide whether a historical correction creates a revised record or a separately documented recalculation.
A two-sided interruption test
First disconnect the Modbus source while leaving the broker connection available. The expected result is a field-source problem, not evidence of a healthy current measurement merely because messages still arrive. Next restore the field connection and interrupt only the path to the broker. Collection may continue locally if the selected equipment supports it. Historical observations should later arrive with their original time and quality information.
Finally, interrupt an acknowledgement after the application has stored an observation. Check that replay creates neither a second sample nor an unbounded stream of repeated alarms. Include a malformed payload and a measurement-quality fault in the same acceptance plan; neither should become an unexplained zero in a trend. Record the outcome at the gateway, receiver and screen so a future maintainer can identify the failed boundary.
This exercise shows why choosing protocols is only part of integration. The useful deliverable includes the device map, payload example, identity and quality rules, topic permissions and recovery behaviour. Share those items when discussing a bridge between existing field equipment and a monitoring application, rather than assuming that a converter alone supplies the complete operating model.