MQTT explained: brokers, topics, QoS and retained messages
In short: MQTT is a lightweight publish/subscribe protocol in which devices send messages to a broker under named topics and other clients subscribe to the topics they care about. QoS levels, retained messages and the last will feature make it reliable on poor networks. It is simple, but it must be secured with authentication, TLS and topic permissions.
Why publish/subscribe suits IoT
MQTT (originally MQ Telemetry Transport) is a messaging protocol designed for small devices on unreliable links. It runs over TCP, normally on port 1883, or port 8883 when wrapped in Transport Layer Security (TLS). The current versions are 3.1.1 and 5.0, both OASIS standards.
Instead of a device talking directly to the system that needs its data, every client connects to a central server called the broker. A client publishes a message to a topic, and the broker forwards it to every client that has subscribed to that topic. Publishers and subscribers do not need to know each other's addresses, or even be online at the same time.
This decoupling is the main attraction. You can add a new dashboard, database or alerting service just by subscribing, without touching the sensors. The connection is opened by the device outwards to the broker, so devices behind Network Address Translation (NAT) work without port forwarding. Popular brokers include Eclipse Mosquitto, EMQX, HiveMQ and VerneMQ, and the large cloud IoT platforms offer MQTT endpoints too.
Topics and wildcards
A topic is a UTF-8 string split into levels by forward slashes, for example site1/lab/rack3/temperature. Topics are created on the fly; there is nothing to register. Subscribers can use two wildcards:
+matches exactly one level:site1/+/rack3/temperaturematches any room.#matches all remaining levels and must come last:site1/lab/#matches everything in the lab.
Good topic design pays off later. Put the general part first and the specific part last, keep a consistent pattern such as <site>/<area>/<device-id>/<measurement>, avoid spaces and leading slashes, and keep commands on separate topics from telemetry (for example .../cmd/relay) so you can grant permissions precisely. Topics beginning with $, such as $SYS/, are reserved for broker information.
mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt -u dash -P '<password>' -t 'site1/lab/#' -v
mosquitto_pub -h broker.example.com -p 8883 --cafile ca.crt -u sensor01 -P '<password>' -t 'site1/lab/sensor01/temperature' -m '21.4' -q 1Quality of service, retained messages and last will
Each publish and subscription carries a quality of service (QoS) level. The broker delivers at the lower of the publisher's and the subscriber's QoS. Use QoS 0 for frequent readings where losing one does not matter, QoS 1 for most events and alerts (make the receiver tolerate duplicates), and QoS 2 only when a duplicate would cause harm, such as a billing count.
| Feature | What it does | Typical use |
|---|---|---|
| Retained message | Broker keeps the last message on a topic and sends it to new subscribers at once | Current state: "door closed", last temperature |
| Last will and testament (LWT) | Message the broker publishes if a client disconnects without saying goodbye | Mark a device offline |
| Keep alive | Client pings within an agreed interval so dead links are detected | Battery and cellular devices |
| Persistent session | Broker remembers subscriptions and queues QoS 1/2 messages while a client is away | Devices that sleep |
MQTT 5 adds useful features: reason codes on every acknowledgement, message and session expiry, user properties (key/value metadata), shared subscriptions for load balancing ($share/group/topic), topic aliases to save bytes, and request/response helpers. If your broker and libraries support version 5, prefer it for new projects.
Security and common mistakes
MQTT itself provides only a username and password field. Everything else comes from the broker configuration. Brokers left open on the internet with anonymous access are regularly found by scanners, exposing data and sometimes allowing anyone to publish commands.
- Turn off anonymous access and give every device its own credentials or, better, its own client certificate.
- Use TLS on 8883 so passwords and data are not sent in clear text.
- Apply access control lists (ACLs): a sensor may publish only to its own topics, and only the controller may publish to
cmdtopics. - Validate payloads on the subscriber side; a broker forwards whatever it receives.
- Do not subscribe to
#in production apps; it wastes bandwidth and hides permission mistakes.
Tip: in exams, remember three numbers: port 1883 (plain), port 8883 (TLS) and QoS 0, 1 and 2. At work, the most valuable habit is writing the topic plan and the ACL file together, before any device is flashed.
Practice
A subscriber uses QoS 0 and the publisher uses QoS 2. Which QoS is used for delivery to that subscriber?
Which wildcard would match home/kitchen/temp and home/garage/temp but not home/garage/fridge/temp?
How can a dashboard show that a device has lost power?
Key takeaways
- MQTT is publish/subscribe: clients talk only to a broker, using topics.
- Wildcards: + matches one level, # matches all remaining levels.
- QoS 0, 1 and 2 trade overhead for delivery guarantees.
- Retained messages, last will and persistent sessions handle state and sleepy devices.
- Secure it with unique credentials, TLS on port 8883 and per-topic ACLs.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.