MQTT Retained Messages – Use-Cases and Examples

Content

Optimal MQTT settings and parameters play an important role in an Industrial Unified Namespace (UNS). This guide describes MQTT retained messages, when their use makes sense and when they should be avoided. Further information on the Industrial Unified Namespace (UNS) can be found in our resources.

 

What is a “Retained Message”?

An MQTT retained message is a regular message that is persistently stored in the broker. The broker always stores the last retained message sent, including the associated Quality of Service (QoS) level for the respective topic. Only one retained message is stored per topic, with older retained messages being overwritten. Retained messages enable newly subscribed clients to receive the current status of the topic immediately after subscribing without having to wait for the next update from the publisher.

MQTT Retained Messages in the Context of Unified Namespace (UNS)

 

What is the Difference to Regular Messages?

Regular MQTT messages (without “Retained” flag) are not persisted by the broker. This affects the delivery of messages, especially with longer intervals between new updates and publications. In practice, these can vary from seconds to several minutes or hours. As a result, subscribers only receive an update when a client publishes a new message. However, if immediate access to the current status of a topic is required, retained messages offer the solution. In this case, each newly subscribed client receives the last retained message, even if no further updates have been made since the last publication. The broker thus provides a snapshot of the last known status of the topic. Clients thus always receive the latest information, regardless of the frequency of message publication.

MQTT Retained vs. Regular Messages in the context of Unified Namespace (UNS)

 

Sending MQTT Retained Messages

To send a retained message, the developer sets the “Retained flag” in the MQTT publish message to true. As a result, the broker saves the message and makes it available to new subscribers after the subscription. Most MQTT client libraries and tools, such as MQTT Explorer, provide a user-friendly option to enable the retained flag. The i-flow software also offers an intuitive way to use this function, simplifying the handling of retained messages. Important: The use of retained messages increases the overhead of the MQTT message, especially in environments with a high frequency of updates for retained messages. This should be taken into account when scaling and optimizing the performance of the system.

 

Deleting MQTT Retained Messages

A new retained message with an empty payload (message content) deletes the existing retained message for the corresponding topic. This signals the broker to remove the currently stored retained message for this topic. As soon as the broker receives the message with an empty payload, the retained message for this topic is deleted. No further clients receive an old message when subscribing.

 

Example Use-Case in the Context of the Unified Namespace (UNS)

To clarify the meaning in the UNS context, let’s look at the following example. Let’s imagine a scenario where a sensor monitors critical process parameters such as process temperature. The sensor publishes the data to specific MQTT topics to enable real-time monitoring and automated safety checks in a monitoring system.

1. Incorrect use of the retain flag

  • At 7:00 a.m., a temperature sensor publishes a measured value of 38°C (100°F) to the topic factory/process1/temperature. The retain flag is set to “true” so that the MQTT broker saves this message as the last known status.
  • Maintenance is then carried out and an employee switches off the process.

2. A new subscriber connects

  • At 15:00, an employee switches a new monitoring system online. This system subscribes to the topic factory/process1/temperature.
  • The monitoring system now receives the last saved message from 7:00 a.m., which contains a temperature of 100°F.

3. Unintended consequence

  • As the monitoring system uses outdated temperature data, it could trigger unnecessary alarms.

 

Conclusion

Correct MQTT settings, in particular the use of retained messages, are crucial for reliable data transmission in the context of the Industrial Unified Namespace (UNS). Retained messages enable new subscribers to receive the current status of a topic immediately. However, incorrect use can lead to outdated information and unwanted reactions. Therefore, careful configuration is essential to ensure optimal results.

About i-flow: i-flow is an industrial software company based in southern Germany. We offer manufacturers the world’s most intuitive software to connect factories at scale. Over 400 million data operations daily in production-critical environments not only demonstrate the scalability of the software, but also the deep trust our customers place in i-flow. Our success is based on close collaboration with customers and partners worldwide, including renowned Fortune 500 companies and industry leaders like Bosch.

Try it out now - free trial version

Experience the unlimited possibilities that i-flow offers by taking a test for yourself. Test now for 30 days free of charge on your systems.

Your question has not been answered? Contact us.

Your Contact:

Marieke Severiens (i-flow GmbH)
content@i-flow.io