Auf dieser Seite
Devices on a cellular link, a weak Wi-Fi signal or a battery do not behave like servers in a rack. They go offline, reconnect and have little memory to spare. MQTT (Message Queuing Telemetry Transport) was designed for that, and the specification still says so in its first paragraph. Here is what it gives you, and where the guarantees stop.
A small protocol that is easy to implement
The MQTT specification describes the protocol as light weight, open, simple and easy to implement, aimed at constrained environments where a small code footprint or scarce bandwidth matters. The concrete part is the packet format. The fixed header of every control packet is a minimum of 2 bytes, and a QoS 0 publish adds only a topic name and its payload to that. Less data on the wire means less radio time, which matters on batteries and metered links.
MQTT runs over TCP/IP or any other transport that gives ordered, lossless, two-way connections. WebSocket is defined for 3.1.1 as well, which is how browsers connect.
Delivery guarantees you choose per message
Every publish carries a Quality of Service (QoS) level, and each client picks one.
| QoS | Name | Packets | Use it when |
|---|---|---|---|
| 0 | At most once | PUBLISH | The next reading replaces this one, such as a temperature sampled every few seconds |
| 1 | At least once | PUBLISH, PUBACK | You cannot lose it and can tolerate a duplicate, such as an alarm |
| 2 | Exactly once | PUBLISH, PUBREC, PUBREL, PUBCOMP | A duplicate would do harm, such as a command that dispenses or charges |
Two details trip people up. First, QoS applies to each hop separately, from publisher to broker and from broker to subscriber. The specification says a message is delivered at the lower of the published QoS and the maximum QoS the subscriber was granted, so a QoS 2 publish reaches a QoS 0 subscriber at most once. Second, QoS says nothing about your application. If a consumer is down for an hour, what it should do with a stale command is still your decision.
Default to the cheapest level your data can tolerate. QoS 1 is the usual middle ground, and your handler should be safe to run twice.
Publish/subscribe with topics
A client publishes to a topic name, and the broker forwards the message to every client whose topic filter matches. Publishers and subscribers never address each other, so you can add a dashboard or a logger without touching the sensor firmware.
Topic design is where most of the long-term pain comes from. Topics are case sensitive and use / to separate levels. In a filter, + matches exactly one level and # matches the parent and all child levels. Topics that start with $ are reserved for the broker, and a filter that begins with + or # does not match them.
A layout that keeps filters simple puts the stable parts first.
site/berlin/line2/press7/temperature
site/berlin/line2/press7/status
site/berlin/line2/+/status all press status topics on line 2
site/berlin/# everything at the Berlin site
Retained messages and last will
Two features make status handling workable on unreliable links. A retained message is stored by the broker and sent to any client that subscribes later to a matching topic, so a new dashboard sees the last known value immediately. Publishing a retained message with an empty payload deletes it.
A last will is a message the client registers when it connects. The broker publishes it if the connection closes without a proper DISCONNECT. In 3.1.1 that happens as soon as the connection is lost. MQTT 5.0 adds a Will Delay Interval, so a brief reconnect does not flip a device to offline.
Combine the two for presence. The device publishes online with retain on connect, and registers an offline retained will. This sketch uses the Mosquitto command line tools and a broker with TLS on port 8883.
echo "terminal 1, watch the status of every press on line 2"
mosquitto_sub -h broker.example.com -p 8883 --cafile ca.pem \
-u dashboard -t 'site/berlin/line2/+/status' -v -q 1
echo "terminal 2, connect with a retained last will, then announce presence"
mosquitto_pub -h broker.example.com -p 8883 --cafile ca.pem \
-u press7 -i press7 -q 1 -r \
--will-topic site/berlin/line2/press7/status --will-payload offline --will-retain \
-t site/berlin/line2/press7/status -m online
Because mosquitto_pub sends one message and disconnects cleanly, the will does not fire in this demo. To see it, publish from a long-running client and kill the process. Adjust the host, credentials and CA file to your broker.
Security is a transport concern
MQTT does not encrypt anything itself. The usual setup is TLS under the protocol, plus a username and password or a client certificate. The 5.0 specification says clients and servers should offer authentication, authorization and secure communication options, and 5.0 adds AUTH packets for multi-step, challenge-based schemes. IANA registers port 1883 for plain MQTT and 8883 for MQTT over TLS. A broker listening on 1883 on the open internet sends credentials and data in the clear.
TLS protects the data in transit between each client and the broker. It does not decide which client may publish or subscribe to which topic. That is the broker's authorization configuration, and it deserves as much attention as the certificates.
Open standard, two versions
MQTT was invented in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper of Arcom. Version 3.1.1 became an OASIS Standard on 29 October 2014 and was also published as ISO/IEC 20922:2016. Version 5.0 became an OASIS Standard on 7 March 2019. An open standard with several independent brokers and client libraries is a large part of why you can mix vendors.
For new projects, 5.0 is worth choosing when your broker and client libraries support it. It adds session and message expiry, reason codes on acknowledgements and shared subscriptions. Check library support before committing, since 3.1.1 remains widely deployed.
How popular is it, really
The best number I could verify is the 2019 Eclipse IoT Developer Survey, with more than 1,700 participants. 42 percent said they use MQTT, roughly three times as many as CoAP. That is a self-selected developer survey from 2019, so read it as a signal and not a market share figure. The MQTT project site lists automotive, manufacturing, telecommunications and oil and gas among the industries that use it.