What is Modbus RTU used for?

Modbus RTU is used for serial communication between industrial devices, such as PLCs, sensors, drives, meters, and instrumentation. It's the dominant protocol for point-to-point and multi-drop serial networks in manufacturing and process automation, particularly on devices that predate widespread Ethernet adoption.

What's the difference between Modbus RTU and Modbus TCP?

Modbus RTU runs over serial connections (RS-485 or RS-232) and uses CRC error checking. Modbus TCP runs over Ethernet and uses TCP's built-in transport reliability. Both use the same function codes and data model. RTU is more common on legacy devices; TCP is the default for Ethernet-connected devices and newer installations.

Can Modbus RTU devices connect to MQTT?

Yes, through a protocol gateway. The gateway polls Modbus RTU slaves on the serial side and publishes the data as MQTT messages on the network side. The Modbus devices don't require modification. Gateway configuration requires the device register map, serial port settings, and MQTT broker connection details.

What physical layer should I use for Modbus RTU?

RS-485 for any multi-device network or cable runs over 15 meters. RS-232 only for direct two-device, short-range connections. RS-485's differential signaling, noise immunity, and multi-drop support make it the standard for industrial Modbus RTU deployments. If you're scoping a gateway installation, assume RS-485.

What is a Modbus RTU function code?

A function code is a one-byte value in the Modbus RTU frame that tells the addressed slave what operation to perform - read coils, read registers, write a coil, write registers. The slave responds with the same function code, or an exception response if the request can't be processed. For MQTT integration, the function codes your gateway will use most are FC03 (read holding registers) and FC04 (read input registers).

What MQTT QoS level should I use for Modbus RTU sensor data?

It depends on the data type. Use QoS 1 (at least once) for process-critical data where message loss has operational consequences - drive speeds, pressure readings, flow rates. Use QoS 0 (fire and forget) for high-frequency, non-critical telemetry where occasional loss is acceptable. QoS 2 guarantees exactly-once delivery but carries a four-message handshake overhead that's rarely justified for continuous sensor streams - use it selectively for control commands or setpoint writes back to devices.

How do I design an MQTT topic structure for Modbus RTU devices?

Use a hierarchy that reflects your physical and logical site model: {site}/{area}/{line}/{device}/{measurement}. For example: plant/stamping/line-A/drive-1/speed-actual. Design this before you configure your first gateway - topic structures are difficult to change once downstream consumers like historians or analytics platforms are built against them. A flat structure is fast to set up and expensive to fix later.

Can I connect multiple Modbus RTU devices to one MQTT gateway?

Yes. A single gateway can poll multiple devices across one or more RS-485 buses and publish each device's data to separate MQTT topics. Physical bus constraints apply on the Modbus side - device count, cable length, and baud rate all affect polling cycle time. On the MQTT side, the broker scales independently of those constraints, which is precisely why bridging to MQTT removes the architectural ceiling that polling imposes.

What causes slow polling when bridging Modbus RTU to MQTT?

Polling cycle time is a function of baud rate, number of devices, register counts per device, and response timeouts. At 9,600 baud with 20 devices and typical response times, a full poll cycle can take several seconds. If cycle time is too slow for your data requirements, increase the baud rate, reduce the number of registers polled per device, or split devices across multiple RS-485 buses. Calculate expected cycle time before setting poll intervals - don't assume a 500ms interval is achievable without validating it against your network's physical constraints.

Does HiveMQ support Modbus RTU to MQTT integration?

Yes. HiveMQ Edge is purpose-built for exactly this use case - it runs at the edge, connects directly to your RS-485 bus, and handles Modbus RTU polling and protocol translation natively, publishing device data as MQTT messages to the HiveMQ broker without requiring custom code or middleware. It also supports Modbus TCP, OPC-UA, and other industrial protocols in the same deployment, making it practical for hybrid environments where multiple protocol variants run simultaneously.

What makes HiveMQ a good MQTT broker for Modbus RTU industrial data?

Three things matter most in industrial Modbus RTU to MQTT deployments: reliability at the edge, scalability at the broker, and security across both. HiveMQ supports persistent sessions so edge gateways with intermittent cellular or Ethernet connectivity don't lose data during disconnections. It handles millions of concurrent connections and message throughput that polling-based architectures can't match. And it provides the TLS encryption, authentication, and access control that IT and security teams require before OT data crosses into enterprise or cloud infrastructure.

Can HiveMQ connect Modbus RTU data to a Unified Namespace?

Yes, and this is one of the most common reasons manufacturing teams choose HiveMQ for Modbus RTU integration. Once your gateway is publishing Modbus RTU device data as MQTT messages to HiveMQ, that data becomes a governed, addressable part of a Unified Namespace - consumable by any subscriber, whether that's a historian, SCADA system, cloud analytics platform, or AI model, without polling overhead or point-to-point integration work. HiveMQ's topic structure, persistent sessions, and data governance capabilities via HiveMQ Data Hub make it a natural foundation for UNS architectures in manufacturing environments running legacy serial devices alongside modern Ethernet-connected equipment.

MQTT Real-Time Monitoring

How to Connect Modbus RTU to MQTT for Real-Time Industrial Data

by Kudzai Manditereza

May 26, 2026 25 min read

TL;DR

Modbus RTU is a serial communication protocol that has powered industrial automation for decades - but it wasn't built for the data volumes, network architectures, or AI-readiness requirements of modern manufacturing.

This guide is for OT and IT engineers who need to pull real operational data out of legacy Modbus RTU devices and get it into a modern, scalable data backbone - without ripping out hardware that works.

A clear picture of how Modbus RTU works and why it still dominates the factory shop floor
A practical, step-by-step path to bridging Modbus RTU to MQTT
A real-world manufacturing example with MQTT topic structure you can use as a template
A troubleshooting reference for the most common integration failure points

Who this is for: OT engineers managing legacy serial devices, and IT engineers being asked to connect that data to cloud platforms, historians, or AI workloads, without touching the hardware.

If you work in industrial automation, Modbus RTU is everywhere. PLCs, drives, sensors, flow meters, temperature controllers, etc. – the majority of devices on a typical factory floor still speak it.

The problem isn't Modbus RTU itself. It's deterministic, reliable, and battle-tested across decades of real industrial environments. The problem is that it was never designed to share data beyond the serial bus it runs on.

If your team has been asked to feed OT data into a data lake, build a Unified Namespace, or connect operational data to an AI initiative, Modbus RTU is where that journey starts and, without a bridge, where it stops.

That bridge is a protocol gateway running MQTT. You keep the hardware. You keep the control logic. You add a translation layer at the edge that pulls data from Modbus RTU devices and publishes it as MQTT messages to a broker. From there, any system that needs that data can subscribe to it, such as historian, SCADA, cloud analytics, or an AI model. This guide shows you exactly how to do that.

Modbus RTU Communication Overview

Modbus RTU is a master/slave serial protocol. One master initiates every transaction, slaves respond only when addressed, and nothing transmits unsolicited. It runs over RS-485 in virtually every industrial deployment, supporting up to 247 addressable devices per bus with cable runs up to 1,200 meters and the noise immunity manufacturing environments demand. That strict request/response model is what made it the default for PLCs, drives, sensors, and instrumentation across decades of factory floors. The trade-off is visibility: data stays on the serial bus unless something explicitly bridges it out.

Modbus RTU Protocol Overview

The Modbus RTU protocol defines how every byte on the wire is structured, addressed, and validated. Each transaction begins with a node address (1–247) that targets one device, followed by a function code that tells it what to do, a data field carrying the register address and count, and a CRC for error detection. Get any of these wrong in your gateway configuration, such as wrong address, wrong function code, and wrong register offset, and the device either ignores the request or returns data that looks valid but isn't.

Common Modbus RTU Devices

Client Master: The master initiates all communication on the network. In industrial automation, this is typically a PLC, SCADA system, or data acquisition device. It sends requests, manages polling cycles, and processes responses from slaves. Only one master operates on a Modbus RTU network at a time.
Client Slave: Slave devices respond to requests from the master. Sensors, drives, meters, actuators, and instrumentation typically operate as slaves. A slave processes only requests addressed to its node address and responds with the requested data or an error code. Slaves never initiate communication.
Gateways: Gateways translate between Modbus RTU and other protocols, including MQTT, Modbus TCP, and OPC-UA. In modern integration architectures, an edge gateway is typically the device that polls Modbus RTU slaves on the serial side and publishes the data upstream over Ethernet or cellular. Gateways are the practical bridge between legacy serial devices and modern data infrastructure.

RS-485 Modbus RTU Physical Layer Key for MQTT Integration

For any Modbus RTU to MQTT integration, RS-485 is the physical layer you'll be working with. While Modbus RTU doesn't mandate a specific physical layer, RS-485 is the industrial standard. Its differential signaling handles the electrical noise generated by variable-frequency drives, motors, and high-current equipment that would corrupt data on single-ended standards like RS-232. It supports multi-drop networking across up to 247 addressable devices on a single bus, cable runs up to 1,200 meters, and reliable communication at 9,600 baud across several hundred meters in well-terminated installations.

RS-232 is limited to two-device, point-to-point connections with a 15-meter maximum, which is useful for a direct PLC-to-programming-terminal connection, but not relevant for any multi-device deployment where a gateway needs to poll multiple Modbus RTU slaves and publish their data upstream to an MQTT broker.

If you're scoping a gateway installation, assume RS-485, and account for cable quality, proper termination at both ends of the bus, and stub lengths before you set your baud rate and polling intervals.

Data Representation: Understanding for Better Modbus RTU to MQTT Integration

When configuring a gateway to bridge Modbus RTU to MQTT, knowing which data lives where is what separates a clean integration from hours of debugging.

Modbus RTU organizes device data into four object types:

Coils (read/write, 1-bit - relay states, valve positions)
Discrete inputs (read-only, 1-bit - physical input states)
Input registers (read-only, 16-bit - sensor readings, measured values)
Holding registers (read/write, 16-bit - setpoints, configuration parameters).

In practice, the registers your gateway will poll most frequently are input registers for real-time sensor data and holding registers for operational setpoints. These become the MQTT messages published upstream to your broker and consumed by historians, analytics platforms, or AI workloads.

One trap that catches almost everyone during gateway configuration: the protocol data address transmitted in the frame is offset by 1 from the register number in your device documentation. Holding register 40001 is addressed as 0x0000 in the frame. Get this wrong and your gateway publishes to the right MQTT topics with the wrong data, and it will look correct until someone checks it against a live device reading. Always confirm which addressing convention your vendor's documentation uses before you configure a single register map.

The table below maps each Modbus RTU data type to its real-world device use and its role as an MQTT message once your gateway bridges the two. Use it as a reference when configuring your register map.

Object type	Access	Data type	Address range	Typical use	MQTT Relevance
Coils	Read/Write	1-bit Boolean	00001–09999	Relay states, valve open/close, motor run/stop	Published as binary status events - useful for alerting and control feedback topics
Discrete inputs	Read Only	1-bit Boolean	10001–19999	Physical input states, limit switches, presence sensors	Published as event-driven status; ideal for QoS 0 high-frequency topics
Input registers	Read Only	16-bit word	30001–39999	Sensor readings, measured current, flow totals, temperature	Most commonly polled registers - become the real-time telemetry messages on your MQTT broker
Holding registers	Read/Write	16-bit	40001–49999	Setpoints, speed references, configuration parameters	Published for monitoring; can also receive MQTT commands to write updated setpoints back to devices

Modbus RTU Frame Structure

When bridging Modbus RTU to MQTT, you don't need to build or parse frames manually. Your gateway handles that transparently. What you do need to know is which function code to configure for each data type you want to publish upstream:

FC03 to read holding registers
FC04 to read input registers
FC01 to read coils
FC02 to read discrete inputs

Get the function code wrong in your register map and the gateway will poll the right device at the right address and return an exception response. This means no data reaches your MQTT broker.

Modbus RTU vs Modbus TCP vs MQTT: What Integration Engineers Need to Know

Modbus TCP uses the same function codes and data model as RTU, but runs over Ethernet with TCP's built-in reliability instead of serial CRC. Most modern devices default to Modbus TCP. Hybrid networks running both variants simultaneously are common, and most gateways that bridge to MQTT support both.

Here's how all three compare across what actually matters for an integration project:

	Modbus RTU	Modbus TCP	MQTT
Physical layer	RS-485 / RS-232 serial	Ethernet / TCP/IP	TCP/IP (any network)
Communication model	Master/slave polling	Client/server polling	Publish/subscribe
Device addressing	Node address in frame	IP address	Topic-based
Error handling	CRC + master timeout	TCP checksums + retransmission	QoS 0/1/2 + persistent sessions
Scalability	Up to 247 nodes per bus	Scales over Ethernet	Millions of concurrent connections
Data flow	Master polls, slave responds	Client polls, server responds	Devices publish; subscribers receive
IIoT / cloud ready	No. Serial boundary	Partial. Polling overhead remains	Yes. Designed for it
Legacy hardware support	Native	Native	Via gateway

The key insight for integration engineers: MQTT's publish/subscribe model removes the polling ceiling entirely. Instead of a master cycling through devices one at a time, a gateway publishes data to a broker, and any number of downstream consumers - historian, SCADA, analytics platform, AI model - receive it without adding polling overhead. That's the architectural shift that makes Modbus RTU data actually useful at scale.

For a deeper look at how Modbus TCP compares to MQTT for IIoT data use cases, including gateway hardware and software options, see our companion guide: Transferring Data from Modbus to MQTT Broker for Advanced IIoT Data Use Cases.

Step-by-Step Guide to Connecting Modbus RTU to MQTT

Connecting Modbus RTU to MQTT requires a translation layer, such as an edge gateway or software agent that sits between your serial network and the MQTT broker. The gateway polls Modbus RTU slaves on the serial side using standard function codes, then publishes the data as MQTT messages on the network side. Your Modbus devices don't need to be modified, reconfigured, or even aware that anything has changed. The gateway handles protocol translation transparently. It’s the only thing that changes in your architecture.

Step 1: Audit Your Modbus Devices

Before touching any configuration, document what you have. For each device on your RS-485 bus, record:

Node address (1–247)
Register map - which registers hold the data you actually need
Baud rate and serial settings (data bits, parity, stop bits)
Object types in use - coils, discrete inputs, input registers, holding registers

Most integration failures start here. Cross-reference the device datasheet against any existing PLC configuration to catch address discrepancies before they become gateway errors.

Step 2: Choose Your Gateway

You have two paths depending on your environment and team preference.

Hardware gateways sit physically at the edge, connect directly to your RS-485 bus, and publish to MQTT over Ethernet or cellular. They're the right choice for environments where you want a dedicated appliance with no server dependency.
Software gateways run on an existing edge server or industrial PC. Node-RED with Modbus and MQTT nodes works well for rapid prototyping. Ignition with the MQTT Transmission module is a strong choice for larger SCADA environments. For teams that prefer to build their own, see our step-by-step guide to building a Modbus-to-MQTT gateway in C#.

Step 3: Configure Serial Port Settings

Your gateway's serial settings must exactly match every device on the bus. A single mismatch will result in no response or garbled data. Typical RS-485 settings for industrial Modbus RTU deployments:

Baud rate: 9,600 or 19,200 (confirm from device datasheet)
Data bits: 8
Parity: None (most common), Even, or Odd
Stop bits: 1 or 2

Step 4: Map Your Registers

Define exactly what data the gateway collects and publishes. For each device, configure:

Node address
Object type (coil, discrete input, input register, holding register)
Starting address and register count
Data type (16-bit integer, 32-bit float, Boolean)
Polling interval

Remember the address offset. Holding register 40001 in your device documentation is starting address 0x0000 in the frame. Confirm your gateway uses the same convention as your vendor documentation before you save a single register map entry.

Step 5: Design Your MQTT Topic Structure

This is the decision that's hardest to undo. A flat structure like device1/temperature is fast to configure and painful to scale. Design a hierarchy that reflects your physical site model before you publish your first message:

{site}/{area}/{line}/{device}/{measurement}

A well-structured topic hierarchy makes your data addressable, filterable, and compatible with Unified Namespace architectures from day one, without requiring downstream transformation later.

Step 6: Connect to Your MQTT Broker and Validate

Configure your gateway with:

Broker address and port: use 8883 with TLS in production, never 1883 unencrypted
Username and password
Client ID, which is unique per gateway instance
QoS per topic group
Persistent session enabled for gateways with intermittent connectivity

Once connected, use an MQTT client tool such as MQTT Explorer or MQTT.fx to subscribe to your topic hierarchy and confirm data is flowing. Validate values against a live device reading to check that the data makes sense, not just that messages are arriving.

Step 7: Set QoS Per Data Type

Not all data carries the same delivery requirement. Assign QoS based on what each data type actually needs:

QoS 0 - fire and forget. Use for high-frequency telemetry where occasional loss is acceptable, such as temperature readings updated every second.
QoS 1 - at least once. Use for process-critical data where message loss has operational consequences, such as drive speeds, pressure readings, flow rates.
QoS 2 - exactly once. Guarantees single delivery but requires a four-message handshake. Rarely justified for continuous sensor streams - use selectively for control commands or setpoint writes.

Connecting to HiveMQ

Once your gateway is publishing Modbus RTU data as MQTT messages, HiveMQ handles everything on the broker side, right from routing data to subscribers whether that's a historian, SCADA system, analytics platform, or cloud service. HiveMQ supports the full MQTT specification including QoS levels 0, 1, and 2, persistent sessions for edge devices with intermittent connectivity, and the security controls industrial environments require.

For engineers building toward a broader data architecture, such as a Unified Namespace, real-time analytics, or AI workloads, MQTT-connected Modbus RTU data stops being siloed serial data accessible only to the local master and becomes an addressable, governed part of a unified operational data backbone. That's the shift from OT data that's locally useful to OT data that's enterprise-ready.

Get Started with HiveMQ

Real-World Example: Stamping Line Integration

Here's what a real gateway configuration looks like for a stamping line with three drives and a temperature sensor.

Devices:

Drive 1 - Node address 1, holding registers 40001–40002 (speed setpoint, actual speed)
Drive 2 - Node address 2, holding registers 40001–40002
Drive 3 - Node address 3, holding registers 40001–40002
Temperature sensor - Node address 4, input register 30001 (temperature, °C)

Poll interval: 500ms for drives (speed is process-critical), 5 seconds for temperature

MQTT topics published:

plant/stamping/line-A/drive-1/speed-setpoint
plant/stamping/line-A/drive-1/speed-actual
plant/stamping/line-A/drive-2/speed-setpoint
plant/stamping/line-A/drive-2/speed-actual
plant/stamping/line-A/drive-3/speed-setpoint
plant/stamping/line-A/drive-3/speed-actual
plant/stamping/line-A/temp-sensor/celsius

QoS settings:

Drive speed data: QoS 1 (at least once - process data, delivery matters)
Temperature: QoS 0 (fire and forget - high frequency, occasional loss acceptable)

Any downstream subscriber - a historian, a SCADA dashboard, a cloud analytics platform - subscribes to the topics it needs. The drives don't know MQTT exists. The gateway handles everything.

Common Modbus RTU to MQTT Integration Problems and How to Fix Them

Problem	Likely Cause	Fix
No data from a device	Wrong node address or baud rate mismatch	Confirm serial settings match device datasheet exactly
Data looks wrong or implausible	Register offset error - the ±1 trap	Check whether vendor doc uses register numbers or protocol addresses
Intermittent data drops	RS-485 termination issue or polling too fast	Add termination resistors at both ends of the bus; reduce poll rate
Gateway connects but nothing publishes	MQTT broker authentication failure	Verify credentials, port (8883 for TLS), and firewall rules
Slow polling across many devices	Too many devices on one bus at low baud rate	Calculate expected cycle time; split devices across buses or increase baud rate
CRC errors logged by gateway	Electrical noise on RS-485 cable	Check cable quality, grounding, and stub lengths; reduce baud rate if needed

Conclusion

Modbus RTU isn't going away, and it shouldn't have to. The devices running on it are reliable, the control logic built around it is proven, and replacing that hardware to solve a data visibility problem is a cost that rarely makes business sense. The smarter path is a protocol gateway at the edge that bridges what you already have to the data architecture you're building toward.

MQTT is what makes that bridge scalable. Once your Modbus RTU devices are publishing to an MQTT broker, the data stops being siloed on a serial bus and becomes an addressable, subscribable stream that any downstream system can consume, such as historians, SCADA platforms, cloud analytics, or AI workloads, without adding polling overhead or touching the devices themselves. That's the architectural shift that takes OT data from locally useful to enterprise-ready.

HiveMQ is built for exactly this. Whether you're connecting a handful of legacy devices on a single RS-485 bus or scaling across hundreds of devices across multiple sites, HiveMQ handles the broker-side routing, security, and reliability that industrial data pipelines require.

HiveMQ Edge brings the protocol translation directly to the edge, with native Modbus RTU and TCP support, so your operational data flows from the shop floor to wherever it needs to go, without rearchitecting what already works.