Modbus to MQTT Bridges: Three Patterns From Quick Win to Refactor

Modbus is the protocol that refuses to die — for good reason. It runs on power inverters, energy meters, HVAC controllers, motor drives, and tens of millions of installed devices. If your IoT project touches anything industrial, energy, or buildings, you’ll be reading Modbus eventually.

The question is how to get that data into a modern IoT pipeline without rewriting half the plant. Three patterns work.

Pattern 1 — Drop-in Modbus-to-MQTT adapters

Pre-built devices that read Modbus over RS-485 or TCP and publish to an MQTT broker.

Common products:

• Advantech ECU / WISE series — industrial-grade, multi-protocol, well-supported
• Moxa MGate / ioLogik — same category, common in Asian deployments
• Tibbo TPS — programmable Modbus-to-MQTT bridges, more flexible than the pure-config options
• EZ Gateway / Universal Gateway — middle-ground commercial offerings

What you get: plug in the RS-485 cable or point at a Modbus TCP device, configure register-to-MQTT-topic mappings via web UI, done.

What you don’t: complex transformations, derived data, sophisticated buffering, or modern observability. These are configuration appliances, not platforms.

When this fits:

• Small deployments (< 50 Modbus devices)
• Simple data flows (read register, publish reading)
• Time-to-running matters more than long-term flexibility
• The team doesn’t want to write or operate gateway software

When it doesn’t:

• You need calculations, anomaly detection, or filtering at the edge
• The Modbus topology is complex (multiple segments, multiple register maps)
• You need integration with a custom MQTT topic structure or Sparkplug B

Pattern 2 — Gateway with edge logic

A general-purpose Linux gateway running Modbus client software, applying logic, and publishing MQTT.

Common stacks:

• Node-RED + node-red-contrib-modbus — fastest to build, low-code, suitable for small fleets
• Telegraf with the Modbus input plugin — pure data collection, ships to InfluxDB or MQTT
• Custom Python or Go — pymodbus or goburrow/modbus, full control, integrates with your codebase
• Industrial offerings: Inductive Automation Ignition, Cirrus Link MQTT Modules, Cogent DataHub

What you get: real edge processing — derived calculations, filtering, alarm generation, buffering during outages. Modern observability via Prometheus or OpenTelemetry. Integration with whatever MQTT topic structure or Sparkplug B encoding you need.

When this fits:

• Medium deployments (50–500 Modbus devices)
• You need calculations beyond what configuration appliances do
• The team can operate Linux gateways
• The deployment will evolve over years and you want flexibility

When it doesn’t:

• The deployment is one-off and small (Pattern 1 is cheaper)
• The deployment is huge and standardised (Pattern 3 may scale better)

For broader edge gateway architecture see our gateway patterns post.

Pattern 3 — Modbus replaced by OPC UA at the edge

A more invasive pattern but the right call for serious industrial deployments.

The gateway:

1. Reads Modbus from the legacy device
2. Maps the Modbus registers into a structured OPC UA information model
3. Exposes the OPC UA model to local SCADA or other consumers
4. Publishes the data upstream via OPC UA Sparkplug B over MQTT

Why this is worth the work:

• OPC UA’s information model preserves type and unit information — Modbus is just numbered registers
• Local SCADA / HMI systems get the structured model they expect
• New equipment that arrives speaking OPC UA natively integrates with the same model
• Sparkplug B over MQTT (see our OPC UA post) is the right cloud egress for serious industrial data

When this fits:

• Plant-floor IIoT with tens of thousands of registers
• Long deployment horizon (10+ years)
• Mix of legacy and modern equipment expected to evolve
• Customer has SCADA / MES integration requirements

When it doesn’t:

• Small / quick deployments where the OPC UA stack overhead doesn’t pay back
• Pure-data flows where no one needs the structured model

The Modbus-specific gotchas

Three things that bite teams new to Modbus:

1. Register types are not standard

Modbus has four register classes: Coils (read/write 1-bit), Discrete Inputs (read 1-bit), Input Registers (read 16-bit), Holding Registers (read/write 16-bit). Vendors don’t agree on which class their data lives in. Always read the device’s register map; never guess.

2. Endianness is a war zone

Modbus registers are 16-bit. 32-bit floats and ints span two registers. The order of those two registers — high-low or low-high — is not specified by Modbus. Each vendor picks. Some vendors switch within a single device’s register map.

For every device, read four bytes interpreted as both byte orders and pick the one that matches the expected value. Document the choice in the register map. Re-test when firmware updates.

3. Polling cadence vs response time

Modbus is request-response. The slave (the device) responds when polled. Polling 100 registers across 50 devices on a single RS-485 segment can take seconds. Plan the polling schedule against the data freshness requirement.

For high-volume polling, consider Modbus TCP over Ethernet (much faster than RS-485) or splitting RS-485 segments to parallelise.

What we typically deploy

For a plant or building Modbus integration in 2026:

• Small (< 50 devices, simple flows): Pattern 1 — pick an Advantech or Moxa adapter
• Medium (50–500 devices, edge logic needed): Pattern 2 — Linux gateway running custom Go or Python, publishing Sparkplug B
• Large industrial (500+ devices, multi-vendor): Pattern 3 — OPC UA model at the edge, Sparkplug B to cloud

In every case, document the Modbus register map, byte order, and polling cadence per device. The documentation is the part that survives team changes; the code is replaceable.

What we hand over

For a Modbus integration engagement:

• Per-device register map with type, unit, byte order, polling cadence
• Gateway stack (Pattern 1 / 2 / 3 depending on scope)
• Cloud-side topic structure or Sparkplug B model
• Operational runbook for adding a new Modbus device
• Test harness that simulates Modbus devices for CI

If you are wrestling with a Modbus integration — particularly the legacy mess of mixed register conventions — we run these as fixed-scope engagements.