MQTT

MQTT is a lightweight messaging standard that carries data between machines and devices. It is not request and response: a publisher sends to a topic and does not know who reads it, while a subscriber reads without knowing who sent it. That decoupling is the point, because a new consumer can be added without touching the sender.

The specification describes the protocol as deliberately small and simple. Message headers are short, so it fits constrained environments where memory is limited and bandwidth is expensive. It runs over TCP/IP, or any other network that provides ordered, lossless and bi-directional connections, and it is agnostic to the content of the payload.

The broker and the clients

The broker sits in the middle. Clients connect to it, and the broker does the heavy work: it accepts publications, checks permissions, queues messages according to their quality of service level, and routes them to authorised subscribers. Addressing uses topics, and a subscription may be a pattern, so one message can reach many readers at once.

In practice the broker is often Eclipse Mosquitto: open source, it implements MQTT 5.0, 3.1.1 and 3.1, and it ships a C library together with the mosquitto_pub and mosquitto_sub command line clients. It is small enough for a single board computer and still fine on a server.

Quality of service and message behaviour

The protocol defines three levels of delivery, and they are a trade between reliability and cost:

• 0 - at most once: messages go on a best effort basis and can be lost. For sensor readings this is often enough, because the next value arrives soon.
• 1 - at least once: messages arrive, but duplicates can occur.
• 2 - exactly once: messages arrive exactly once, the level to use where a duplicate would cause a wrong decision.

The standard also has the tools real deployments need. A retained message stays on the topic, so a reader that connects later learns the last state at once. The will message is stored by the broker and published when a client disconnects abnormally, so a dead device does not vanish silently. Clean start decides whether a connection resumes the previous session or begins a new one, and long lived sessions matter on mobile networks because they shorten the time it takes to reconnect.

Security

The protocol does not encrypt by itself, but it supports doing so: messages can be protected with TLS, and clients can be authenticated with modern mechanisms such as OAuth. On the broker side this means accounts and access rules, because authorisation has to be decided at the topic level. That is what keeps a sensor in one system from reading the messages of another.

Where it fits with us

MQTT is the language of our devices. Home Assistant reaches devices on this bus when they have no integration of their own, the broker runs in a Docker container, and the server side is Linux.

MQTT works well when messages are small and frequent and the devices sit on unreliable networks. When something has to be recorded or queried as a transaction, it is the wrong layer.

Further reading

• MQTT: The Standard for IoT Messaging - what the standard is for, and the publish and subscribe model.
• MQTT Version 5.0, OASIS Standard - the official specification, published 07 March 2019.
• Eclipse Mosquitto - the broker, the command line clients and the downloads.

For CyberElectro MQTT is the layer that connects physical devices and control logic to our systems, precisely because it stays predictable with small messages.