Why MQTT Has Become the Standard in Industrial IoT
The Industrial IoT generates millions of data points every day: sensors that report every minute, PLCs that send status updates every second, and meters that transmit hourly readings. These data streams must be transmitted reliably, efficiently, and securely.
MQTT meets these needs exactly:
- Ultra-lightweight — 2- to 5-byte headers. HTTP/REST generates hundreds of bytes of headers for a payload of just a few bytes.
- Persistent connection — the gateway connects to the broker once and maintains the connection. No TCP handshake is required for each message.
- Publish/Subscribe — multiple subscribers (cloud monitoring, ERP, BI) can receive the same data without the gateway being aware of it.
- Configurable QoS — depending on the criticality of the data.
- Resilience — messages are stored if the client is temporarily disconnected (retain, persistent session).
Industrial MQTT Architecture
MQTT Topics: Structure and Best Practices
An MQTT topic is a hierarchical chain separated by /:
eziwan/{site_id}/{equipment}/{variable}
Exemples :
eziwan/pumping-station-01/control-panel/discharge-pressure
eziwan/site-pompage-01/compteur/energie_kwh
eziwan/batiment-paris/cvc/temperature_zone_a
Best Practices for Naming:
- Always include the site ID to filter by site.
- Separate data types (measurement, status, alarm, command) into distinct topics.
- Use human-readable names, not obscure codes.
- Avoid overly broad topics (
eziwan/#) for production subscriptions.
QoS Levels: What’s the Best Choice for Industry?
| QoS | Guarantee | Overhead | Recommended Use |
|---|---|---|---|
| 0 | At most once (best-effort) | Minimal | Frequent measurements (1/s), loss OK |
| 1 | At least once (with acknowledgment) | Low | Standard monitoring, alerts |
| 2 | Exactly once (4 exchanges) | Medium | Commands, critical data |
For typical industrial IoT monitoring (measurements every 5 to 60 seconds), QoS 1 offers the right balance: sufficient reliability and acceptable overhead.
MQTT vs. HTTP for the IoT: A Comparison
| Criterion | MQTT | HTTP/REST |
|---|---|---|
| Model | Publish/Subscribe | Request/Response |
| Overhead size | 2–5 bytes | 200–400 bytes |
| Connection | Persistent | Per request (or keep-alive) |
| Data push | Native (subscribe) | Polling or WebSocket |
| Latency | < 50 ms | 100–500 ms |
| Multiple subscribers | Native | Webhooks/external queues |
| Suitable for low-bandwidth IoT | ★★★★★ | ★★ |
The Eziwan Approach
The Eziwan Gateway implements an MQTT client that publishes the collected Modbus/OPC UA data to the Eziwan Cloud MQTT broker. Topics are auto-generated based on each device’s configuration. Transmission is secured via TLS with client certificate authentication—there are never any unsecured MQTT connections.
Learn more: Modbus Cloud, Industrial IoT Gateway, and Remote Site Monitoring.