How to Bridge Modbus RTU to MQTT: A Simple Guide

Bridging Modbus RTU to MQTT means taking register values that a serial field device exposes over an RS-485 bus and publishing them, as structured messages, to an MQTT broker that your SCADA, cloud platform, or analytics stack subscribes to. The gateway does two jobs at once: it acts as a Modbus master that polls slaves on a fixed schedule, and it acts as an MQTT client that converts each poll result into a payload on a topic. This guide walks through every configuration decision, from serial line parameters to TLS, using SURIOTA’s SRT-MGATE-1210 gateway as the worked example.

Why a Protocol Bridge Is Needed at All

Modbus RTU is a request and response protocol on a shared serial bus. A master must explicitly poll each slave, one transaction at a time, and there is no concept of a device pushing data on its own or of a publish and subscribe topology. MQTT is the opposite: a lightweight publish and subscribe protocol designed for many-to-many event distribution over TCP/IP (typically port 1883 plain, or 8883 with TLS). For the fundamentals of brokers, topic design, and QoS levels, see our companion guide on MQTT for industrial IoT; here we focus on the gateway configuration that produces those messages. The gateway reconciles these two worlds. It keeps the deterministic polling loop on the serial side and translates the captured values into asynchronous publishes on the network side. If you are still deciding between serial and Ethernet Modbus on the field side, our explainer on Modbus RTU vs Modbus TCP covers the trade-offs in detail.

Step 1: Set the Serial Line Parameters

Every slave on a single RS-485 segment must use identical serial parameters or the bus will not communicate. Configure the gateway’s serial port to match the field devices exactly:

• Baud rate: one of the standard values (9600, 19200, 38400, 57600, 115200). 9600 and 19200 are the most common defaults for meters and sensors.
• Data bits, parity, stop bits: the typical Modbus RTU framing is 8 data bits with even parity and 1 stop bit (8E1). When no parity is used, the spec calls for 2 stop bits (8N2) to preserve the 11-bit character frame.
• Slave address: 1 to 247 are valid unit IDs; 0 is the broadcast address and is never polled for a response.

Respect the physical limits of the EIA/TIA-485-A standard as well: a single segment supports up to 32 unit loads and roughly 1200 m of cable at lower baud rates, with one termination resistor (typically 120 ohm) at each far end of the trunk. Poor wiring is the single most common cause of intermittent timeouts, so if you see CRC errors review our guide on RS-485 wiring and termination faults.

Step 2: Define the Register and Poll Map

Next, tell the gateway what to read. Each poll entry specifies the slave address, the Modbus function code, the starting register, the quantity, and how to decode the raw 16-bit words into an engineering value. The four standard data models map to function codes as follows: Read Coils (01), Read Discrete Inputs (02), Read Holding Registers (03), and Read Input Registers (04). Holding registers (function 03) carry most analog measurements. If the layout of your device’s registers is unclear, the companion article on Modbus register mapping explains addressing offsets and data types.

Pay close attention to data width and word order. A 32-bit float or a kWh accumulator spans two consecutive 16-bit registers, and vendors differ on whether the high word comes first (big-endian) or the low word comes first (little-endian or word-swapped). Setting the wrong word order produces values that look plausible but are wildly scaled, so always validate against the device display during commissioning.

Step 3: Design the MQTT Topic Structure

A topic is a hierarchical UTF-8 string with levels separated by forward slashes. A disciplined, self-describing hierarchy makes subscriptions and access control far easier later. A practical pattern is site/area/device/measurement, for example plant1/utility/meter01/voltage. Avoid leading slashes and avoid the wildcard characters + and # inside published topics (they are reserved for subscribers). The table below shows how a small set of registers from a SURIOTA PM1611-WD power meter would map onto the bus and onto MQTT.

The temperature and humidity rows here come from a SURIOTA THM-30MD Modbus sensor sharing the same bus, which is exactly the kind of mixed-device segment a gateway is built to handle.

Step 4: Design the JSON Payload

You can publish one value per topic as a bare number, but a single JSON object per device is usually easier to consume because it bundles a timestamp, a quality flag, and all measurements in one atomic message. Keep keys short and stable, and include a UTC timestamp so downstream systems are not forced to trust their own clock. A typical per-device payload looks like this:

{
  "ts": "2026-06-09T08:30:00Z",
  "device": "meter01",
  "status": "ok",
  "data": {
    "voltage": 229.8,
    "current": 12.34,
    "pf": 0.97,
    "energy_kwh": 184523
  }
}

The status field matters. When a slave does not answer or returns a Modbus exception, do not silently drop the reading. Publish a payload with "status": "timeout" or an explicit error so the consumer can distinguish a stale value from a zero value. Mapping exceptions cleanly is half of a robust integration, and the table below lists the standard codes the gateway may receive in a response frame.

Step 5: Choose QoS and Publish Interval

MQTT offers three quality of service levels. QoS 0 (at most once) is fire and forget with no acknowledgement, QoS 1 (at least once) guarantees delivery but may duplicate, and QoS 2 (exactly once) guarantees a single delivery through a four-step handshake. For periodic telemetry that is republished every few seconds, QoS 1 is the usual sweet spot: you tolerate the occasional duplicate but never lose a reading. Reserve QoS 2 for events you cannot afford to duplicate, such as command acknowledgements. Our deeper write-up on MQTT topic and QoS design goes further into retained messages, Last Will and Testament, and clean session behaviour.

Set the publish interval to match the physics of what you are measuring, not the maximum the bus can sustain. Energy meters change slowly, so a 5 to 30 second interval is plenty; a vibration or pressure trend may need 1 second. Remember that the serial bus is the bottleneck: at 9600 baud each transaction takes tens of milliseconds, so polling 30 registers across 10 slaves every second is realistic, but polling hundreds at sub-second rates is not. The gateway’s poll loop period must always be longer than the sum of all transaction times plus inter-frame gaps.

Step 6: Secure the Connection

Never ship a plaintext broker connection to production. Configure the gateway as follows:

• TLS: connect on port 8883 with a CA certificate so the client verifies the broker. Use mutual TLS (client certificates) where the broker supports it.
• Authentication: a unique username and password per gateway, never a shared credential, so a compromised device can be revoked without disrupting the fleet.
• Authorisation: restrict each gateway’s broker ACL to only the topic prefix it owns, for example plant1/utility/# for publish and nothing for subscribe unless it accepts commands.

On the serial side, protect the RS-485 line itself. Long outdoor runs are exposed to surges and ground potential differences, which is where an inline RS-485 surge protector and proper isolation earn their keep. This wiring discipline is part of any well-run industrial IoT and system integration project, where the gateway is only one link in a longer chain from sensor to dashboard.

Commissioning Checklist

1. Confirm serial parameters match every slave and that termination and biasing are correct.
2. Poll one register manually and compare against the device display to verify scaling and word order.
3. Subscribe to the gateway’s topic tree with a test client and confirm payload shape and timestamp.
4. Force a timeout (unplug a slave) and confirm the status field reports it instead of publishing stale data.
5. Enable TLS and authentication, then re-verify the full path end to end.

Frequently Asked Questions

Should I publish one topic per value or one JSON object per device?

One JSON object per device is generally preferred because it groups related measurements with a shared timestamp and quality flag into a single atomic message, which simplifies time alignment downstream. Use per-value topics only when a consumer subscribes to individual measurements independently or when payload size must be minimal.

What QoS level is best for Modbus telemetry over MQTT?

QoS 1 is the practical default for periodic telemetry. It guarantees the broker receives each reading at least once while keeping overhead low. QoS 2 adds a slower four-way handshake and is worth it only for messages that must never be duplicated, such as control acknowledgements.

How fast can the gateway poll Modbus RTU and publish?

The serial bus sets the ceiling. At 9600 baud a single transaction takes tens of milliseconds, so the total loop time is the sum of all transactions plus inter-frame gaps. Set the publish interval longer than that loop and match it to how quickly the measured quantity actually changes rather than to the bus maximum.

Can one gateway handle different device types on the same bus?

Yes. As long as all devices share the same serial parameters and have unique addresses (1 to 247), the gateway polls a mixed set of meters and sensors and maps each register block to its own topic and payload, exactly as shown in the mapping table above.