MQTT Retained Messages: A New Delivery Can Contain an Old Value

Separate receipt from occurrence

OASIS MQTT 5 defines retained messages that can be sent when a subscription is established. New receipt does not prove a new observation. Primary reference: MQTT 5 retained handling.

An illustrative startup timeline

Suppose a fictional sensor application observes a value at 10:00 and publishes it as retained. Another consumer establishes a matching subscription at 10:30 and receives that value under the stated retained policy. Its receipt time is 10:30, but the represented observation is 30 minutes old.

If the payload omits source time, the consumer cannot recover that age from the receipt timestamp alone. A proposed dashboard should retain the distinction between delivered startup state and fresh evidence. The example assumes the retained message remains available; it does not prescribe session, expiry or broker settings.

Define the initial display contract

Write the expected retained policy, observation timestamp or other freshness evidence, receipt time and display meaning. Ask which source records the publisher includes and how missing time is presented. A consumer should not invent a current observation merely because its connection has just become active.

Keep this startup interpretation separate from completeness of history. One retained value does not represent every intervening event. If the project needs a historical sequence, specify that requirement elsewhere. This guide changes no broker or device configuration and asserts no MQTT capability on HM equipment. Its practical outcome is an honest startup data label and a defined question for the supplier when source freshness cannot be established.

Customer Questions

Primary References

These references support the technical principles discussed in this guide. The worked examples and review questions are educational.

• Primary reference: MQTT 5 retained handling