Based on your question here, I believe we may require some clarification on what the retained flag for a message does with regards to MQTT.
When a message is published to a topic with the retained flag set to true, this triggers the broker to store both the message and the quality of service level that was assigned when the message was published for the specific topic it was published to. Subsequently, each client that subscribes to this topic will be delivered the retained message for the topic as soon as their subscription is complete.
In order for this retained message to be changed, a new retained message, or an empty message with the retained flag set to true, must be published.
With MQTT 5, message expiry values have been introduced. This is separate function, and identifies how long messages will be queued for delivery to clients that are currently subscribed to the relevant topic, but are either offline or otherwise unable to receive the message at the time of publication.
Some more information on both topics can be found here :
there is an actual issue that a published message does not get delivered from HiveMQ Cloud Broker (Retain=True and MessageExpiary=0) but from the Testserver (Mosquitto)
i guess after:
there is still an little issue that the expiarytimer…
according to MQTT5 Spec:
184.108.40.206.3 Message Expiry Interval`
2 (0x02) Byte, Identifier of the Message Expiry Interval.
Followed by the Four Byte Integer representing the Message Expiry Interval.
If present, the Four Byte value is the lifetime of the Application Message in seconds. If the Message Expiry Interval has passed and the Server has not managed to start onward delivery to a matching subscriber, then it MUST delete the copy of the message for that subscriber [MQTT-3.3.2-5].
If absent, the Application Message does not expire.
The PUBLISH packet sent to a Client by the Server MUST contain a Message Expiry Interval set to the received value minus the time that the Application Message has been waiting in the Server [MQTT-3.3.2-6]. Refer to section 4.1 for details and limitations of stored state.
what i am referring is that → “If absent, the Application Message does not expire.” which i would interpret as 0 = No expiration. Like Mosquitto did it in their Broker!
As per the aforementioned documentation, when a message expiry value is left undefined with a publish request, the broker will indefinitely hold the message for matching subscribers.
When defining a message expiry value in conjunction with a retained message, this will define the amount of time in which a message is retained for a topic.
Message Expiry Interval in MQTT 5
Within MQTT 5, clients can set a unique Message Expiry Interval in seconds for each PUBLISH message. This interval establishes the duration the broker preserves the PUBLISH message for subscribers that match the topic but are currently offline. If the interval isn’t defined, the broker must indefinitely hold the message for matching subscribers, yet disconnected subscribers. Furthermore, if the ‘retained=true’ option is selected during the PUBLISH message, the interval also dictates the length of time a message is retained on a particular topic.
For your example, if a message is published to a topic with the retained flag set to true, and the message expiry left undefined, the message will be retained for that topic indefinitely, and any new subscribers to that topic will receive the retained message upon reconnection or subscription to the associated topic.
Note that, for message expiry values, 0 is not the same as undefined. When setting a retained message with an expiry of 0, this will clear the retained message for the topic. If you would like a message to be retained indefinitely, the expiry must be left undefined.