MQTT: cos’è e come funziona il “Last Will and Testament” (LWT)

Una volta familiarizzato con il protocollo MQTT e con le sue principali caratteristiche e scopi, è bene scoprire e padroneggiare una funzionalità sulla quale spesso non ci si sofferma, sebbene sia – specialmente in domotica – particolarmente utile: il cosiddetto “LWT” o “Last Will and Testament“.

Come suggerisce la traduzione, si tratta delle ultime volontà e testamento di un componente dotato di protocollo MQTT, ma ovviamente in questo caso non c’è niente di luttuoso: si tratta, infatti, della gestione dello stato dei componenti a fronte disconnessioni improvvise e non gestite. Non solo: tale caratteristiche viene utilizzata non solo per la morte del componente, ma anche per la sua nascita.

Vediamo come.

Questione di stati

In domotica (e non solo) è certamente fondamentale conoscere lo stato della connessione di un determinato componente dotato di protocollo MQTT, stato da non confondersi con lo stato operativo legato alle caratteristiche proprie (eg. stato operativo degli eventuali relè, sensori eccetera). Nell’uso quotidiano è infatti possibile che tali componenti perdano (temporaneamente o meno) la connessione verso il broker per:

• mancanza di alimentazione (batterie scariche);
• basso segnale Wi-Fi;
• anomalie nel firmware/software (riavvii imprevisti)

e altre condizioni inattese.

In ambito MQTT spesso abbiamo parlato di “messaggi telemetrici” erogati dai componenti domotici presenti in casa. Pensiamo banalmente a un sensore intelligente dotato di protocollo MQTT: tale componente erogherà ciclicamente un messaggio telemetrico che riporti lo stato operativo legato alle proprie funzionalità (contenente, per esempio, temperatura e umidità).

Solitamente chi raccoglie tali informazioni sono altri client MQTT i quali, connessi al broker, sottoscrivono i topic dei messaggi telemetrici di loro interesse; tali client sono (solitamente) HUB personali (Home Assistant, Homey ecc.) i quali utilizzano le informazioni così raccolte per gli usi ordinari previsti per la propria domotica (visualizzazione, automazione eccetera).

Ciò che però è anche fondamentale non è solo ricevere o inviare messaggi da e verso componenti MQTT, ma anche esser consapevoli o meno se tali componenti siano effettivamente collegati al broker tramite la rete TCP/IP, se siano quindi operativi. Può infatti capitare, come spiegato sopra, che la connessione tra il componente e il broker “cada”, causando una indisponibilità del componente.

Per gestire queste casistiche in modo che i client MQTT non siano inconsapevoli sullo stato dei componenti di loro interesse interviene, appunto, l’LWT. In pratica si tratta di uno speciale messaggio MQTT (con retain impostata sempre “true“) il quale viene inviato ai sottoscrittori in due momenti specifici: alla “nascita” e alla “morte” del componente.

Quando il componente “nasce” (ovvero quando entra in rete LAN) esso per natura (e configurazione) si collega al broker tramite le coordinate che conosce (indirizzo IP, eventuali credenziali d’accesso) e, alla prima connessione, comunica il payload LWT previsto in caso di eventuale disconnessione (solitamente “Offline“). Il broker si “segna” tale payload e lo accantona, in attesa di utilizzarlo – eventualmente – a fronte di una caduta di connessione. Un vero e proprio testamento, per così dire.

Dopo l’avvenuta connessione il componente pubblica sul broker anche un messaggio MQTT contenente un topic di tipo LWT con un payload che lo identifica come operativo, ovvero (solitamente) “Online“. Immediatamente, tutti i client iscritti al topic del messaggio LWT lo ricevono e quindi assumono che il componete sia – per l’appunto – operativo.
Per esempio, nel caso di un Sonoff con configurazione base il messaggio MQTT pubblicato dopo la prima connessione sarà:

tele/Sonoff/LWT Online

dove il topic ovviamente è “tele/Sonoff/LWT” mentre il payload è “Online“.

Successivamente, in caso il componente di colpo “venga meno” (per le possibili cause citate in precedenza) – passato un certo lasso di tempo in cui il broker non riceve segni di vita da parte del componente – quest’ultimo tira fuori il payload previsto per la “caduta” (quello precedentemente accantonato) e lo pubblica in un messaggio LWT, tipo:

tele/Sonoff/LWT Offline

Di conseguenza, tutti i client iscritti al topic (anche in questo caso “tele/Sonoff/LWT“) saranno immediatamente notificati dello stato di indisponibilità del componente.

In pratica, mentre è il componente stesso a informare tutti dell’essere entrato in operatività, è invece il broker ad accorgersi di una sua eventuale caduta e a informare la rete di tale evento (utilizzando il payload LWT comunicato dal componente quando è “nato” l’ultima volta).

Ecco spiegato perché, per esempio, su Home Assistant per configurare uno switch Tasmota utilizziamo sintassi di questo tipo:

mqtt:
  switch:
  - 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"

Come si nota facilmente, nel campo “availability_topic” viene proprio indicato il topic LWT al quale iscrivere il client di Home Assistant per conoscere istantaneamente lo stato del componente, con i rispettivi payload previsti (per le due possibili situazioni, “Online” e “Offline“) a seguire.