When a temperature sensor needs to report its value, the most intuitive approach would be to send it straight to whoever uses it: the hub, the app, the thermostat. With dozens of devices this web of direct links becomes unmanageable. MQTT solves the problem with a simple idea: everyone talks to a single intermediary, the broker, which routes messages to whoever asked for them.
The publish/subscribe model
MQTT has two roles, and the same device can hold both at once.
- A publisher sends a message on a given subject, the topic.
- A subscriber to that topic receives every message published on it.
The publisher does not know who will receive the message, and the subscriber does not know who sent it. The broker acts as the switchboard. This decoupling is why MQTT fits IoT so well: adding a new listening device does not require changing the existing ones.
Topics
A topic is a hierarchical string separated by slashes, similar to a folder path:
home/livingroom/temperature
home/livingroom/humidity
home/kitchen/light/state
home/kitchen/light/command
To subscribe to several topics at once there are two wildcards:
+replaces a single level:home/+/temperaturereceives the temperature of every room;#replaces all following levels:home/kitchen/#receives everything about the kitchen.
A good topic structure, decided at the start, keeps the system readable years later. It is wise to separate state topics, where the device reports its condition, from command topics, where it receives orders.
Quality of service levels (QoS)
MQTT lets you choose how strongly each message's delivery is guaranteed.
| QoS | Guarantee | Typical use |
|---|---|---|
| 0 | at most once, no acknowledgement | frequent sensor readings |
| 1 | at least once, duplicates possible | commands and notifications |
| 2 | exactly once | cases where a duplicate causes trouble |
For a sensor sending the temperature every minute, losing a reading is not serious: QoS 0 is enough. For the command that closes a water valve, at least QoS 1 is advisable. QoS 2 is heavier and rarely needed at home.
Retained messages and last will
Two features make MQTT especially practical.
- Retained: the broker keeps the last message on a topic and delivers it immediately to anyone who subscribes later. An app that opens knows the light's state at once, without waiting for the next update.
- Last Will and Testament: when connecting, the device gives the broker a message to publish if it disconnects abnormally. Typically "offline" is published on an availability topic, so the hub knows the device is not responding.
A broker at home
The most widely used broker for home use is Mosquitto, lightweight and open source. It runs comfortably on a Raspberry Pi or a mini PC, often next to the home automation hub. Many devices with alternative firmware, ESP32 boards and tools such as Zigbee2MQTT use it as their exchange point.
To check that everything works, two command-line client commands in two separate windows are enough:
mosquitto_sub -h 192.168.1.10 -t 'home/#' -v
mosquitto_pub -h 192.168.1.10 -t 'home/test' -m 'hello'
If the message appears in the first window, broker and network are fine.
Security: the minimum settings
A badly configured broker lets anyone on the network read all the data and send commands. The basic rules are few:
- mandatory authentication with username and password, disabling anonymous access;
- separate users for different devices, with permissions limited to the topics they need;
- TLS encryption, especially if traffic leaves the local network: the standard unencrypted port is 1883, the TLS one is 8883;
- no direct exposure to the internet: for outside access, going through a VPN is better.
When you do not need MQTT
With a few devices from the same ecosystem, or with Matter devices, the hub already handles communication and MQTT only adds complexity. It becomes useful when you build your own devices, integrate different brands or want separate systems to talk to each other.
In short
- MQTT uses a central broker and the publish/subscribe model to let devices communicate.
- Topics are hierarchical; the
+and#wildcards allow multiple subscriptions. - The QoS level should match how important the message is.
- Retained messages and Last Will provide instant state and disconnection detection.
- Authentication, per-topic permissions and no internet exposure are the bare minimum.
