What MQTT Is
MQTT is a lightweight publish and subscribe messaging protocol designed for low-overhead telemetry between clients and brokers. Its practical value is decoupled data distribution: one gateway can publish operational data once while multiple subscribers consume it without polling the original device directly.
MQTT is common in industrial Internet of Things (IIoT), edge-to-cloud telemetry, supervisory dashboards, and remote monitoring systems where many consumers need the same data stream. It is especially useful when the destination is a broker-centric platform rather than a traditional master polling network.
For field-level diagnostic workflow, use the MQTT Troubleshooting Guide.
See QuickServer for MQTT publishing and protocol conversion options
History
MQTT was designed as a lightweight messaging protocol for constrained or distributed telemetry systems that needed efficient publish-and-subscribe behavior instead of repeated polling. That design made it attractive well beyond its original niche, especially once broker and cloud platforms started using MQTT as a standard ingestion layer.
In practice, the protocol is simple, but production MQTT projects still become engineering-heavy because TLS, identity, and topic-contract requirements live outside the core publish verb.
Core Concepts
MQTT integrations rely on a few core ideas:
- Broker model: MQTT traffic flows through a broker, not directly between field devices and applications.
- Topic hierarchy: topic names and wildcard subscriptions are the protocol’s routing model.
- Publisher and subscriber roles: one client can publish, subscribe, or do both depending on the workflow.
- QoS behavior: delivery level
0,1, or2changes overhead, duplicate-handling expectations, and delivery assurance. - Retained and session state: retained messages, last-will behavior, and persistent sessions affect what a client sees after reconnect.
- Transport and security defaults: MQTT commonly runs over TCP port
1883or over TLS on port8883, with broker-specific authentication layered on top.
Most MQTT failures are edge and security problems, not raw publish mechanics.
MQTT-Specific Information
MQTT defines two main network roles: clients and brokers. A broker receives messages from publishing clients and routes them to any clients that subscribed to matching topics. Clients do not communicate directly with each other, which is what makes MQTT useful when many systems need the same telemetry.
Key Components
| Component | What It Does | Why It Matters |
|---|---|---|
| Broker | Accepts client connections, stores session state, and routes messages by topic | It is the hub of the system and the first place to validate endpoint, auth, and TLS settings |
| Publisher | Sends data to the broker on a specific topic | A publisher only needs to know the broker and topic contract, not the downstream subscribers |
| Subscriber | Registers interest in one or more topics and receives matching messages | Subscribers depend on clean topic hierarchy and payload consistency |
| Topic | Hierarchical subject string used to route messages | Topic design is the protocol’s addressing model, so bad topic design creates long-term integration debt |
| QoS | Delivery guarantee level between client and broker | The wrong QoS level can create either data loss risk or unnecessary overhead |
| Retained message | Last stored value for a topic | New subscribers can receive the current state immediately instead of waiting for the next publish |
Publisher, Subscriber, and Broker Workflow
An MQTT publisher opens a TCP connection to a broker, authenticates if required, and publishes payloads to a topic such as building/chiller-1/supply-temp. The broker then forwards that payload to every subscriber whose topic filter matches. A subscriber does not need to know who published the value, and the publisher does not need to know how many subscribers exist.
That decoupling is the protocol’s core advantage. It lets one telemetry producer serve many consumers without every consumer polling the original field device.
Packet Flow and Delivery Semantics
| Step | Native Protocol Behavior | Why It Matters |
|---|---|---|
| Connect | Client opens a session to the broker and negotiates auth, keepalive, and session behavior | Connection policy often fails before any payload is exchanged |
| Subscribe | Subscriber registers topic filters such as building/+/alarm/# | Wildcards determine how much data the consumer receives |
| Publish | Publisher sends payload, topic, retain flag, and QoS level | A valid connection can still produce unusable data if topic or payload design is wrong |
| Acknowledge | Broker and client exchange acknowledgements for higher QoS levels | Duplicate handling and latency expectations change with QoS |
| Disconnect or failover | Broker may publish a Last Will and Testament if a client drops unexpectedly | Useful for supervisory health monitoring and stale-connection detection |
Topic and Broker Design
| Area | Why It Matters | Common Failure Mode |
|---|---|---|
| Topic hierarchy | Controls how downstream systems subscribe and parse data | Gateway publishes data, but consumers cannot use it cleanly |
| TLS and certificate handling | Determines whether the broker session can even start | Connection fails before the first publish |
| Authentication mode | Changes how the gateway must identify itself | Username/password is assumed where certificates or tokens are required |
| Payload convention | Controls downstream parsing and semantics | Topic path is correct, but the payload contract is wrong |
Delivery and Session Behavior
| Feature | Typical Choices | Why It Matters |
|---|---|---|
| QoS | 0, 1, 2 | Trades delivery assurance against protocol overhead |
| Retained messages | Enabled or disabled per publish | Helps late subscribers receive current state immediately |
| Last Will and Testament | Configured or not configured | Allows the broker to signal unexpected client disconnects |
| Persistent sessions | Clean session or stored session state | Affects how subscriptions and queued messages survive reconnects |
Common Variants
| Variant | Where It Fits | Why It Matters |
|---|---|---|
| MQTT | General broker communication | Common for on-premises and lab workflows |
| MQTT over TLS | Secure broker communication, often on port 8883 | Same protocol, but with transport security and certificate requirements |
| Sparkplug B | Industrial topic and payload conventions | Relevant when SCADA or IIoT consumers expect a stricter contract |
How To Get The Points List
For MQTT, the points list is really a topic and payload design. Point lists usually come from the source-point map and the required topic contract, then get validated against a live broker session.
Preferred sources:
- Topic namespace specification
- Payload schema or Sparkplug B definition
- Source protocol point list mapped to publish topics
- Existing broker sample used only to validate the contract
Common Integration Targets
- BACnet when building-system data needs broker or cloud publishing
- Modbus when meter and controller telemetry needs to be pushed upstream
- SNMP when infrastructure telemetry is aggregated alongside building or controller data
Tools & Diagnostics
| Tool | Type | Description |
|---|---|---|
| QuickServer | Gateway | Use when normalizing field-protocol data into MQTT topics for supervisory, cloud, or multi-consumer workflows |
| FieldServer Toolbox | Gateway diagnostics | Useful for separating source-protocol mapping issues from broker-session issues |
| MQTT Explorer | Client | Useful for topic browsing and retained-message inspection |
| Mosquitto | Broker and CLI | Useful for testing connections and publish and subscribe behavior |
| MQTTX | Client | Useful for cross-platform connection validation |
Devices that Support MQTT
QuickServer is Chipkin’s primary gateway for publishing field-protocol data into MQTT and MQTT-adjacent broker environments.
Representative broker and consumer environments include:
| Environment | Typical Role |
|---|---|
| Mosquitto and HiveMQ brokers | Lab validation, on-premises broker infrastructure, and local supervisory pipelines |
| Ignition and Sparkplug B ecosystems | Industrial telemetry distribution and SCADA-adjacent consumers |
| AWS IoT Core and Azure IoT Hub | Cloud ingestion layers with tighter auth and certificate requirements |
| Teltonika RUT and similar edge gateways | Remote telemetry aggregation and WAN-published field data |
Frequently Asked Questions
Why do MQTT TLS connections fail so often?
Because many failures come from certificate formatting, incomplete CA chains, expired certificates, or broker hostname mismatches rather than from the MQTT message flow itself.
What is the difference between a publisher and a subscriber?
A publisher sends data to a topic on the broker. A subscriber registers interest in one or more topics and receives matching messages from the broker.
Does MQTT require every device to know every other device?
No. Clients only need to know how to reach the broker and which topics to use.
When should MQTT be used instead of polling devices directly?
When multiple consumers need the same telemetry, when the destination is broker or cloud based, or when the gateway should push changes instead of having every consumer poll the source.
What is the first production question on an MQTT project?
Which broker or cloud platform is actually being targeted. That answer usually determines TLS, auth, topic rules, and payload expectations immediately.
Reference Documents
- MQTT.org - Official MQTT project overview and entry point for core protocol material.
- OASIS MQTT Version 5.0 Specification - Authoritative specification for control packets, session behavior, and QoS semantics.
- Eclipse Mosquitto documentation - Practical broker and client documentation useful for testing and diagnostics.
- Wikipedia: MQTT - Useful overview source for protocol history, adoption context, and common terminology.
