MQTT for Industrial Sensors: From Field Device to Cloud - MQTT is the lightweight publish/subscribe protocol behind many industrial IoT dashboards. This guide explains brokers, topics, QoS levels, TLS, Modbus-to-MQTT bridging, and how to keep LPWAN payloads small while still integrating sensors with the cloud.
Industrial sensors produce small, frequent facts: temperature, pressure, level, a vibration alert. Dashboards, historians, and alarm engines need those facts in near real time—without each device opening a heavy HTTP session. That is why so many IoT platforms speak MQTT.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol designed for constrained devices and unreliable networks. This guide covers how MQTT works, how to design topics and QoS for sensors, how to secure brokers, and how MQTT sits beside fieldbuses like Modbus and radios like LoRaWAN—aligned with nowsens. IoT integration patterns.
Publish/Subscribe in One Minute
Three roles matter:
- Publisher — a sensor gateway or device that sends a message to a topic (for example plant/tank3/level).
- Broker — the server that receives publishes and forwards them to interested clients.
- Subscriber — a dashboard, SCADA connector, cloud function, or another gateway that listens to topics.
Publishers and subscribers never talk directly. That decoupling is the point: add a new analytics consumer without touching the sensor firmware. Compare that to classical Modbus polling, where a master must know every slave address—see Modbus RTU vs TCP.
Topics: Naming That Scales
Topics are UTF-8 paths, usually hierarchical. Wildcards let subscribers scoop up families of sensors:
- + — single level (for example plant/+/temperature)
- # — multi-level (for example plant/#)
A practical industrial convention:
| Segment |
Example |
Why |
| Site / plant |
houston-north |
Multi-site brokers stay readable |
| Area / line |
wwtp/clarifier2 |
Operations think in areas |
| Asset |
tank-07 |
Stable ID, not a changing IP |
| Metric |
level_cm |
One topic per quantity (or a JSON payload with several fields) |
Example: houston-north/wwtp/tank-07/level_cm. Avoid putting secrets in topic strings. Prefer opaque asset IDs over customer names if topics are widely subscribed.
Payload style: for LPWAN-fed systems, keep JSON tiny ({"v":312,"u":"cm","ts":1710000000}) or use CBOR/binary. Verbose HTML-like payloads waste radio duty cycle—see power management.
QoS Levels: What "Delivered" Means
| QoS |
Name |
Behavior |
Sensor use |
| 0 |
At most once |
Fire and forget |
High-rate non-critical samples |
| 1 |
At least once |
Retry until ACK; duplicates possible |
Default for most telemetry |
| 2 |
Exactly once |
Four-step handshake; highest overhead |
Rare; billing-critical events |
Most industrial sensor fleets use QoS 1 for alarms and QoS 0 for dense trend samples. Make consumers idempotent: handle duplicate QoS 1 messages without double-counting events.
Retained messages store the last payload on a topic so a new subscriber immediately sees the latest value (useful for "current setpoint" or "last known level"). Do not retain high-frequency noise—retain state, not every sample.
Last Will and Testament (LWT) lets a device register a message the broker publishes if the client disconnects uncleanly—handy for "gateway offline" alarms.
Brokers, Sessions, and Keepalive
Choose a broker that matches your ops model: managed cloud MQTT, on-prem Mosquitto/EMQX/HiveMQ, or an IoT platform's built-in endpoint. Industrial checklists:
- Authentication — username/password, certificates, or token auth; never anonymous on the public internet.
- Authorization — ACL so a tank sensor cannot publish to another plant's topics.
- TLS — encrypt in transit (MQTT over TLS, typically port 8883).
- Persistence — durable sessions and queues if subscribers can go offline.
- Observability — metrics for connect storms, ACL denials, and queue depth.
Keepalive and session expiry must match flaky WAN links. Too aggressive and mobile or LPWAN gateways flap; too loose and dead clients linger.
Security Baseline
- TLS everywhere outside a sealed control VLAN.
- Per-device or per-gateway credentials—not one shared password for the fleet.
- Topic ACLs mirroring plant hierarchy.
- Separate broker accounts for devices vs. dashboards vs. admins.
- Rotate credentials when a gateway is decommissioned.
MQTT is not a VPN and not a safety PLC network. Treat it as an IT/OT integration bus with explicit trust boundaries.
From Modbus (and Other Fieldbuses) to MQTT
Most installed instruments still speak Modbus RTU/TCP, 4–20 mA, or vendor protocols. A common pattern:
- Edge gateway polls Modbus registers on a short RS-485 spur or plant Ethernet.
- Gateway maps registers → engineering units.
- Gateway publishes MQTT topics to the broker on a schedule or on change-of-value.
- Cloud apps subscribe; they never open Modbus toward the plant.
That preserves field wiring while enabling remote monitoring. Publish only the registers you need—do not mirror entire maps over the WAN. For protocol detail, use the Modbus guide.
LPWAN and MQTT: Two Layers
LoRaWAN and NB-IoT move bytes over the air; MQTT usually sits north of the network server or cellular IoT core, not as a raw LoRaWAN frame format. Typical path:
- Device → LPWAN → network server / operator → application integration → MQTT broker → subscribers.
Sometimes a site gateway speaks MQTT directly on Ethernet/Wi-Fi while sensors remain LoRaWAN or wired. Either way, keep radio payloads minimal and let MQTT fan-out happen where power and bandwidth are cheap. For radio choice, see LoRaWAN explained and NB-IoT vs LoRaWAN.
QoS, Timestamps, and Measurement Trust
MQTT delivers messages; it does not certify that a temperature reading is accurate. Stamp samples at the edge when possible, document units, and keep calibration intervals honest—see accuracy, resolution, and calibration. Dashboards should display stale-data age so a silent sensor is obvious.
Testing Before Production
Before connecting the plant broker to the internet:
- Publish a known fixture payload and confirm every subscriber renders units correctly.
- Kill the publisher mid-session and verify LWT / offline alarms fire once—not in a storm.
- Force a broker restart and confirm durable sessions recover without duplicate work orders.
- Attempt an ACL violation from a test client and confirm it is denied and logged.
- Measure message rate at peak (shift change, batch end) so QoS 1 queues stay within broker limits.
Treat MQTT like any other industrial interface: change control, versioned topic docs, and a rollback plan when a gateway firmware update mis-maps registers.
Sparkplug and Industrial Conventions
Some plants standardize on Sparkplug B (MQTT with a defined topic namespace and birth/death certificates for edge nodes). You do not need Sparkplug to succeed with sensors, but if your OT team already runs Ignition or similar, ask whether they expect Sparkplug payloads. Otherwise a simple hierarchy plus JSON is enough for most monitoring projects—and easier for constrained gateways to produce.
Whatever convention you pick, write it down: topic examples, units, timestamp format (prefer UTC epoch or ISO-8601), and how alarms differ from trends. Onboarding the twentieth sensor should be copy-paste, not invention.
Failure Modes Worth Designing For
- Broker restart — clean session vs durable session; who replays what.
- Clock skew — edge timestamps vs broker receive time; show both if you debug latency.
- Topic explosion — one topic per noisy raw sample can overwhelm ACL tables; aggregate at the edge.
- Shared credentials — a leaked gateway password publishing as every device; use unique identities.
- Silent sensors — subscribe to LWT and monitor "last seen"; do not assume no news is good news.
Implementation Checklist
- Define a topic taxonomy before the first pilot device goes live.
- Pick QoS per message class (trend vs alarm).
- Enable TLS and ACLs on day one—not after the first incident.
- Bridge Modbus (or other field protocols) at the edge; publish sparse MQTT.
- Load-test the broker for connect storms (power restoration after outage).
- Document retained topics and LWT behavior for operators.
- Agree timestamp, unit, and alarm conventions before scaling past the pilot.
Key Takeaways
- MQTT decouples industrial sensors from dashboards via a broker and topics.
- Hierarchical topics and sensible QoS make fleets operable.
- TLS + ACLs are mandatory for internet-facing brokers.
- Modbus stays at the edge; MQTT carries selected values to the cloud.
- LPWAN and MQTT solve different layers—radio vs application messaging.
Planning a Modbus-to-MQTT bridge or a multi-site broker layout? Contact the nowsens. engineering team—we will help you design topics, QoS, and edge mapping that stay maintainable as the fleet grows.
