IoT device
pump-7 connects with a Will Message and then publishes an online birth message.
MQTT Last Will Workbench
Trace when an MQTT broker publishes a stored Will Message and when it must cancel it.
animation
mqtt
protocols
reliability
Learner-ready MQTT Last Will workbench with scenario presets, step/play controls, keep-alive and Will Delay feedback, retained status behavior, birth-message pairing, MQTT 5 disconnect nuance, source links, and desktop/mobile visual verification.
MQTT Last Will Workbench
Trace the Will Message stored during CONNECT, then compare normal DISCONNECT, network failure, keep-alive timeout, MQTT 5 disconnect-with-will, and delayed reconnect cancellation.
Will topic
devices/pump-7/status
Broker decision
store will
Detection path
connection alive
Subscriber output
online
1. CONNECT
2. Birth publish
3. Fault event
4. Detect close
5. Will delay
6. Notify subscribers
Configure presence path
30 s keep alive
45 s timeout window
10 s delay
event 1
offline notice after 10 s
risk: low
Event source
The device is connected and sending MQTT control packets within the Keep Alive window.
Broker decision engine
The broker stores the Will Message from CONNECT and clears it only when protocol rules say it should.
Will topic
devices/pump-7/status
Will payload
{"status":"offline"}
QoS 1 + retained
Published by the broker only when the trigger condition is met.
C
client
broker
subscribers
Will is stored, connection is alive
No Will Message is published while the connection is healthy.
Session state
Will properties are associated with the network connection and server-side session state.
Retained status
Retained birth/will messages make new subscribers see the current presence state.
Status subscribers
Dashboards subscribe to devices/+/status and currently see pump-7 as online.
Routing trace
Step through CONNECT, birth message, fault, detection, delay, and subscriber update.
Will is armed, not published
The broker stores the Will Message during CONNECT. Because the client is still connected, subscribers should see the retained birth message instead of the offline will.
Quick reference
Will is configured in CONNECT
- The client sets Will Flag, Will QoS, Will Retain, Will Topic, and Will Payload.
- MQTT 5 can add Will Delay Interval, Message Expiry, Content Type, User Properties, and related will properties.
- The broker stores the will until a rule publishes or discards it.
When it publishes
- Unexpected network close, protocol error, I/O failure, or Keep Alive timeout can publish the will.
- MQTT 5 DISCONNECT with reason code 0x04 can explicitly request will publication.
- Will Delay can postpone publication and allow fast reconnect cancellation.
When it does not
- Normal DISCONNECT discards the stored will.
- Reconnect before Will Delay expires can prevent the offline message.
- LWT is presence detection, not an instant heartbeat.
Technical accuracy notes
Keep Alive timing
The server is allowed to close the connection if it does not receive MQTT control packets within one and a half times the Keep Alive interval. The will is considered after that close plus any Will Delay.
Retained birth/will pair
A retained online birth message followed by a retained offline will is a common presence pattern. The will retain flag controls whether new subscribers see the offline state later.
QoS still matters
The Will Message uses its configured QoS when the broker publishes it. QoS can affect acknowledgments and duplicates, but it does not make presence detection instantaneous.