Why Convert Modbus RTU to MQTT?
Modbus RTU is the language of the machine. MQTT is the language of the cloud. The Modbus RTU → MQTT bridge acts as a translator between these two worlds: it enables your legacy industrial equipment to communicate with modern IoT platforms without any changes to the existing installation.
Benefits of MQTT for Industrial Data Transmission:
- Lightweight: Minimum 2-byte header, ideal for 4G and expensive connections
- Publish/subscribe: Decoupling between production (gateway) and consumption (dashboard, API)
- Persistent session: Messages are queued during network outages
- Configurable QoS: Delivery guarantees tailored to each data type
- Native TLS: Encryption and authentication without an application-level overlay
Architecture of the Modbus RTU → MQTT Bridge
The bridge operates in two distinct and independent phases:
Phase 1 — Modbus RTU Data Collection (Field Side) The gateway acts as the Modbus master. It sends read requests (FC01/02/03/04) to the RS485 slaves according to a configurable polling schedule. Each response is decoded, scaled, and time-stamped locally.
Phase 2 — MQTT Publication (Cloud-Side) The decoded values are encapsulated in JSON messages and published to the MQTT broker. If the connection is unavailable, the messages are buffered locally (for 72 hours) and retransmitted upon reconnection with their original timestamps.
RS485 Bus Gateway Eziwan MQTT Broker
────────── ────────────────── ────────────
Esclave 1 ──┐ ┌── Modbus RTU master AWS IoT Core
Esclave 2 ──┤── RS485 ──►│ Polling FC03/FC04 MQTT Azure IoT Hub
Esclave 3 ──┤ │ Decode + Scale ──TLS► HiveMQ
Esclave n ──┘ └── JSON builder Mosquitto
Buffer 72h Eziwan Cloud
Structure of MQTT Topics for Modbus RTU
The organization of MQTT topics is crucial for maintainability and integration:
Recommended convention:
{site}/{area}/{equipment}/{tag}
Examples:
usine/atelier_a/variateur_01/frequence_hz
usine/atelier_a/variateur_01/courant_a
usine/tgbt/compteur_principale/puissance_active_kw
usine/tgbt/compteur_principale/energie_kwh
Metadata topics (Sparkplug B):
spBv1.0/factory/NBIRTH/gateway_01 ← Login Prompt
spBv1.0/plant/NDATA/gateway_01 ← Process Data
spBv1.0/factory/NDEATH/gateway_01 ← Logout (LWT)
MQTT-Compatible Brokers
The Eziwan gateway is compatible with the leading MQTT brokers on the market:
| Broker | Hosting | Protocol | Use Cases |
|---|---|---|---|
| AWS IoT Core | AWS Cloud | MQTT TLS | AWS Integration (Lambda, S3, Timestream) |
| Azure IoT Hub | Azure Cloud | MQTT / AMQP | Azure Integration (Stream Analytics, Cosmos DB) |
| HiveMQ Cloud | Managed Cloud | MQTT 5.0 + TLS | Sparkplug B, UNS, multi-broker |
| Mosquitto | Self-hosted | MQTT 3.1.1 | On-premises SCADA, minimal latency |
| Eziwan Cloud | Managed cloud | MQTT TLS | Turnkey solution, built-in dashboard |
Disconnection Handling and Buffering
Industrial networks (4G, Wi-Fi in harsh environments) are prone to outages. The Modbus RTU → MQTT bridge handles this by:
- Last Will Testament (LWT): an automatic message sent by the broker when the gateway disconnects
- Persistent session: the broker retains subscriptions and pending QoS 1/2 messages
- Local buffer: the gateway stores measurements in flash memory during the outage
- Resynchronization: upon reconnection, messages are retransmitted in chronological order
This mechanism ensures no data loss even during prolonged network outages—which is critical for energy metering and production monitoring applications.
Integration with Cloud TSDBs
MQTT data is typically stored in a time-series database (Time Series Database):
- InfluxDB: open-source, excellent for industrial metrics
- AWS Timestream: serverless, integrated with AWS IoT Core
- Azure Data Explorer: high performance for large volumes
- TimescaleDB: extended PostgreSQL, native SQL
- Eziwan Storage: storage included, configurable retention
From the TSDB, the data feeds into Grafana dashboards, performance reports, and predictive maintenance models.