MQTT is a messaging protocol made for small devices and unreliable networks. If you have looked at Home Assistant, Tasmota, Zigbee2MQTT or any ESP32 project that reports to more than one place, you have probably seen the name. It is simple once the vocabulary clicks.
The idea in one picture
Think of a notice board in a shared hallway. Anyone can pin a note under a heading, such as "Greenhouse temperature". Anyone interested in that heading checks the board and reads the newest note. The person who pinned it does not know who reads it, and the readers do not know who pinned it. The board keeps everyone apart and passes the notes along.
In MQTT terms:
- The broker is the notice board. It is a server that receives every message and delivers it to whoever asked.
- A topic is the heading, written as a path such as
greenhouse/temperature. - Publishing means sending a message to a topic.
- Subscribing means asking the broker to forward you every message on a topic.
- A client is any device or program that connects to the broker. A sensor can be a publisher, a dashboard can be a subscriber, and one program can be both.
Topics and wildcards
Topics are strings separated by slashes, and you choose them. A tidy scheme looks like home/room/measurement, for example home/greenhouse/humidity. Subscribers can use two wildcards:
+stands for exactly one level.home/+/humiditymatches the humidity topic of every room.#stands for everything below that point.home/greenhouse/#matches every measurement in the greenhouse.
Why small devices like it
- The messages are tiny. The smallest MQTT message has a header of just two bytes, which suits slow and metered links.
- The connection stays open. The device connects once and keeps the link alive, so each reading is a short push instead of a fresh handshake.
- Many readers get one message. Publish once, and a dashboard, a logger and an automation rule can all receive it.
- It copes with bad links. The protocol has features for dropped connections, covered below.
Quality of service
Each message is sent with one of three delivery promises.
| Level | Promise | Use it for |
|---|---|---|
| 0 | At most once. Sent and forgotten, so it can be lost. | Frequent readings where the next one replaces a missed one |
| 1 | At least once. Resent until acknowledged, so duplicates are possible. | Most sensor data and alerts |
| 2 | Exactly once. Uses a longer handshake. | Commands where a repeat would cause harm |
Retained messages and last will
Two features solve common sensor problems.
- A retained message is stored by the broker and given to any new subscriber straight away. Without it, a dashboard that starts up has to wait until the next reading to know the temperature. With it, the last value is there at once.
- A last will is a message that a device registers when it connects. If the device disappears without saying goodbye, the broker publishes the will for it. A common use is a topic like
home/greenhouse/statusthat says "online" while the device is there and "offline" when it vanishes.
Ports and security
Plain MQTT usually uses port 1883. MQTT over TLS, the encrypted version, usually uses port 8883. Brokers can also require a username and password. Never expose a broker with no login to the internet. Open brokers are found and abused within hours.
Brokers you can use
- Mosquitto is the small, widely used open source broker. It runs happily on a Raspberry Pi.
- EMQX and HiveMQ are larger brokers, also available as hosted services.
- Home Assistant offers Mosquitto as an add-on that installs in a couple of clicks.
What MQTT does not do
MQTT moves messages. It does not store them. A broker forgets a message once it has been delivered, apart from the single retained one per topic. To keep history, something has to subscribe and write each reading to a database. That is the job of a dashboard or a logging service.
It also needs a broker that is always on and reachable. Ordinary shared web hosting cannot run one, because it only serves web requests. This is why SensorConsole does not accept MQTT directly. If your sensors already speak MQTT, a small script can forward the readings to SensorConsole as web requests. We show a complete one in sending MQTT sensor data to an online dashboard.