Industrial IoT with MQTT: The Complete IIoT Guide

Industrial IoT MQTT is how modern plants move data from PLCs, sensors and machines to the systems that act on it, without the brittle point-to-point integrations of the past. This guide explains why MQTT became the IIoT backbone, how an edge-to-cloud architecture is put together, where Sparkplug B and ISA-95 topic namespaces fit, and how to build a first machine-to-broker data flow with runnable code. By the end you will have a reference architecture and a checklist you can take to your next project meeting.

Why MQTT Became the Industrial IoT Backbone

Classic automation follows the layered Purdue model: sensors talk to PLCs, PLCs to SCADA, SCADA to a historian, and the MES and ERP sit on top. Each layer integrates with the next through point-to-point connections, often with proprietary protocols. Adding one new consumer of machine data, such as a quality dashboard or a predictive maintenance model, means touching several of those links.

MQTT breaks that pattern with publish/subscribe. Each data source publishes once to a central broker, and any number of consumers subscribe to exactly what they need. If you are new to that model, what an MQTT broker does covers the fundamentals. For industrial use, several MQTT properties matter in particular:

• Outbound-only connections. Edge devices open connections to the broker; nothing needs to reach into the plant network. That fits OT security policies far better than polling protocols that require inbound access.
• Report by exception. Devices publish when a value changes rather than being polled on a fixed cycle, which cuts bandwidth dramatically on slow or metered links. See report by exception.
• State awareness. Last Will and Testament messages, retained values and keep-alives tell every consumer whether a machine is online and what its last known state was.
• Light footprint. MQTT clients run on PLCs, gateways and even microcontrollers, and work over cellular links.
• Open standard. MQTT is an OASIS standard with clients in every language, so you are not tied to one vendor's stack.

This does not make OPC UA or fieldbus protocols obsolete. OPC UA remains excellent for rich information models and machine-level access, which is why most IIoT architectures combine the two; we compare them in OPC UA vs MQTT.

Industrial IoT MQTT Reference Architecture

A practical IIoT architecture has four layers. Each one has a clear job, and the broker sits at the center.

The IIoT architecture article goes deeper on each layer. Here are the decisions that matter most.

The Edge Gateway

Most installed machines do not speak MQTT. An IIoT edge gateway reads them with their native protocol and publishes to the broker. It should poll fast locally but publish only on change, add timestamps and units, and buffer messages when the uplink fails. That last job is called store and forward, and it is what keeps a network outage from becoming a data gap. For specific protocols, see Modbus TCP to MQTT, the OPC UA to MQTT gateway guide and PLC to cloud.

Network Placement

Plants usually separate OT and IT networks, with a DMZ between them. The common patterns are a broker in the DMZ that OT gateways publish to, a broker in the cloud reached through an outbound firewall rule, or both bridged together. Each has trade-offs for latency, autonomy and security; MQTT in the industrial DMZ walks through them.

Where the Broker Runs

On-premises brokers keep running when the internet does not, which matters for anything inside a control loop. Cloud brokers make multi-site aggregation, remote access and dashboards much simpler. Many plants do both: local logic stays local, and a cloud MQTT broker aggregates sites for analytics and enterprise systems. Whatever you choose, industrial requirements on uptime, isolation and security are higher than for consumer IoT, which we cover in choosing an industrial MQTT broker.

Topic Design: ISA-95 and the Unified Namespace

Plain MQTT says nothing about topic structure, and that freedom is dangerous at plant scale. Without a convention, you end up with machine7/temp, Line-2/Temp_C and plant/oven/temperature in the same broker, and nobody can subscribe to "everything on line 2."

The industrial answer is to align topics with the ISA-95 equipment hierarchy:

enterprise/site/area/line/cell/measurement
acme/izmir/machining/line1/cnc1/spindle_temp

A broker organized this way becomes a Unified Namespace (UNS): one place where the current state of the whole business is published in a structure everyone understands. MES subscribes to acme/izmir/#, a line dashboard to acme/izmir/machining/line1/#, and a maintenance model to acme/+/+/+/+/vibration. Adding a consumer never requires touching a producer.

Rules that hold up in real plants:

1. Agree on level names and allowed characters before the first device connects.
2. Use lowercase, no spaces and stable identifiers (asset IDs, not operator nicknames).
3. Separate telemetry, state, events and commands into distinct leaf topics.
4. Put engineering units and timestamps in the payload, not the topic.
5. Publish current state as retained messages so new consumers get it instantly.

The detailed guidance lives in ISA-95 MQTT topics, UNS topic structure and the step-by-step how to build a Unified Namespace.

Sparkplug B: Adding State and Structure to MQTT

Sparkplug B is an Eclipse Foundation specification that defines how industrial devices should use MQTT. It fixes three things plain MQTT leaves open:

• A topic namespace: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}.
• A payload format: Protobuf-encoded metrics with names, data types, timestamps and aliases.
• State management: birth (NBIRTH, DBIRTH) and death (NDEATH, DDEATH) certificates, so every consumer knows which edge nodes and devices are online and which metrics they publish.

The benefits are interoperability between Sparkplug-aware products and reliable state. The cost is that Protobuf payloads are not human-readable, and the fixed topic layout does not reflect your plant hierarchy. Start with the Sparkplug B payload and Sparkplug birth and death certificates explainers, and use decoding Sparkplug B in Python when you need to inspect raw traffic.

Sparkplug B and ISA-95 Together

Many plants run both: Sparkplug B at the edge for state-aware, efficient communication, and an ISA-95 JSON namespace for everyone else. The tricky part is the translation layer between them. Our article on Sparkplug B and the Unified Namespace compares the two approaches in detail, and the next section shows how a broker can do the translation for you.

Hands-On: Your First Industrial IoT MQTT Data Flow

You can try industrial topic patterns right now on the free public MQTT broker at broker.connectmq.com. Use a unique prefix, keep topics within 8 levels, and remember that the public area is readable by anyone, so use simulated data only.

Subscribe to the whole simulated plant:

mosquitto_sub -h broker.connectmq.com -p 1883 -i iiot-sub-m5q2 \
  -t "connectmq/demo/m5q2/#" -v

Publish an ISA-95 style reading and a retained machine state:

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/telemetry" \
  -m '{"spindle_temp":61.4,"spindle_rpm":8200,"unit_temp":"C","ts":1760600000}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 -r \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/state" -m "RUNNING"

A Minimal Modbus TCP to MQTT Edge Bridge

The script below plays the role of an edge gateway. It polls two holding registers from a Modbus TCP device every second, publishes only when a value changes by more than a deadband, and registers a Last Will so consumers know when the gateway disappears. It uses pymodbus 3.x and paho-mqtt 2.x:

pip install "pymodbus>=3.6" "paho-mqtt>=2.0"

import json
import time

import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient

PLC_HOST = "192.168.1.50"      # your Modbus TCP device or simulator
BASE = "connectmq/demo/m5q2/machining/line1/press1"
DEADBAND = 0.5                 # publish only if a value moves this much

def on_connect(client, userdata, flags, reason_code, properties):
    print("Broker connection:", reason_code)
    client.publish(f"{BASE}/state", "ONLINE", qos=1, retain=True)

mqttc = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="edge-press1-m5q2",
    protocol=mqtt.MQTTv5,
)
mqttc.will_set(f"{BASE}/state", "OFFLINE", qos=1, retain=True)
mqttc.on_connect = on_connect
mqttc.reconnect_delay_set(min_delay=1, max_delay=30)
mqttc.connect("broker.connectmq.com", 1883, keepalive=30)
mqttc.loop_start()

plc = ModbusTcpClient(PLC_HOST, port=502)
last = {}

while True:
    if not plc.connected:
        plc.connect()
    rr = plc.read_holding_registers(address=0, count=2)
    if rr.isError():
        print("Modbus read failed:", rr)
        time.sleep(2)
        continue

    values = {
        "pressure_bar": rr.registers[0] / 10.0,  # scaled x10 in the PLC
        "temperature_c": rr.registers[1] / 10.0,
    }
    changed = {k: v for k, v in values.items()
               if k not in last or abs(v - last[k]) >= DEADBAND}
    if changed:
        changed["ts"] = int(time.time() * 1000)
        mqttc.publish(f"{BASE}/telemetry", json.dumps(changed), qos=1)
        last.update({k: v for k, v in changed.items() if k != "ts"})
    time.sleep(1)

Watch your subscriber terminal: values appear only when they move, and OFFLINE arrives if you kill the script. Register scaling, word order and addressing differ between PLC vendors, so check the device's register map; our Modbus-to-MQTT bridging guide covers those details. A production gateway would also buffer to disk during outages and use TLS with credentials.

How ConnectMQ Supports Industrial IoT MQTT

ConnectMQ is a managed MQTT broker with features aimed specifically at industrial traffic:

• ISA-95 and UNS detection. The broker recognizes ISA-95 and Unified Namespace topic structures in your traffic.
• Sparkplug B decoding. Sparkplug B payloads are decoded (Protobuf or JSON) so you can read them in the portal instead of staring at bytes.
• Sparkplug to ISA-95 republishing. Sparkplug B data can be republished into ISA-95 topics with readable payloads, for example spBv1.0/factory1/DDATA/line1/cnc1 becomes connectmq/factory1/production/line1/cnc1/telemetry. Edge nodes keep speaking Sparkplug while MES and dashboards consume a clean namespace.
• ISA-95 devices view and alerts. The portal shows devices organized by ISA-95 levels, and threshold alert rules with an alerts log flag values such as a spindle temperature crossing a limit.
• Deployment choice. Start on the free Serverless plan, then move to a Dedicated isolated cluster, BYOC inside your own cloud account, or Self Managed Enterprise for sites that must stay on premises.

To see what this looks like end to end, the ConnectMQ 3D digital twin web demo shows a factory with a CNC, robot arm, furnace, tank, conveyor and pump updating live over Secure WebSocket. Storage and analytics are handled the open way: historians, Telegraf, Node-RED or your own services subscribe to the broker as standard MQTT clients. See building an MQTT historian for that pattern.

Industrial IoT MQTT Project Checklist

Use this list when scoping a first deployment. The complete version is in our IIoT connectivity checklist.

1. Inventory machines, protocols and the data points that actually answer a business question.
2. Agree on an ISA-95 topic hierarchy and naming rules with both OT and IT.
3. Decide on payload format: Sparkplug B at the edge, JSON for consumers, or both.
4. Choose gateway hardware and confirm it supports buffering and TLS.
5. Decide where the broker runs and how traffic crosses the OT/IT boundary.
6. Issue unique credentials per gateway and enforce TLS on 8883.
7. Define state handling: Last Will, retained state topics, birth and death messages.
8. Plan storage and visualization with subscriber tools, not broker-side magic.
9. Run a pilot on one line, measure, then scale.

Organizational alignment matters as much as technology here; IT/OT convergence covers how teams split responsibilities. For the bigger picture of where this connectivity layer fits in a digital transformation program, read our Industry 4.0 guide.

Build Your Industrial IoT Pilot on ConnectMQ

Try the examples above on broker.connectmq.com, then create a private broker at app.connectmq.com. The Serverless free plan needs no credit card and is enough for a single-line pilot with a few gateways, dashboards and the Sparkplug B decoding and ISA-95 views described above.

Frequently Asked Questions

Is MQTT suitable for industrial automation?

Yes, for moving data between machines, edge gateways and applications. Hard real-time control loops still belong on fieldbuses and PLCs; MQTT carries the data around them to SCADA, MES, historians and analytics.

Do I need Sparkplug B for industrial IoT MQTT?

No, but it helps when many vendors' products must interoperate and you need reliable online/offline state. Many plants use Sparkplug B at the edge and an ISA-95 JSON namespace for consumers.

Should the industrial MQTT broker run on premises or in the cloud?

Anything inside a control loop should not depend on an internet link, so local brokers are common in plants. A cloud broker is better for multi-site aggregation, remote dashboards and enterprise integration, and many architectures use both.

How do I connect a PLC that does not support MQTT?

Use an edge gateway that reads the PLC over its native protocol, such as Modbus, OPC UA, S7 or EtherNet/IP, and publishes to the broker. Many newer PLCs also have built-in MQTT clients.

Can ConnectMQ read Sparkplug B messages?

Yes. ConnectMQ decodes Sparkplug B payloads and can republish them into ISA-95 topics with readable payloads, so non-Sparkplug consumers can use the data directly.