by Jesmi | Apr 14, 2020 | Industry4.0 | 0 comments
When a publisher publishes a message to a subject to which no one has subscribed, the message is simply discarded by the MQTT Broker. By setting the retained message flag, the publisher can inform the broker to keep the last message on that topic. This feature allows you to store a single message per MQTT topic and send it to all current and future subscribers. To save a retained message, simply set a retained flag when publishing it to the broker. At that point, the message is delivered to all current subscribers as usual, as well as any future devices that subscribe to that topic. In this post, we will provide an overview of this feature and explain it using an example. Let’s take a look at this right now.
When we hear the phrase retained messages, we immediately think of messages that have been stored. These MQTT Retained messages are defined in the MQTT 3.1.1 specification and are created by publishing a message with the retained flag set to ‘True.’ The broker stores the most recently retained message as well as the MQTT QoS for that topic. When compared to MQTT v3.1.1, it provides a Retain Handling field in the subscription option and makes a more in-depth division of whether to send a retained message when the subscription is established in MQTT v5.0. As previously stated, a retained message is delivered to any currently subscribed clients in the same way that a normal message is, and it is also automatically sent to new clients who subscribe to that topic. As only one retained message can be saved per topic, any future retained messages will replace the existing retained messages.
In this example, the sensor sends the broker its current value along with a true retained message. This message is immediately received by the MQTT client who is online. The broker stores the message and delivers it to the second client once it comes online as the retained flag is set to true. As a result of this feature, when the offline client comes online, it is updated with the most recent sensor value.
After a client subscribes to a topic, MQTT retain messages are sent to the client. You can publish a configuration message with the RETAIN flag set, if you want all clients who subscribe to a topic to receive the MQTT retained message immediately after their subscription. When a new configuration message is published, subscribing clients receive updates to that configuration as well.
Devices can save messages by setting the RETAIN flag on current-state messages. When applications connect or reconnect, they can subscribe to this topic and receive the most recent reported state immediately after doing so. They can avoid waiting for the device’s next message to see the current state this way.
We’ll go over how to set and delete the MQTT retained messages feature in the sections below.
A retain message is a standard MQTT publish message with the retained flag enabled. When a publisher sends data to the broker, it also sends some extra information in addition to the topic and the message, as you are probably aware. The PUBLISH packet is the name of this packet. They’ve provided a field on the fixed header in this packet to set the retain flag to 1 or 0. It will be set to 0 by default, indicating that the message will not be saved. However, if we set it to 1, the MQTT Broker will store the message and its corresponding Quality of Service level for that topic, when it receives the packet.
Can you figure out how to disable the retain feature for a specific topic? It’s not as simple as sending a message with the retain flag set to 0, as that’s the default condition. Sending an empty message to the same topic with the retain flag set to 1 is the correct way to do it. Yes, this may appear counter intuitive, but it was done on purpose to avoid conflicts with any real time publishing on the same topic that did not have the retain flag set to 1.
The MQTT retained message feature is useful for preserving an object’s most recent state, which is especially useful when the state does not change frequently. The quality of the service settings has no impact on the messages that are retained.
To Learn more about the protocol,
Please take a moment to fill this form
We utilize Cookies to enhance your experience. Your acceptance implies our policy agreement. Your data is securely handled, and you can learn more about our commitment to data safety in our comprehensive Privacy Policy.
