MQTT: cos’è e come funziona la “Retain”

La retain è sì tra le funzionalità più importanti del protocollo MQTT, ma anche tra quelle più sconosciute, il ché causa sovente svariati problemi al corretto funzionamento della propria domotica personale.

In ambito MQTT, come sappiamo, ogni client non ha modo di ottenere certezza rispetto all’avvenuta consegna di un dato messaggio al destinatario, ma solo – al massimo – della corretta consegna verso il broker (per colmare eventuali lacune si consiglia la lettura della scheda dedicata al QoS). Per la stessa logica, un client che sottoscriva un topic d’interesse presso il broker non potrà sapere quando (e se) un altro client pubblicherà un messaggio su tale topic. Ne è totalmente all’oscuro.

Ed è qui che interviene il concetto di retain.

Come funziona

Ogni messaggio inviato al broker da un client MQTT possiede una flag di retain che può essere valorizzata “vero” o “falso” in base al fatto che il client abbia attivato o non attivato, per quel messaggio, tale funzione.

Laddove la flag sia impostata a “vero” (quindi, in gergo, sia attivata la retain), tale messaggio – oltre ad essere consegnato immediatamente ai client collegati e che abbiano sottoscritto il topic indicato nel messaggio stesso – viene messo da parte, conservato per così dire, dal broker, in attesa di inviarlo a qualunque client che si colleghi in un secondo momento e che sottoscriva il topic indicato nel messaggio.

Poniamo come esempio che il client MQTT presente su un attuatore domotico Sonoff riprogrammato con firmware Tasmota invii messaggi telemetrici MQTT relativi al proprio stato operativo (“acceso”/”spento”) con retain non attiva e poniamo altresì di possedere una domotica basata su HUB personali che abbia il proprio client iscritto al topic indicato nei messaggi telemetrici di cui sopra al fine di collezionare lo stato dell’attuatore per gli scopi propri della domotica personale.

Immaginiamo che l’HUB si riavvii (o perda la connessione, per motivi diversi): al completamento del riavvio l’attuatore di cui sopra risulterebbe presso l’HUB in uno stato sconosciuto fin tanto l’attuatore non invii, per qualche motivo, un nuovo messaggio di stato al broker.

In caso, diversamente, il messaggio telemetrico inviato dall’attuatore avesse attiva la retain attiva, il riconnettersi/iscriversi al topic da parte del client dell’HUB causerebbe l’immediato invio ad esso dell’ultimo messaggio salvato da parte del broker, così da avere immediatamente lo stato (per lo meno, l’ultimo ricevuto) disponibile.

Quando usarla

Semplice: in linea di principio il meno possibile. Il motivo è semplice: salvo che non sia necessario a tutti i costi la ricezione di un messaggio – anche procrastinato – da parte del destinatario, la presenza della retain attiva può creare più problemi di quanti non ne risolva.

Poniamo il caso di attuatori dotati di supporto MQTT: capita, a volte, che tali dispositivi perdano la connessione Wi-Fi. Capita: si tratta di dispositivi con piccole antenne, a volte sono gli stessi firmware ad avere piccoli problemi che causano disconnessioni sparse. L’uso di comandi inviati dalla domotica con retain attiva, per esempio, causano a volte più problemi che altro: immaginiamo di avere inviato un comando ON all’attuatore via domotica, e poi averlo impostato manualmente in OFF (con un interruttore fisico, magari) mentre, per qualche istante, l’attuatore era offline. Alla prima riconnessione utile l’attuatore si riaccenderebbe “da solo” (perché riceverebbe un comando inviato dal broker a causa della retain attiva), creando una situazione non voluta.

Consigli

Si consiglia dunque di non attivare mai la retain salvo casistiche molto specifiche in cui sia realmente necessaria, a tutti costi, la consegna di un messaggio specifico verso specifici destinatari. Inoltre, si consiglia – dopo l’avvenuta verifica delle proprie configurazioni – di pulire le eventuali retain presenti sul proprio broker.

In caso si utilizzi un broker MQTT basato su Eclipse Mosquitto, la pulizia si effettua così.