Documentation Index
Fetch the complete documentation index at: https://mintlify.com/hivemq/hivemq-community-edition/llms.txt
Use this file to discover all available pages before exploring further.
Overview
MQTT 3.1.1 is the most widely adopted version of the MQTT protocol, standardized by OASIS in 2014. HiveMQ CE provides full support for both MQTT 3.1 and 3.1.1, ensuring compatibility with the vast majority of MQTT clients and devices.MQTT 3.1.1 refined and clarified the MQTT 3.1 specification without introducing breaking changes. HiveMQ CE supports both versions seamlessly.
Core Protocol Features
Quality of Service (QoS)
MQTT 3.1.1 defines three QoS levels for message delivery:| QoS Level | Name | Guarantee | Use Case |
|---|---|---|---|
| 0 | At most once | No guarantee | Sensor data where loss is acceptable |
| 1 | At least once | Guaranteed delivery, duplicates possible | Important messages where duplicates can be handled |
| 2 | Exactly once | Guaranteed once, no duplicates | Critical commands, financial transactions |
Retained Messages
Retained messages are stored by the broker and delivered to new subscribers immediately upon subscription.- Last known device status
- Configuration values
- System state information
Persistent Sessions (Clean Session = False)
Whenclean_session is set to False, the broker maintains:
- The client’s subscriptions
- QoS 1 and QoS 2 messages not yet acknowledged
- New QoS 1 and QoS 2 messages while disconnected
HiveMQ CE stores queued messages in persistent storage (RocksDB) to survive broker restarts.
Last Will and Testament (LWT)
LWT allows clients to specify a message that the broker will publish if the client disconnects ungracefully.- Device status monitoring
- Detecting unexpected disconnections
- Alerting systems
MQTT 3.1.1 Packet Types
| Packet Type | Direction | Description |
|---|---|---|
| CONNECT | Client → Broker | Initial connection request |
| CONNACK | Broker → Client | Connection acknowledgment |
| PUBLISH | Bidirectional | Publish a message |
| PUBACK | Bidirectional | QoS 1 acknowledgment |
| PUBREC | Bidirectional | QoS 2 received (part 1) |
| PUBREL | Bidirectional | QoS 2 release (part 2) |
| PUBCOMP | Bidirectional | QoS 2 complete (part 3) |
| SUBSCRIBE | Client → Broker | Subscribe to topics |
| SUBACK | Broker → Client | Subscribe acknowledgment |
| UNSUBSCRIBE | Client → Broker | Unsubscribe from topics |
| UNSUBACK | Broker → Client | Unsubscribe acknowledgment |
| PINGREQ | Client → Broker | Keep-alive ping |
| PINGRESP | Broker → Client | Keep-alive response |
| DISCONNECT | Client → Broker | Graceful disconnection |
Topic Structure
Topic Naming
- Use UTF-8 encoded strings
- Maximum length: 65535 bytes (configurable in HiveMQ CE)
- Hierarchical structure using
/as delimiter - Case-sensitive
Topic Wildcards
Single-level Wildcard (+)
Matches exactly one topic level:Multi-level Wildcard (#)
Matches one or more topic levels (must be last character):Connection Parameters
Client Identifier
- Unique identifier for the client
- 1-23 characters in MQTT 3.1
- 1-65535 characters in MQTT 3.1.1
- Can be empty in MQTT 3.1.1 (broker assigns ID)
Keep-Alive
- Maximum time interval between messages
- Default: 60 seconds
- Range: 0-65535 seconds
- 0 = keep-alive disabled
Authentication
MQTT 3.1.1 supports username/password authentication:Use TLS/SSL encryption to protect credentials in transit. See TLS Transport guide.
MQTT 3.1.1 Limitations
Compared to MQTT 5, version 3.1.1 lacks:- ❌ Reason codes (only basic error indicators)
- ❌ User properties (custom metadata)
- ❌ Request/response pattern
- ❌ Topic aliases
- ❌ Shared subscriptions (HiveMQ extension available)
- ❌ Subscription options
- ❌ Message expiry
- ❌ Server-sent DISCONNECT
Complete Connection Example
Next Steps
MQTT 5
Explore MQTT 5.0 enhanced features
Quality of Service
Deep dive into QoS levels
Connecting Clients
Client connection examples
Transport Protocols
Configure TCP and TLS transports