MQTT Explained: Broker, Topics, QoS, Retained Messages and Last Will
MQTT is a lightweight messaging protocol commonly used by connected devices. It lets a sensor, microcontroller, server and dashboard exchange data without each device knowing the network address of every other participant.
Instead of repeatedly asking whether data has changed, MQTT uses publish/subscribe. A publisher sends a message to a broker under a topic name. The broker routes it to clients with matching subscriptions. Think of it as a message exchange with named channels and a central router.
The four core concepts
Broker: the server that accepts client connections and routes publications. Eclipse Mosquitto is a common open-source broker.
Publisher: any client that sends a message to a topic. An ESP32 might publish temperature readings.
Subscriber: any client that requests messages matching a topic filter. Node-RED might subscribe to temperature data to update a dashboard.
Topic: a hierarchical name such as home/kitchen/temperature. A slash divides levels. Choose a hierarchy that remains understandable as devices are added.
A single device can publish and subscribe at the same time—for example, an ESP32 publishes sensor data and subscribes to a command topic.
Topic wildcards
A subscriber can use wildcards in a subscription filter. The single-level wildcard + matches exactly one topic level. The multi-level wildcard # matches the remaining hierarchy and is used at the end of a filter.
| Filter | Example match | Meaning |
|---|---|---|
| home/+/temperature | home/kitchen/temperature | One room level |
| home/# | home/kitchen/temperature | Descendants under home |
| home/kitchen/+ | home/kitchen/humidity | One leaf under kitchen |
A wildcard subscription can receive more messages than expected. Keep topic design and access controls intentional, especially when topics carry actuator commands or private data.
Quality of Service (QoS)
| QoS | Basic guarantee | Design consideration |
|---|---|---|
| 0 | At most once | Low overhead; delivery can be lost |
| 1 | At least once | A message may be delivered more than once |
| 2 | Exactly once at MQTT protocol exchange level | More overhead; not a guarantee that a physical action happens exactly once |
QoS is not application correctness. If a controller sends an actuator command and restarts before recording success, it may still need an acknowledgement, sequence number or idempotent state operation. Choose the lowest level that meets delivery needs rather than using QoS 2 for everything.
Retained messages: current value, not a full history
When a publisher sends a retained message, the broker stores the latest retained publication for that topic. A new subscriber can receive that value immediately, even if the original publication happened earlier. This can be useful for current state, such as online/offline or the latest temperature.
Retained messages do not form a complete event history; the retained value is replaced by a later retained publication. Do not retain one-shot commands such as TOGGLE, UNLOCK or PULSE unless replaying the action is explicitly intended. A reconnecting device may receive an old command and repeat an action at an unexpected time.
Last Will and Testament (LWT)
A client can register a Last Will when it connects. If the broker detects an unexpected disconnect, it publishes the configured message on behalf of that client. A common use is availability: retained offline as the will, followed by retained online when the client connects successfully.
LWT is not an instantaneous hardware detector. Publication timing depends on connection-loss detection and MQTT keep-alive/session behavior. For a robust dashboard, combine availability with a timestamp of the last valid sensor reading and make the stale-data threshold clear.
MQTT does not automatically make a system secure
A broker may run without appropriate authentication or authorization if the operator has not configured it. For a lab, keep access on a trusted network. For devices communicating across untrusted networks, configure explicit listener scope, credentials, topic permissions and TLS or a suitable secure network path. Do not expose an anonymous broker directly to the internet.
Topic names are not access controls. A secret-looking topic is not a replacement for authentication or ACLs. Give each client only the read/write permissions required for its role.
Continue learning on SolderHub
- Install Mosquitto on Raspberry Pi 5
- Test MQTT without Hardware
- ESP32 MQTT Tutorial: Publish and Subscribe with Arduino IDE
- Node-RED with MQTT: Connect Mosquitto, Publish & Subscribe
- MQTT Troubleshooting: Connection Refused, rc=-2 and rc=5
Official references: Mosquitto documentation and the configuration manual.