Modbus to MQTT Guide

Two protocols that were never meant to meet

Almost every industrial IoT project eventually reaches the same sentence: "we just need to get the Modbus data into the cloud." It sounds like a plumbing job. It is closer to a translation job, because Modbus and MQTT do not merely use different wires. They describe the world in fundamentally different ways.

Modbus has been in service since 1979. It is deterministic, polled and register-based. A controller (the client, historically called the master) asks a device (the server, historically the slave) for the contents of a numbered register, and the device answers. Nothing happens unless something asks. The data is a bare 16-bit number with no name, no unit and no timestamp attached to it on the wire.

MQTT arrived twenty years later, in 1999, from a different problem entirely: moving telemetry over expensive, unreliable satellite and cellular links. It is event-driven and loosely coupled. Devices publish messages to named topics on a central broker, and any interested system subscribes. Nobody polls anyone. The publisher does not know or care who is listening.

So a Modbus to MQTT bridge is not just changing the connector. It is converting a synchronous, request-and-response, number-in-a-box world into an asynchronous, publish-and-subscribe, message world. Understanding that gap is the difference between a bridge that quietly works for a decade and one that produces a topic full of numbers nobody can interpret.

What Modbus actually gives you, and what it does not

Modbus exists in two common forms that share one data model. Modbus RTU is a compact binary protocol carried over serial: RS-232 for point-to-point, or far more commonly RS-485 for a multidrop bus of several devices on one pair of wires. Modbus TCP is the same register model wrapped in an Ethernet frame and carried over IP. The register model is identical in both; only the transport changes.

That register model is deliberately simple. Data lives in four tables: coils and discrete inputs (single bits, for things like a relay state or a running flag) and holding registers and input registers (16-bit words, for things like a temperature or a meter reading). A handful of function codes read or write them. It is a model an engineer can reason about with a datasheet and a calculator, which is exactly why it has outlived almost everything designed alongside it.

The simplicity is also the catch. A holding register does not tell you what it contains. Register 40001 might hold a temperature in tenths of a degree, a fault code, or the high word of a 32-bit energy total that spans 40001 and 40002. The meaning lives in a document written by whoever commissioned the device, not in the data. Modbus gives you no units, no engineering names, no data types beyond the raw word, no timestamps, and no way for a device to describe itself. It also never pushes: if you want a new reading, you ask again.

What MQTT changes

MQTT replaces the poll with a broker and a subscription. A publisher connects to the broker, publishes a message to a topic such as site12/plantroom/ahu3/supply_temp, and disconnects from the conversation. Subscribers to that topic receive a copy. The broker is the post office; publishers and subscribers never address each other directly. This decoupling is the whole point, because it means you can add a dashboard, a historian and an analytics service to the same data stream without reconfiguring a single field device.

MQTT is an OASIS standard and an ISO recommendation (ISO/IEC 20922), which matters when you need to justify a protocol choice to a security team or a client. It also brings features that suit exactly the constrained and intermittent links common in industrial IoT: three quality-of-service levels (fire-and-forget, at-least-once and exactly-once delivery), retained messages so a late subscriber immediately receives the last known value, a Last Will and Testament message the broker publishes if a client drops unexpectedly, and a keep-alive timer so the broker knows a client is still alive. Run it over TLS on port 8883 and the transport is encrypted as well.

But MQTT on its own only solves half the problem, and it is important to be honest about which half.

What the bridge in the middle actually does

A Modbus to MQTT gateway is the component that reconciles the two worlds. On one side it behaves as a Modbus client, on the other as an MQTT publisher, and in between it does the work that makes the data useful. A well-built bridge performs most of the following:

• Polls the Modbus devices on a schedule, because Modbus will not volunteer anything.
• Applies the register map, turning register 30012 into a named, typed value such as phase A current in amps.
• Handles data typing and scaling: combining word pairs into 32-bit values, applying multipliers, converting signed and unsigned integers or floats.
• Adds a timestamp at the moment of reading, which the Modbus data never carried.
• Publishes to a sensible topic structure, so the meaning is legible from the topic alone.
• Reports by exception where possible: publishing when a value changes beyond a deadband, rather than flooding the broker with identical readings every poll.
• Buffers during a network outage (store and forward) and replays when the link returns, so a dropped cellular connection does not become a hole in the record.
• Optionally accepts commands back: subscribing to a control topic and writing the received value into a Modbus register.

A typical energy-monitoring path makes the shape of it concrete:

The interesting engineering is concentrated in the middle box. Everything before it is a well-understood field bus, and everything after it is standard messaging. The bridge is where a number acquires a name, a type, a scale, a time and a destination. That is the value it adds, and it is why choosing a bridge on transport specifications alone misses the point.

The trap: putting the register number in the topic

The quickest way to get Modbus data onto MQTT is to publish each register straight to a topic named after its address. It looks like progress. A subscriber sees:

site12/meter1/40001  =  2317

and it means nothing without the same register map you were trying to escape. Is 2317 volts, watts, a scaled current, or half of a 32-bit total? Every consuming system now needs the vendor document, the byte order and the scaling factor hard-coded into it. Change a meter for a different model and every dashboard breaks. You have not bridged the two worlds. You have carried the Modbus problem across the bridge and set it down on the other side.

For a handful of values feeding one dashboard, a clean structured payload solves this well enough: publish JSON such as {"current_a": 231.7, "unit": "A", "ts": "2026-09-07T09:14:00Z"} to a descriptive topic. It is readable, self-contained and perfectly adequate for many deployments. The difficulty appears at scale, when dozens of gateways feed shared analytics and every integrator has invented a slightly different topic tree and payload shape. That is the problem Sparkplug was designed to remove.

Sparkplug B: making MQTT industrial

Sparkplug B is an open specification from the Eclipse Foundation, developed under the Eclipse Tahu project and authored by Arlen Nipper, one of the original co-inventors of MQTT. The current release, Sparkplug 3.0.0, was published in November 2022 and was the first formal specification issued by the Eclipse Sparkplug Working Group. It does not replace MQTT. It sits on top of it and adds the three things plain MQTT leaves undefined.

The first is a defined topic namespace, so a subscriber can reason about what a topic means without a vendor manual. The second is a strongly typed payload format using Protocol Buffers, so a value arrives with its data type, and often its engineering context, built in rather than assumed. The third, and the one that matters most in operational technology, is state management.

Report by exception is efficient, but it creates a question: if a value has not been published for ten minutes, is it unchanged, or is the device dead? Sparkplug answers this with birth and death certificates. When an edge node connects it publishes a birth certificate (NBIRTH) declaring itself and every metric it will report. Its death certificate (NDEATH) is registered with the broker in advance as the MQTT Last Will message, so if the node drops off ungracefully the broker publishes the death on its behalf. Combined with the keep-alive timer, every subscriber always knows whether silence means "nothing changed" or "this node is gone". Devices behind a node use the same pattern with DBIRTH and DDEATH verbs, and commands flow back with NCMD and DCMD.

Where the bridge should run

Once you accept that the bridge is where the real work happens, the practical question becomes where that component physically lives. There are four common answers, and the right one depends on the size of the site and how much local logic you need.

On the router or gateway itself

Many industrial cellular routers now perform Modbus to MQTT conversion natively, with no separate protocol converter. Teltonika devices running RutOS, for example, can read Modbus registers and publish them as MQTT topics on the device, which is exactly the architecture we describe in our guide to SCADA over cellular and in the verified deployment covered in the Schneider Electric and Teltonika connectivity piece, where a Schneider energy meter reaches a cloud dashboard through a single cellular gateway. Collapsing router, protocol converter and publisher into one box removes hardware, reduces failure points and simplifies commissioning.

On an edge computer running a flow engine

Where the mapping is complex, or you want a visual and maintainable definition of it, a flow engine such as Node-RED is a natural fit. Its Modbus and MQTT nodes let you poll registers, transform and scale values, and publish the result, all in a flow you can read and hand over. That engine can run on the router, as it does on the Milesight development platform, or on a dedicated single-board computer or industrial PC. Choosing between an integrated router and separate compute is its own decision, one we work through in SBC versus industrial router for edge computing.

On a dedicated protocol converter

Purpose-built converter appliances still have a place, particularly in retrofits where the networking is already handled and you simply need a hardened, certified box to translate between a field bus and a broker. They add a device to the bill of materials, but they concentrate the translation in one auditable place.

On a self-hosted broker or server

For estates that would rather not depend on a vendor cloud, a modest server can host the broker itself, with a flow engine polling remote devices over a VPN and republishing. We walk through a low-cost version of exactly this pattern in running IoT and M2M services on a small VPS, where one instance carries a broker, a Modbus proxy and a VPN endpoint.

Does the data have to reach the cloud?

No, and it is worth saying plainly because the phrase "get the data to the cloud" quietly assumes an answer. The broker is the destination that matters, and a broker can sit on a server in the plant room just as easily as in a hyperscale region. On-premises brokers and unified-namespace architectures are entirely valid, and for some regulated or latency-sensitive environments they are preferable.

The realistic pattern for a multi-site operator is usually hybrid: each site runs its own broker and keeps working if the wider network fails, while selected values, alarms and summaries are forwarded to a central platform for portfolio-wide reporting. Local control stays local; the cloud provides comparison and context. A boiler or pump should never wait for a round trip to a remote service to decide what to do.

Cellular connectivity fits this honestly rather than universally. A large occupied building may already have resilient fixed connectivity. Cellular becomes valuable for dispersed sites, unmanned plant rooms, temporary installations, and cases where a landlord or tenant will not allow the building systems onto the corporate network, or as an independent backup path. The addressing decisions that go with it, private APN versus public IP, matter as much as the signal, which is why we treat them separately in private versus public IP for cellular IoT.

The bridge is a new front door

Connecting a Modbus network to a broker changes a security assumption that most industrial installations were built on: that the field bus was physically isolated and therefore did not need to defend itself. The moment those registers become reachable through a gateway, that assumption is gone, and the bridge itself becomes something worth attacking.

The baseline controls are well established. Keep operational technology on its own network segment, separated from general office IT. Prefer outbound-only, encrypted connections from the gateway to the broker, MQTT over TLS rather than plaintext. Authenticate clients with credentials or, better, certificates, and use topic access-control lists so a compromised sensor cannot subscribe to command topics. Do not expose broker or device management interfaces to the public internet. Our wider treatment of these controls lives in the IoT security guides.

There is also an unglamorous point that fails more deployments than any exploit. When a gateway dies and a replacement is pulled from stores, can anyone rebuild its register map, topic structure, credentials and APN settings? A perfectly healthy plant can sit unreachable because nobody backed up the configuration of a modest gateway. That configuration is part of the system, and it belongs in a recovery plan, as we argue in OT backup and recovery.

What to settle before you bridge anything

A Modbus to MQTT project rarely fails on the protocols. It fails on the decisions around them. Before buying a gateway or picking a broker, an honest project has answers to the following:

1. The register map: which registers, in what units, at what scale and byte order, and who owns and maintains that document.
2. The topic and naming convention, agreed once and applied everywhere.
3. Whether you publish every poll or report by exception, and what deadband counts as a real change.
4. Where the timestamp comes from, and which time zone it is in.
5. Which quality of service level each stream needs, and whether values should be retained.
6. What the gateway does during an outage: buffer and replay, or accept the gap.
7. Whether plain JSON is sufficient or the estate genuinely needs Sparkplug and a unified namespace.
8. Whether the bridge is read-only or permitted to write, and who authorises writes.
9. How TLS, credentials and certificates are issued, rotated and revoked.
10. How the whole configuration is backed up and restored when hardware fails.

Answer those and the wiring is straightforward. Skip them and you will have a topic full of numbers and an argument about what they mean.

That is the real reason a Modbus to MQTT bridge is worth building carefully. The measurement was always there in the plant room, sitting in a register nobody could reach. The bridge is what turns it from a private number into shared, trustworthy evidence, the kind an engineer, a dashboard or an analytics model can actually act on. Get the meaning right and the rest is just messages.

Frequently asked questions