MQTT: what is "Last Will and Testament" (LWT) and how does it work?

3 minutes of reading

MQTT logo

Once familiar with the proMQTT tocollo and with its main characteristics and purposes, it is good to discover and master a feature on which we often do not dwell, although it is - especially in home automation - particularly useful: the so-called "LWT"Or"Last Will and Testament"

As the translation suggests, these are the last will and testament of a component equipped with protocollo MQTT, but obviously in this case there is nothing mournful: it is, in fact, the management of the status of the components in the event of disconnections improvvise and not managed. Not only: this feature is used not only for the death of the component, but also for his birth.

Let's see how.

Nb First di profollowing in the reading is advised to have a clear head what it is MQTT, Its functionalnamento in home automation and the concept of "retain".

A matter of states

In domotics (and not only) it is certainly fundamental know the connection status of a particular component equipped with proMQTT tocollo, not to be confused with operational status linked to the characteristics profirst (eg operating status of any relays, sensors, etc.). In everyday use it is indeed possible for these components lose (temporarily or not) the connection to the broker for:

  • lack of power (dead batteries);
  • low signal Wi-Fi;
  • anomalies in the firmware / software (unexpected restarts)

and other unexpected conditions.

In the MQTT area we often talked about "telemetric messages" provided by the home automation components present in the home. We think trivially an intelligent sensor equipped with proMQTT tocollo: this component will cyclically deliver a telemetry message that reports the operational status linked to proits functionality (containing, for example, temperature and humidity).

Usually those who collect this information are other MQTT clients which, connected to the broker, subscribe to the topical of telemetric messages of interest to them; these clients are (usually) HUB personal (Home Assistant, Homey etc.) which use the information thus collected for the ordinary uses envisaged for the profirst home automation (visualization, automation, etc.).

But what is also fundamental is not only receiving or sending messages to and from MQTT components, but also be aware or not if these components are actually connected to the broker via the network TCP/IP, if they are then operating. It can indeed happen, as explained above, that the connection between the component and the broker "cada", causing the component to be unavailable.

To manage these cases so that the MQTT clients are not unaware of the status of the components of interest to them, it intervenes, appgreasy, theLWT. In practice it is a special MQTT message (with retain always set "true") Which is sent to the subscribers in two specific moments: to the" birth "and" death "of the component.

When the component "is born" (ie when it enters the LAN network) it by nature (and configuration) connects to the broker through the coordinates it knows (IP address, any access credentials) and, on the first connection, communicates the LWT payload provided in the event of a disconnection (usually "offline"). The broker "marks" this payload and sets it aside, waiting to use it - eventually - in the event of a connection failure. A true e proprio will, just saying.

After successful connection the component also publishes on the broker an MQTT message containing a LWT type topic with a payload that identifies it as operational, or (usually) "Online". Immediately, all the clients registered to the topic of the LWT message receive it and therefore assume that the component is - for theappanointed - operating.
For example, in the case of a Sonoff with basic configuration the MQTT message published after the first connection will be:

tele /Sonoff/ LWT Online

where the topic is obviously "tele /Sonoff/ LWT"While the payload is"Online"

Subsequently, in case the hit component "fails" (due to the possible causes mentioned above) - after a certain amount of time has passed in which the broker does not receive signs of life on the part of the component - the latter pulls out the expected payload for the "fall" (the one previously set aside) and publishes it in an LWT message, like:

tele /Sonoff/ LWT Offline

As a result, all clients subscribed to the topic (also in this case "tele /Sonoff/ LWT") Will be notified immediately the unavailability status of the component.

In practice, while is the component itself to inform everyone of having entered into operation, it is the broker instead to notice a possible fall and to inform the network of this event (using the LWT payload communicated by the component when it was "born" the last time).

This explains why, for example, su Home Assistant to configure a switch Sonoff-Tasmota we use syntax of this type:

  - platform: mqtt
    name: "Interruttore"
    state_topic: "stat/Interruttore/RESULT"
    value_template: "{{ value_json.POWER }}"
    command_topic: "cmnd/Interruttore/POWER"
    availability_topic: "tele/Interruttore/LWT"
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"

As you can easily see, in the field "availability_topic"Comes probefore indicating the topic LWT to which to register the client of Home Assistant to instantly know the status of the component, with the respective expected payloads (for the two possible situations, “Online" and "offline") following.

inDomus telegram channel