We’ve been looking into the foundational changes that MQTT 5 introduces and the top reasons MQTT users are upgrading to MQTT 5. We’ve also started to individually examine each of the new features in the MQTT 5 protocol. Let’s continue with a very exciting feature: User Properties

At the end of this blog post we also have a video about User Properties.

MQTT 5 was specifically designed to bridge the gap between what MQTT 3.1.1 offered users and what those users expect from the de facto standard protocol for the Internet of Things. MQTT 5 ensures that the MQTT protocol will keep its place as the standard IoT protocol for decades to come.

How Do User Properties in MQTT 5 Work?

In MQTT 5, user properties are basic UTF-8 string key-value pairs that you can append to almost every type of MQTT packet, excluding PINGREQ and PINGRESP. This includes control packets such as PUBREL, or PUBCOMP. As long as you don’t exceed the maximum message size, you can use an unlimited number of user properties to add metadata to MQTT messages and pass information between publisher, broker, and subscriber. The feature is very similar to the HTTP header concept.

Why Were User Properties Introduced in MQTT 5?

Two major drawbacks MQTT 3 users voiced were the lack of extensibility of the protocol and the difficulty of creating multi-vendor deployments. The User Properties feature in MQTT 5 addresses both of these concerns. With the added possibility to pass virtually any information across an entire MQTT system, the new specification makes sure that users can extend the standard protocol features to meet their specific needs.

Practical Use Case Examples of MQTT 5 User Properties

While the technical details of the User Property feature may seem trivial, the practical impact of having a way to pass metadata across an entire MQTT ecosystem is, in fact, enormous. Let’s take a look at three of the more common use cases that I have personally heard many times from users who were yearning to have a feature like User Properties introduced in the MQTT specification.

Saving Resources with Payload Metadata Using User Properties in MQTT 5

In scenarios that use MQTT to connect multiple systems that have been implemented by separate teams and vendors, it is not uncommon that the payload structure varies greatly. Some clients may send JSON, XML, or compressed formats such as Protobuf. With the possibility of adding metadata to the messages that can include the specific markup language and version used to encode the payload, the receiving client or in some cases the broker no longer have the need to unpack the payload and try out a number of possible parsers until the right one is found. Instead, each message carries its own parsing information and reduces the computing load on the entire system.

Increased Efficiency Through Application Level Routing Using User Properties in MQTT 5

MQTT is perfectly suited for, and often utilized as, the transporting and routing component in large scale data processing and streaming deployments. Such deployments frequently contain multitudes of different devices, systems, and applications. It is not unusual for multiple systems to receive the same message for different purposes. For example, one system to display live data and another for long term storage of the same data. In this case, user properties can function as an additional application-level timestamp for the message. The broker can then very quickly decide to not pass certain messages to a specific set of subscribers, based on a predefined validity period. This provides an additional application-level layer for providing message relevance to the Message Expiry Interval.

Transparent Traceability in Complex Systems Using User Properties in MQTT 5

IoT deployments are often complex, and the existence of separate systems can make it hard to pinpoint where a specific message comes from or why a multi-layer message flow is unsuccessful. In MQTT 3.1.1 there is no way for the subscriber to know who the publisher of a received message was. While it is possible in 1-to-1 scenarios to embed a unique identifier in the topic, this method negates some of the biggest advantages of the publish-subscribe paradigm. The new User Property feature in MQTT 5 allows the publisher to easily add information about itself. For example, a client ID or publishing region. This information is forwarded to any receiver of the message without adding any extra business logic.

Similarly, you can add a specific system identifier to the MQTT messages to log and trace the entire message flow from sender to all subscribers. When properly implemented, these identifiers can even span multiple MQTT message flows. This ability opens up a completely new level of transparency and traceability for business-critical use cases such as premium paid services for end customers.

Summary and Additional Information on User Properties in MQTT 5

• User properties are UTF-8 string key-value pairs that can be appended to any MQTT message
• The possibilities to apply additional logic to an MQTT use case with this feature is almost limitless
• Deployments and projects that span across multiple systems and vendors can use this feature to ensure consistency

Personally, I am very excited to see all the ingenious ways that MQTT users will take full advantage of this simple yet powerful feature. Feel free to add your ideas to the comments!

Learn More About MQTT 5

Over the next few weeks, we will continue our technical deep dive into all of the MQTT 5 features. In Part 7 of this series we will be talking about Shared Subscriptions. If you would like to join us, sign up for our newsletter to get regular updates and ensure that you don’t miss a post.

About Florian Raschbichler

Florian serves as the head of the HiveMQ support team with years of first hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.
Contact Florian