Modbus to MQTT: A Step-by-Step Guide to Register Maps, Topics and Payloads

How do you get Modbus to MQTT? Put a gateway between the devices and the broker. It polls Modbus RTU or Modbus TCP registers on a schedule, converts raw values using a register map, and publishes them to MQTT topics as JSON or Sparkplug B. Add report by exception, buffering and TLS before production.

By TouchVision Engineering Team · Published 31 October 2026 · Last updated 31 October 2026

This guide is written by the engineering team of Beijing Huamei Xuntong Technology Co., Ltd. (TouchVision), a manufacturer founded in 2012 that designs and builds industrial displays, embedded boards, HMI panels, industrial gateways and edge AI computers.

Why convert Modbus to MQTT at all?

Modbus to MQTT conversion lets decades-old meters, drives and PLCs feed modern dashboards and cloud platforms without replacing the devices or opening inbound connections to the plant network. Modbus is a request-response protocol designed for one master and many slaves; MQTT is a publish-subscribe protocol designed for many consumers and unreliable networks.

The two fit together through a gateway. On the field side the gateway acts as Modbus master (client), asking each device for values. On the IT side it acts as an MQTT client that publishes those values to a broker, from which SCADA, historians, MES and cloud services subscribe. Because the gateway connects outward to the broker, the firewall does not need inbound rules toward the controllers. Japanese, Brazilian and German integration guides describe the same basic architecture; the differences are in how carefully the register map and topic design are done.

Step 1: what should the device inventory and register map contain?

The register map is the foundation of any Modbus to MQTT project: it tells the gateway what to read, how to decode it and what to call it. Most project delays come from incomplete or ambiguous maps rather than from the gateway itself.

For each device, record the interface (Modbus RTU on RS-485, or Modbus TCP on Ethernet), the slave or unit ID, the serial settings, and then one line per value:

Field	Example	Why it matters
Register type and function code	Holding registers, function code 03 (input registers use 04)	Wrong function code returns an exception or the wrong data
Address and offset	Documented as 40101, sent as address 100	Many manuals use 1-based “4xxxx” numbering while the protocol uses 0-based addresses
Data type and length	32-bit float over two 16-bit registers	Each Modbus register holds only 16 bits
Byte order and word order	Big-endian bytes, low word first	Swapped words produce plausible but wrong values
Scaling and unit	Raw × 0.1 = kWh	Integer registers often carry implied decimals
Name and topic	site1/line2/meter07/energy_kwh	Becomes the MQTT topic and data point name

Verify a few values against the device’s own display before scaling up. A reading that is off by a factor of 10 or looks random usually points to scaling, the address offset or byte order.

Step 2: how do you choose the polling interval?

Set the polling interval from how fast each value really changes and what the bus can carry, not from the fastest rate the gateway supports. On Modbus RTU, every request and response shares one half-duplex RS-485 line, so the total cycle time grows with every device and register block.

• Group adjacent registers into one read request instead of reading them one by one.
• Poll fast-changing values (power, current, alarms) every second or few seconds; poll slow values (energy totals, temperatures, configuration) every 30 to 60 seconds.
• Split large installations across several RS-485 ports so that one slow or offline device does not delay the others; set sensible timeouts and retry counts.
• For Modbus TCP, limit the number of simultaneous connections the device accepts; some meters handle only a few.

Step 3: how should the MQTT topic structure be designed?

A good MQTT topic structure is hierarchical, stable and readable, so subscribers can use wildcards to pick up exactly the data they need. A common pattern follows the physical or ISA-95 hierarchy: enterprise/site/area/line/device/measurement.

Keep topic levels lowercase without spaces, avoid putting changing values such as timestamps into the topic, and separate telemetry from commands, for example .../meter07/data for readings and .../meter07/cmd for writes. Publish a gateway status topic with an MQTT last-will message so consumers know when a gateway goes offline. Many sites now build a “unified namespace” this way, where every system publishes its current state into one shared topic tree.

Step 4: what should the JSON payload look like?

A JSON payload should carry the value, its timestamp and a quality flag at minimum, so that consumers can tell a real zero from a failed read. A typical message looks like this:

{"ts":"2026-10-31T09:00:00+08:00","value":1523.4,"unit":"kWh","quality":"good"}

Decide early whether each topic carries a single value or a device object with many values. Single-value topics are simple to consume; device objects reduce message count on cellular links. Keep the format documented and versioned, because every dashboard built later will depend on it.

Step 5: when should you use Sparkplug B instead of plain JSON?

Use Sparkplug B when several vendors’ systems must discover devices and understand their state automatically; use plain JSON when one team controls both ends. The Eclipse Sparkplug specification standardises the topic namespace as spBv1.0/group_id/message_type/edge_node_id/device_id and defines message types such as NBIRTH, NDEATH, DBIRTH, DDATA and DCMD.

Birth messages announce every metric with its data type; death messages, delivered through the MQTT last will, mark data as stale when a node disconnects. Payloads are binary-encoded with Protocol Buffers, which saves bandwidth but makes debugging less convenient than JSON. Check whether your gateway firmware and your SCADA both support Sparkplug B before choosing it; US integrators such as Corso Systems publish practical introductions for SCADA teams weighing the choice.

Step 6: how do report by exception, QoS and retained messages fit together?

Report by exception sends a value only when it changes by more than a deadband, which can cut traffic sharply on slow-changing data, while a periodic heartbeat proves the link is still alive. The gateway still polls Modbus at the set interval; it simply publishes less.

• Deadband: set an absolute or percentage threshold per value, such as 0.5 °C or 1% of span.
• Heartbeat: publish all values at a longer interval anyway, for example every 5 or 15 minutes.
• QoS: the MQTT 5.0 standard defines QoS 0 (at most once), 1 (at least once) and 2 (exactly once). QoS 1 is a common choice for telemetry, with consumers tolerating occasional duplicates.
• Retained message: mark the latest value or status as retained so a new subscriber immediately receives the current state.

Step 7: how do you secure and buffer the link?

Encrypt the MQTT connection with TLS, authenticate every gateway individually, and buffer data locally so a broken uplink does not create gaps. The registered port for MQTT over TLS is 8883; plain port 1883 should stay inside trusted networks only.

• Use a unique username and password or client certificate per gateway, and restrict each one to its own topic branch on the broker.
• Enable store-and-forward so readings collected during an outage are published with their original timestamps when the link returns.
• Handle Modbus writes carefully: accept them only on a dedicated command topic, validate ranges in the gateway, and log every write.
• Keep the RS-485 and controller network separate from the uplink network.

Step 8: how do you test a Modbus to MQTT setup?

Test from the field side outward: confirm Modbus reads at the gateway, then confirm the broker receives correct topics and payloads, then confirm the consuming application. Subscribing with a command-line client such as mosquitto_sub -t 'site1/#' -v shows exactly what the gateway publishes.

• Register map reviewed, with addresses, types, byte order and scaling verified against the device display.
• Polling groups and intervals set; cycle time measured on each RS-485 port.
• Topic tree and payload format documented.
• Deadbands and heartbeat configured; QoS and retained flags chosen.
• TLS on 8883, per-gateway credentials and topic permissions enabled.
• Store-and-forward tested by unplugging the uplink.
• Write commands restricted, validated and logged.

Which TouchVision products handle Modbus to MQTT?

The TouchVision TV-IS013 gateway is designed for exactly this job, and the TV-W-GYWG covers sites that mix Modbus with CAN, analogue and low-power radio links. Both are configured per project.

The TV-IS013 industrial IoT gateway has two RS-485 ports, two Gigabit Ethernet ports, CAN, 4G and Wi-Fi, and supports Modbus, MQTT, OPC UA and HTTP with data encryption and remote configuration. The TV-W-GYWG supports Modbus-TCP and Modbus-RTU over two RS-485 ports, acts as a TCP server for up to 16 clients and uplinks over Ethernet, 4G, NB-IoT or LoRa. For local dashboards, HMaker SCADA can subscribe to the same data. Typical projects include energy metering and power automation and EV charging sites. For hardware selection, see our guide on how to choose an industrial IoT gateway.

Frequently asked questions

What is the difference between Modbus RTU to MQTT and Modbus TCP to MQTT?

Modbus RTU runs over serial RS-485, so the gateway needs RS-485 ports and polls devices one at a time on a shared line. Modbus TCP runs over Ethernet, which is faster and allows parallel connections. The MQTT side is the same in both cases.

Why do my Modbus values look wrong after conversion?

The usual causes are the 1-based vs 0-based address offset, the wrong function code, swapped byte or word order on 32-bit values, or missing scaling factors. Compare a few values with the device display.

Is Sparkplug B required?

No. Plain JSON over MQTT works well when one team controls both ends. Sparkplug B adds standard topics, birth and death messages and automatic tag discovery, which helps in multi-vendor systems.

Which MQTT QoS should I use for telemetry?

QoS 1 is a common choice: delivery is guaranteed at least once and consumers handle rare duplicates. QoS 0 suits high-rate data where a lost sample does not matter; QoS 2 adds overhead and is rarely needed for telemetry.

Can MQTT write values back to Modbus devices?

Yes, through a dedicated command topic that the gateway turns into Modbus write function codes. Restrict who can publish to it, validate ranges and log every write.

Sources and standards referenced

• OASIS: MQTT Version 5.0
• Eclipse Sparkplug
• Modbus Organization
• EMQX: Bridging Modbus data to MQTT (Japanese)
• LRI: Como integrar Modbus com MQTT (Portuguese, Brazil)
• HiveMQ: Modbus RTU to MQTT
• Corso Systems: MQTT and Sparkplug B simplified
• IANA: service name and port registry (MQTT)