Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamHow to make MQTT to send values after the MQTT broker has restarted
• Publish the data with the retain flag set and make sure the broker is configured for persistence.
• If you also need to guarantee delivery of data generated while the broker was down, let the publishers connect with a static client-ID, Clean-Session = false (Clean-Start = false in MQTT 5) and QoS 1 or 2, and enable persistence on the broker.
Key points
– Retained messages guarantee that the last value on a topic survives a broker restart and is sent immediately to any client that (re-)subscribes.
– Persistent sessions + QoS > 0 guarantee that every queued message produced while the broker was unreachable is delivered after the broker and the client reconnect.
Broker restart effects
• All TCP sessions are dropped → clients disconnect.
• Volatile state (subscriptions, in-flight packets, retained messages, queued messages) is lost unless the broker has been told to persist them.
Two complementary MQTT mechanisms
a) Retained messages
– One message per topic, stored by the broker.
– Delivered to any subscriber immediately after it subscribes, irrespective of when it connected.
– Survives restarts only if broker persistence is enabled.
b) Persistent sessions (session queuing)
– Achieved by ClientID = "fixedId", CleanSession = false (MQTT ≤3.1.1) or CleanStart = false, Session Expiry Interval > 0 (MQTT 5).
– Works only for messages published with QoS 1 or QoS 2.
– The broker stores:
• subscription list
• undelivered outgoing messages
• QoS handshake state
– When the client reconnects it receives the backlog automatically.
Practical publisher flow during an outage
• Client detects disconnect (TCP error / on_disconnect).
• Continues to buffer outgoing QoS 1/2 messages (library does this automatically; add a disk-backed queue if you can lose power).
• Periodically retries connect().
• On successful reconnect with the same ClientID and CleanSession = false, the session resumes and all buffered messages flush to the broker.
Broker-side requirements (examples)
Mosquitto 2.x (mosquitto.conf)
persistence true
persistence_location /var/lib/mosquitto/
autosave_interval 30EMQX 5.x (emqx_retainer.conf)
retainer.storage_type = bothHiveMQ CE (config.xml)
<persistence>
<payload-store enable="true"/>
</persistence>• MQTT 5 adds granular control: Session Expiry, Message Expiry, Will Delay, Shared Subscriptions.
• Brokers increasingly support external persistence engines (Kafka, Redis, Timeseries DB) to survive crashes and allow analytics.
• Edge devices start using store-and-forward patterns (e.g., Eclipse Hono, AWS Greengrass) that marry MQTT session persistence with local SQLite/Flash queues for >99.999 % availability.
• QoS levels
– 0 = “fire-and-forget”; never queued.
– 1 = at-least-once; possible duplicates.
– 2 = exactly-once; extra 2-way handshake, more overhead.
• Retained ≠ Queued: a retained message is overwritten by the next retained publish, while queued messages form a FIFO backlog per client.
• Clearing a retained message: publish the same topic with an empty payload and retain=true.
• Code snippet (Paho-Python publisher)
import paho.mqtt.client as mqtt, time, json
cid = "sensor-t800"
client = mqtt.Client(client_id=cid, clean_session=False)
client.connect("broker.local", 1883, 60)
client.loop_start()
while True:
value = read_temperature()
payload = json.dumps({"t": value, "ts": time.time()})
client.publish("plant/temperature", payload, qos=1, retain=True)
time.sleep(10)– The same code continues to publish; if the broker restarts, Paho’s internal queue keeps QoS 1 messages until the TCP link is back.
• Security: enable TLS and client authentication so that automatic reconnects do not open a replay or spoofing vector.
• Privacy: retained messages may expose sensitive state to any subscriber; apply ACLs.
• Safety: for command topics use QoS 2 plus application-level idempotency to avoid duplicate actuation.
Implementation checklist
persistence true and path on disk with enough space.clean_session=False / clean_start=False.retain=True for current value topics.reconnect_delay_set() (Paho) or similar back-off.Potential challenges & mitigation
• Large backlog → tune max_queued_messages and storage location.
• Flash wear on microcontrollers → batch-write queue.
• Broker disk full → enable log rotation & alerts.
• Retained messages alone are not suitable for full telemetry history. Use a time-series DB or MQTT-to-Kafka bridge.
• Some lightweight brokers (earlier Mosquitto 1.x builds, uMQTT on MCUs) do not persist retained messages; upgrade or switch.
• Very old MQTT 3.1 devices might ignore Session Expiry semantics of MQTT 5.
• Evaluate MQTT SN or CoAP Observe for sensor networks with aggressive sleep cycles.
• Study MQTT Sparkplug B for industrial state replication (birth certificates + death certificates).
• Look at Persistent Data Exchange Patterns in Eclipse Tahu and W3C Web of Things.
• Explore edge-cloud synchronization frameworks (Azure IoT Edge, AWS IoT Greengrass v2).
To keep values available after the broker restarts:
retain = true and enable broker-side persistence so that value is stored on disk. CleanSession = false / CleanStart = false) and QoS 1 or 2; ensure both client and broker persist the session.