Global – October 28, 2026 -- Neither MQTT retained messages nor persistent sessions can guarantee complete production history, so industrial operators who need every measurement must add application-level buffering and a historian, according to an engineering analysis of the OASIS MQTT 5.0 specification.
Retained messages deliver the latest state to new subscribers
A retained message gives a subscriber the last retained value on a topic when it subscribes. In the example of a packaging line publishing to plant/line2/packer/status, a new maintenance display receives the retained RUNNING state without waiting for the next live publication, provided the message is still available and the subscription's retain-handling settings permit delivery.
A new retained publication such as STOPPED replaces the earlier value. The broker does not store a RUNNING, FAULT, STOPPED sequence. A retained value also goes stale if the publisher disappears without updating the topic, so payloads should carry a source timestamp and device identity.
Retained messages are not part of a client's Session State, and ending a session does not by itself delete them. MQTT 5.0 Retain Handling options can suppress or limit delivery, and retained messages are not sent when a shared subscription is created. A reconnect does not automatically replay a retained value.
Persistent sessions queue only eligible QoS 1 and QoS 2 traffic
A historian collector subscribed to plant/line2/+/temperature can recover queued QoS 1 or QoS 2 messages after a network failure if it resumes its session with the same client identifier. QoS 0 offline queuing is optional under MQTT 5.0, so recovery should not depend on it without verifying broker behavior.
Survival is conditional. Sessions can expire, individual messages can expire, and broker queue limits, administrative actions, outages and storage configuration can reduce or eliminate queued data. Measurements that never reached the broker cannot be recovered by a subscriber's session. The term does not promise durable disk storage through broker restarts.
Clean Start and Session Expiry Interval must be set together
In MQTT 5.0, Clean Start set to 1 discards any existing session for the client identifier, while 0 requests resumption. The Session Expiry Interval defaults to 0 when absent, ending the session at disconnect. Operators should use a stable, unique client identifier and a nonzero interval, then check the broker's session-present indication after reconnecting.
MQTT 3.1.1 uses a single Clean Session flag instead. Message Expiry Interval is a separate control that can remove a queued message even while the session persists.
Field tests should compare broker delivery against historian rows
The analysis recommends a test sequence: publish a retained state and confirm a fresh non-shared subscription receives it. Then, for MQTT 5.0, establish a QoS 1 or 2 subscription, confirm the granted QoS, disconnect, publish several QoS 1 messages, and reconnect without clearing the session. The test should be repeated after session expiry, message expiry and a broker restart, with received messages compared against historian rows for timestamps, duplicates and gaps.
For TDengine TSDB Enterprise, the MQTT ingestion connector can subscribe to broker topics and map messages into historical tables. Its documentation lists protocol selection and a Clean Session setting. Operators should verify which session controls the deployed version exposes, and should not infer durable end-to-end history from the connector's subscription alone.