In the context of the Unified Namespace (UNS), up-to-date status information is essential. MQTT Retained Messages provide a simple way to store the last known value of a topic on the broker. This value is then immediately available to new clients as soon as they connect. When used correctly, retained messages improve response times. They also simplify the commissioning of new systems and increase transparency on the shopfloor. However, as with many powerful features, their real value lies in targeted and thoughtful use. In this article, we explain what MQTT Retained Messages are and how they differ from normal MQTT messages. You will also learn when it makes sense to use them – and when it doesn’t.
What are MQTT Retained Messages?
An MQTT Retained Message is a normal message that the broker stores permanently. For each topic, the broker keeps only the most recent retained message. Older retained messages are overwritten. The message is saved together with its quality of service (QoS) level. This means: When a new client subscribes to a topic, it immediately receives the last retained message. The client does not have to wait for the next update from the publisher. As a result, the system becomes faster, more transparent, and easier to manage.
What is the Difference to Regular Messages?
Regular MQTT messages – without the “Retained” flag – are not saved by the broker. This has a direct impact on message delivery. Especially when updates are sent at long intervals, gaps can occur. In practice, these intervals can range from a few seconds to several minutes or even hours. Subscribers only receive new data when a client actively publishes an update. If no update is sent, no message arrives. This becomes a problem when the current status of a topic is needed immediately. In such cases, MQTT Retained Messages offer a clear advantage. The broker delivers the last saved retained message to every newly subscribed client – even if no new messages have been published since then. This way, the broker acts like a snapshot provider. Clients always get the latest known value, no matter how often updates are sent.
Send and Deleting of MQTT Retained Messages
To send a retained message, the “Retained” flag must be set to true in the MQTT publish message. This tells the broker to save the message and deliver it to new subscribers after they subscribe. Most MQTT client libraries and tools, like MQTT Explorer, offer a simple way to enable this flag. The setting is often just a checkbox or a parameter. The i-flow software also supports retained messages in an intuitive way. This makes it easy to configure and manage retained messages – even for complex use cases.
A retained message with an empty payload deletes the existing retained message for that topic. This tells the broker to remove the saved message from its memory. As soon as the broker receives a retained message with no content, it deletes the stored value for the topic. From that moment on, new subscribers no longer receive any old data. This is useful when the retained information is no longer valid or needed. It ensures that only relevant and current data is shared.
Useful Use Cases in the Unified Namespace (UNS)
Retained messages ensure that important status and context data is permanently available in the UNS. The retain flag enables new subscribers to receive the last system status, particularly in the case of slowly updated or state-oriented topics. Typical use cases are:
- Machine status and availability: Operating statuses of systems (on/off, operating mode) can be published as retained messages. When a monitoring client connects, it immediately sees whether a machine is running or not. Availability data – such as heartbeat signals or last-will messages – also benefit from the Retain flag. These messages show whether a system is online. Thanks to Retain, every subscriber always receives the current status right after connecting.
- Last measured values: A classic SCADA system requires immediate access to the last known status of all relevant tags at startup – e.g. machine status, alarms or production counters. When a worker opens his HMI, he expects to see the current status immediately without having to wait for new data. In this case, retained messages can ensure that the HMI has all the required statuses available immediately.
- Master data and metadata: Rarely changed configuration parameters or metadata (such as device configurations, calibration values, system identifiers) are often stored as retained messages. New clients in the UNS can access such information at any time, which makes it easier to quickly commission additional applications. For example, topics with device data (serial number, model) or system descriptions can be stored as retained so that they remain present in the Unified Namespace.
Typical Misuse of Retain
Despite the advantages, retained messages can cause problems if used incorrectly in the UNS. Common misapplications include:
- Outdated data and misinformation: Let’s imagine the following scenario. At 7:00 a.m., a sensor publishes a measured value of 187°C to the factory/process1/temperature topic. 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. At 15:00, another 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 of 187°C. As the monitoring system uses outdated temperature data, it could trigger false alarms.
- Performance overhead: A common mistake is the recommendation that all MQTT messages should have the retain flag. This contradicts the design concept of MQTT and can overload brokers, especially with high-frequency topics (e.g. sensor data in millisecond intervals). You should therefore limit the use of retain to meaningful data and check whether retain is actually necessary for high-frequency streams.
As Arlen Nipper, one of the inventors of MQTT, emphasizes: “If everything was published with RETAIN then it’s probably NOT an application that should be using MQTT.”
Best Practices for the Use of Retained Messages
Efficient lifecycle management for retained messages ensures that the Unified Namespace (UNS) remains consistent and up-to-date. Important strategies include the following points.
Planned Update and “Birth” Events
When a system or device starts or restarts, it should publish its key status data again – as retained messages. This helps initialize the Unified Namespace (UNS) correctly. Without this step, outdated data from a previous session may remain in the broker. Protocols like Sparkplug B solve this with a birth message. This message sends all current values when a connection is established. A similar approach works with MQTT. Devices can resend selected topics – such as status or last known values – with the Retain flag set at startup.
Last Will and Offline Status
The combination of Retain and Last Will Testament (LWT) is recommended for status topics. In this case, the client sets up an LWT message when connecting, which sets the status topic …/state to “offline” in the event of an error, for example. If the client fails, the broker automatically publishes the predefined message to all subscribers. In this way, the online/offline status is always visible in the UNS without manual intervention. It is important to configure the LWT message as retained so that the offline status remains until the device reports online again.
Regular Cleanup of Retained Messages
Retained messages stay in the broker until they are actively deleted. Without regular clean-up, outdated or unused topics can remain visible. To avoid this, a structured clean-up should be done regularly – for example, after tests or when sensors are removed. This is done by sending a retained message with an empty payload to the relevant topic. The broker then deletes the stored value. This process should be automated or defined as a fixed maintenance task. That way, the Unified Namespace (UNS) stays clean, consistent, and up to date.
Conclusion
The right MQTT settings are key for reliable data in the Industrial Unified Namespace (UNS). In particular, the selective use of retained messages plays a central role. Retained messages give new subscribers instant access to the last known state. This improves speed and transparency. However, they do not replace real persistence. If used incorrectly, retained messages can deliver outdated data or trigger unwanted actions – especially in SCADA-like environments. The rule is clear: Use retained messages carefully and only where they truly make sense.
