Key Takeaway: MQTT for industrial IoT is the lightweight publish/subscribe protocol that lets ESP32 sensor nodes stream machine data to dashboards and SCADA in near real time — with minimal bandwidth, QoS guarantees, and built-in dead-node detection via Last Will messages.
Table of Contents
- 1. What Is MQTT and Why It Fits the Factory
- 2. Core Concepts: Broker, Topics, Publish/Subscribe
- 3. QoS Levels and Last Will
- 4. Choosing and Setting Up a Broker
- 5. ESP32 MQTT Client with PubSubClient
- 6. Payload Design and Retained Messages
- 7. Securing MQTT: Authentication and TLS
- 8. From Sensors to SCADA: A Reference Architecture
- 9. FAQ
- 10. Related Reading
- 11. Sources
1. MQTT for Industrial IoT: What It Is and Why It Fits the Factory
MQTT (Message Queuing Telemetry Transport) was designed at IBM in the 1990s to monitor oil pipelines over satellite links — unreliable networks, low bandwidth, battery-powered nodes. Those are exactly the constraints of factory-floor sensor networks today. Unlike HTTP’s request-response polling, MQTT keeps a persistent TCP connection open between every device and a central broker, and the broker pushes messages to subscribers the instant they are published.
The result is dramatically more efficient than HTTP: a typical MQTT control packet is 2–5 bytes of overhead versus 200+ bytes for HTTP headers. For machine-monitoring nodes publishing temperature, vibration, and current every few seconds, that efficiency translates into longer battery life, lower cellular costs, and true real-time dashboards. This makes MQTT for industrial IoT the de facto messaging standard for everything from predictive maintenance to production-line condition monitoring.
2. Core Concepts: Broker, Topics, Publish/Subscribe
Three roles make up MQTT. The broker is the central hub every client connects to — Mosquitto, EMQX, HiveMQ, or a managed cloud like AWS IoT Core. Publishers send messages to named topics; subscribers listen to topics they care about. The publisher and subscriber never know about each other; they only know the broker and the topic.
Topics are hierarchical strings that act like message channels. A vibration node might publish to factory/line1/vibration, and a dashboard subscribes to factory/# to receive everything under the factory tree. Wildcards make this powerful: factory/+/temperature matches any single level, while factory/# matches all descendants. Designing your topic hierarchy carefully is the architecture of your whole IoT system — use a reverse-DNS style like site/line/machine/measurement so you can scale without renumbering.
3. QoS Levels and Last Will
MQTT defines three Quality of Service levels:
- QoS 0 (at most once): fire-and-forget, no acknowledgment. Best for high-frequency telemetry where losing an occasional sample is fine.
- QoS 1 (at least once): the broker acknowledges (PUBACK) and retransmits if not acked; the subscriber may see duplicates. Best for control commands.
- QoS 2 (exactly once): a four-way handshake guarantees no duplicates. Use for billing, alarms, or commands where a duplicate would cause real harm.
The Last Will and Testament (LWT) message is a factory-floor lifesaver. You configure the broker with a “will message” when a device connects; if the device dies without a clean disconnect, the broker automatically publishes the will. A monitoring system subscribed to factory/alerts instantly knows a sensor node went offline — essential for predictive maintenance and production visibility.
4. Choosing and Setting Up a Broker
Mosquitto is the most widely used open-source broker and runs on a Raspberry Pi or any Linux box. Install it, enable the service, and you have a local broker in minutes:
sudo apt install -y mosquitto mosquitto-clients, then systemctl enable mosquitto. Test with mosquitto_sub -h localhost -t “test/topic” in one terminal and mosquitto_pub -h localhost -t “test/topic” -m “Hello” in another.
Scale is the main selection factor. A Raspberry Pi 4 running Mosquitto comfortably handles a few hundred devices. For thousands of nodes, EMQX (open source, horizontally scalable) or a managed cloud service like AWS IoT Core, Azure IoT Hub, or HiveMQ Cloud is the better choice. Many Indian factory deployments start with Mosquitto on a VPS and migrate to managed brokers as the fleet grows.
5. ESP32 MQTT Client with PubSubClient
The ESP32 is the workhorse of MQTT for industrial IoT prototyping because it combines dual-core processing with built-in Wi-Fi and Bluetooth at low cost. The most popular Arduino library is PubSubClient by Nick O’Leary. The skeleton is simple: connect to Wi-Fi, set the broker with client.setServer(broker, 1883), register a callback with client.setCallback(onMessage), then in loop() call client.loop() to keep the connection alive.
Two patterns matter in production. First, use a non-blocking reconnect loop with exponential backoff (1 s doubling up to 60 s) instead of while(!connected) blocking loops, so the node keeps reading sensors during outages. Second, call client.loop() frequently and avoid long delay() calls — the library needs regular processing to handle keep-alive pings and incoming messages. For pure ESP-IDF development, the native esp-mqtt component provides the same publish/subscribe model with full event handling and MQTT 5.0 support.
6. Payload Design and Retained Messages
Payloads should be compact and self-describing. JSON is the de facto standard and pairs with the ArduinoJson library: {“device”:”vib-node-01″,”temperature”:72.4,”vibration”:1.8,”timestamp”:1785739200}. Keep payloads small — every byte crosses the network, possibly over cellular.
Set the retained flag on important topics. A retained message is stored by the broker, so a new subscriber (like a dashboard that just opened) immediately receives the last known value instead of waiting for the next publish cycle. This is how a SCADA screen shows current machine state on connect without historical replay.
7. Securing MQTT: Authentication and TLS
Default MQTT transmits plaintext on port 1883. Inside a private factory LAN that may be acceptable, but anything internet-exposed requires security:
- Authentication: username and password per device (device credentials, not shared logins).
- TLS encryption: MQTTS on port 8883 with a Let’s Encrypt certificate on the broker; on the ESP32 use WiFiClientSecure with the CA certificate loaded.
- Network isolation: place brokers and devices on a segmented network or VPN, and restrict broker access by IP where possible.
Treat every device as a potential entry point. A sensor node with hardcoded credentials on a public broker is a liability; a fleet with per-device certificates and TLS is a defensible industrial network.
8. From Sensors to SCADA: A Reference Architecture
A practical MQTT for industrial IoT architecture has four layers. At the edge, ESP32 (or STM32 + ESP32) nodes sample vibration, current, and temperature and publish to factory/<line>/<machine>/<metric>. The broker layer — Mosquitto or EMQX — routes messages and stores retained state. The integration layer uses Node-RED to parse JSON and forward data to databases, or bridges to OPC-UA/Modbus for legacy PLCs. The visualization layer runs Grafana or a custom dashboard subscribed to the same topics, triggering alerts when thresholds are crossed.
This same stack supports the condition-monitoring patterns in our predictive maintenance guide, and it coexists with traditional fieldbus: RS-485/Modbus remains excellent for deterministic machine control, while MQTT rides on top for fleet-wide visibility. For the controller layer, compare PLCs, industrial PCs, and edge controllers to decide where the MQTT client should live.
Frequently Asked Questions
Is MQTT good for industrial IoT?
Yes. MQTT’s low bandwidth, persistent connections, QoS guarantees, and Last Will messages make it the standard messaging protocol for machine monitoring, predictive maintenance, and factory telemetry. It complements fieldbus protocols like Modbus rather than replacing them.
What is the difference between MQTT and HTTP for IoT?
HTTP is request-response and stateless; clients poll and waste bandwidth. MQTT is publish/subscribe over a persistent connection; the broker pushes data the moment it is published. MQTT packets are also far smaller, which matters for constrained devices.
Does ESP32 support MQTT?
Yes. The Arduino PubSubClient library and the native esp-mqtt component in ESP-IDF both support MQTT, including QoS 0/1 (and QoS 2 via esp-mqtt), TLS, and MQTT 5.0.
Which MQTT broker should I use?
Mosquitto for small deployments and learning, EMQX for high-scale or distributed fleets, and AWS IoT Core, Azure IoT Hub, or HiveMQ Cloud for managed cloud services. For most factory pilots, Mosquitto on a local server or VPS is plenty.
Is MQTT secure?
MQTT itself is a transport protocol; security is your job. Use per-device credentials, TLS (MQTTS on 8883), network segmentation, and never expose a plaintext broker to the internet.
Related Reading
- Predictive Maintenance with Industrial IoT
- PLC vs Industrial PC vs Edge Controller
- ESP32 vs ESP8266: Which IoT Board Should You Choose?
- RS485 and Modbus RTU for Industrial Automation
Sources
- MQTT on ESP32: A Beginner’s Guide — EMQX
- ESP-MQTT Programming Guide — Espressif
- Eclipse Mosquitto MQTT Broker
- HiveMQ MQTT Broker
- ESP32 MQTT Client: Publish and Subscribe with Mosquitto — Zbotic
Disclosure: This post contains affiliate links. As an Amazon Associate and partner of electronics distributors, justlast.in may earn a commission on qualifying purchases at no extra cost to you.
