MQTT 5.0 features
MQTT 5.0 keeps the packet structure of 3.1.1 and adds properties and reason codes. The protocol level in CONNECT is 5 for MQTT 5.0 and 4 for 3.1.1. The PDComm simulator always connects with MQTT 5.0.
Properties
Section titled “Properties”A property is an optional item in the variable header of a packet (§2.2.2). Each one has an identifier, a type and a value, and carries information that 3.1.1 had no place for. These are the properties you meet most often:
| Property | Packets | Purpose |
|---|---|---|
| Session Expiry Interval | CONNECT, CONNACK, DISCONNECT | How long the session is kept |
| Receive Maximum | CONNECT, CONNACK | How many QoS 1 and 2 messages can await acknowledgement at once |
| Maximum Packet Size | CONNECT, CONNACK | The largest packet the peer accepts |
| Topic Alias Maximum | CONNECT, CONNACK | How many topic aliases the peer accepts |
| Maximum QoS | CONNACK | The highest QoS the broker accepts |
| Retain Available | CONNACK | Whether the broker supports retained messages |
| Server Keep Alive | CONNACK | The keep alive the broker imposes |
| Payload Format Indicator | PUBLISH | 0 for bytes, 1 for a UTF-8 string |
| Message Expiry Interval | PUBLISH | Seconds after which an undelivered message is discarded |
| Content Type | PUBLISH | A string that names the payload format, such as a MIME type |
| Response Topic, Correlation Data | PUBLISH | Pair a request with its response |
| User Property | Most packets | Name/value pairs defined by the application |
| Reason String | Response packets | A human-readable diagnostic |
Reason codes
Section titled “Reason codes”MQTT 5.0 response packets report their result with a one-byte reason code (§2.4). Values below 0x80 mean success; 0x80 and above mean failure.
| Code | Name | Typically in |
|---|---|---|
| 0x00 | Success | Every response |
| 0x01, 0x02 | Granted QoS 1, Granted QoS 2 | SUBACK |
| 0x10 | No matching subscribers | PUBACK, PUBREC |
| 0x80 | Unspecified error | Several responses |
| 0x81 | Malformed Packet | CONNACK, DISCONNECT |
| 0x82 | Protocol Error | CONNACK, DISCONNECT |
| 0x84 | Unsupported Protocol Version | CONNACK |
| 0x85 | Client Identifier not valid | CONNACK |
| 0x86 | Bad User Name or Password | CONNACK |
| 0x87 | Not authorized | CONNACK, PUBACK, SUBACK, DISCONNECT |
| 0x8E | Session taken over | DISCONNECT |
| 0x8F | Topic Filter invalid | SUBACK |
| 0x90 | Topic Name invalid | CONNACK, PUBACK, DISCONNECT |
| 0x95 | Packet too large | CONNACK, DISCONNECT |
| 0x97 | Quota exceeded | Several responses |
| 0x9B | QoS not supported | CONNACK, DISCONNECT |
Connection problems has the complete table for connecting. MQTT 3.1.1 has no reason codes, only the CONNACK return codes 0 to 5 and the SUBACK failure value 0x80.
User properties
Section titled “User properties”A User Property is a pair of UTF-8 strings, a name and a value (§3.3.2.3.7).
- A packet can carry several, and a name can repeat.
- The broker forwards them unchanged and in order, without interpreting them.
- They let a receiver tell what a message is without opening the payload.
OPC UA PubSub requires two properties on MQTT 5.0 messages (OPC 10000-14 §7.3.4), and the PDComm simulator sends both:
| Property | Value for UADP data |
|---|---|
| Content Type | application/opcua+uadp |
User Property UAMessageType |
ua-data |
Topic aliases
Section titled “Topic aliases”A topic alias is an integer that stands in for a long topic name (§3.3.2.3.4). The sender transmits the name and the alias in the first PUBLISH and then only the alias, which shrinks every later packet. Aliases belong to one connection, and a sender can use only as many as the receiver allows with Topic Alias Maximum. The PDComm simulator doesn’t use topic aliases.
Flow control and size limits
Section titled “Flow control and size limits”In MQTT 5.0, both sides announce their limits when they connect:
- Receive Maximum (§3.1.2.11.3, §4.9): keep the number of unacknowledged QoS 1 and 2 messages at or below this value.
- Maximum Packet Size (§3.1.2.11.4, §3.2.2.3.6): never send a larger packet.
- Maximum QoS (§3.2.2.3.4): never publish above the QoS the broker accepts.
The PDComm simulator honors the limits the broker announces. It doesn’t send a publication that breaks one; the publish fails with an error instead. Delivery problems lists those errors.