English is currently available.
IoT & MQTT DISCUSSION
I have about 30 ESP32 nodes publishing to a Mosquitto broker and a dashboard that should show which nodes are alive. At present I guess from the time of the last reading, which is unreliable because some nodes only publish on change.
I have read that the Last Will feature is meant for this, but I do not understand when the broker sends the will, how fast it reacts to a node losing power, and how to make the dashboard show the right state immediately after it starts.
The will is a message the client hands to the broker inside its CONNECT packet: a topic, a payload, a QoS and a retain flag. The broker stores it and publishes it on the client's behalf if the connection ends without a proper DISCONNECT packet: the network connection breaks, the keep-alive expires, or the client violates the protocol. If the client disconnects cleanly, the will is discarded and not sent.
So it is a way for a device to announce its own unexpected death, arranged in advance.
The standard presence pattern uses one status topic per device with retained messages. Set the will to topic devices/node12/status, payload offline, QoS 1, retain true. Immediately after every successful connect, publish online to the same topic, also retained. Before a deliberate shutdown or deep sleep, publish offline (or a sleeping state) yourself and then disconnect.
Because the messages are retained, a dashboard that subscribes to devices/+/status receives the current state of all 30 nodes at once when it starts, without waiting for anything to happen.
How fast the broker notices depends on how the node dies. If the TCP connection is closed or reset, the will goes out at once. If the node loses power or Wi-Fi, nothing is sent and the broker only finds out through the keep-alive: the client promises to send something (at least a PINGREQ) within each keep-alive interval, and the broker closes the connection when one and a half times that interval passes in silence.
With a keep-alive of 60 seconds, detection therefore takes up to 90 seconds. Setting it to 15 seconds gives about 22 seconds. Do not go very low on Wi-Fi or cellular links; short dropouts would mark healthy nodes as offline, and the extra pings cost power.
Two details prevent wrong states. Give every node a unique client ID. If two nodes share one, the broker disconnects the older connection whenever the other connects, and the status topic flips constantly. And remember that the online message is published by your code, so a node that reconnects automatically must publish it in the on-connect handler, not once in setup.
The will does not replace application-level health. A node whose sensor task has hung but whose network stack still answers pings looks online. If that matters, also publish a periodic heartbeat with an uptime counter, and let the dashboard flag nodes whose heartbeat is stale.
MQTT 5 adds a will delay interval: the broker waits that many seconds after the disconnection before publishing the will, and cancels it if the client reconnects to its session in time. That filters out short Wi-Fi glitches without lengthening the keep-alive.
Check that both the broker and the client library are using protocol version 5 before relying on it; many small microcontroller libraries implement only 3.1.1.
Back to IoT & MQTT community
