MQTT Reference
Free reference guide: MQTT Reference
About MQTT Reference
This MQTT Protocol Reference is a searchable guide covering the complete MQTT messaging lifecycle, including CONNECT/CONNACK handshake, Keep Alive PING mechanism, Will Message configuration for unexpected disconnections, and DISCONNECT packet handling with Python Paho client examples.
The reference provides detailed coverage of MQTT publish/subscribe patterns, including QoS 0 (at most once), QoS 1 (at least once with PUBACK), QoS 2 (exactly once with 4-step handshake), retain flag behavior, and QoS downgrade rules when publisher and subscriber levels differ.
It also covers topic design patterns with single-level (+) and multi-level (#) wildcards, $SYS system topics for broker monitoring, TLS/SSL encrypted connections on port 8883, username/password authentication, ACL access control lists, and WebSocket transport for browser-based MQTT clients.
Key Features
- CONNECT, CONNACK, and DISCONNECT packet handling with Python Paho MQTT client code
- Keep Alive mechanism with PINGREQ/PINGRESP and configurable interval
- Will Message (Last Will and Testament) setup for detecting unexpected client disconnections
- QoS 0, QoS 1, and QoS 2 delivery guarantees with protocol flow explanations
- Retain flag behavior for persisting the last message on a topic at the broker
- Topic wildcard patterns: single-level (+) and multi-level (#) with practical examples
- TLS/SSL encrypted connections, username/password authentication, and ACL configuration
- WebSocket transport support for browser-based MQTT communication on port 9001
Frequently Asked Questions
What are the three QoS levels in MQTT?
QoS 0 (At most once) sends the message without any delivery confirmation, making it the fastest but least reliable. QoS 1 (At least once) uses a PUBACK acknowledgment to ensure delivery but may result in duplicates. QoS 2 (Exactly once) uses a 4-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) to guarantee the message is delivered exactly once, ideal for payment or order processing.
How do MQTT topic wildcards work?
The single-level wildcard (+) matches exactly one topic level. For example, sensor/+/temperature matches sensor/room1/temperature and sensor/room2/temperature. The multi-level wildcard (#) matches all remaining levels and must be the last character. For example, sensor/# matches sensor/temp, sensor/room1/temp, and sensor/room1/floor2/temp.
What is an MQTT Will Message?
A Will Message (Last Will and Testament) is configured during the CONNECT phase. If the client disconnects unexpectedly (network failure, crash) without sending a DISCONNECT packet, the broker automatically publishes this pre-configured message to the specified topic. This is commonly used to broadcast an "offline" status to other subscribers.
How do I secure an MQTT connection with TLS?
Use TLS/SSL on port 8883 by configuring the client with CA certificate, client certificate, and client key using client.tls_set(ca_certs, certfile, keyfile). Additionally, you can set username/password authentication with client.username_pw_set() and configure ACL files on the broker to control read/write permissions per topic per user.
What is the MQTT retain flag?
When a message is published with the retain flag set to True, the broker stores the last retained message for that topic. Any new subscriber to that topic immediately receives the retained message upon subscribing, rather than waiting for the next publish event. This is useful for status indicators like device online/offline state.
What happens when publisher and subscriber use different QoS levels?
MQTT brokers downgrade the QoS to the lower of the two levels. If a publisher sends at QoS 2 but a subscriber subscribed at QoS 1, the subscriber receives the message at QoS 1. The effective QoS is always the minimum of the publish QoS and the subscribe QoS.
What are $SYS topics in MQTT?
$SYS topics are special system topics published by the MQTT broker that provide operational metrics. Examples include $SYS/broker/clients/connected (number of connected clients) and $SYS/broker/messages/received (total messages received). These topics are read-only and useful for broker monitoring and diagnostics.
Can MQTT work in web browsers?
Yes, MQTT supports WebSocket transport, allowing browser-based JavaScript clients to connect to the broker. Configure the client with transport="websockets" and connect on port 9001 (or the broker-configured WebSocket port). This enables real-time IoT dashboards and web applications to communicate via MQTT without plugins.