Stato “sconosciuto” (unknown) su entità MQTT di Home Assistant post 2022.3: perché e come risolvere

A partire dall’aggiornamento 2022.3 di Home Assistant Core – il più diffuso HUB per domotica personale al mondo – molti utenti avranno forse notato sull’interfaccia, a valle del riavvio dell’HUB, una serie di entità derivanti da integrazione MQTT con stato “sconosciuto” (in inglese “unknown”), nello specifico i Binary Sensor, Switch, Light, Fan e Humidifier. 

Perché?

Il motivo è semplice – in realtà è sempre stato così, ma prima il comportamento dell’HUB prima dell’aggiornamento era diverso.

Procediamo per esempi. Ipotizziamo l’integrazione manuale del sensore di surriscaldamento di una presa Shelly Plug S via MQTT. La configurazione via YAML a grandi linee sarà la seguente:

mqtt:
  binary_sensor:
  - name: "Surriscaldamento presa"
    state_topic: "shellies/NOME_SHELLY/overtemperature"
    payload_on: 1
    payload_off: 0
    device_class: problem
    qos: 1

In questo banale caso di esempio, l’HUB si aspetta di ricevere lo stato del surriscaldamento tramite uno specifico topic MQTT (se non si sa di cosa si stia parlando, forse è il caso di leggere questo approfondimento), da configurazione indicato come “shellies/NOME_SHELLY/overtemperature“, il quale prevede uno stato 1 o 0 in base al fatto che la presa sia in surriscaldamento o meno.

Fino alla versione 2022.2, per i Binary Sensor, Switch, Light, Fan e Humidifier di derivazione MQTT, l’HUB all’avvio si limitava a ripristinarne il valore a ‘off‘, a prescindere. Ma si trattava di un’anomalia:  in realtà lo stato potrebbe esser nel frattempo cambiato.

Ecco perché gli sviluppatori di Home Assistant hanno – giustamente – deciso di uniformare il comportamento di Binary Sensor, Switch, Light, Fan e Humidifier via MQTT a tutte le altre piattaforme di integrazione: se uno stato non è noto, non è noto, pertanto è bene che l’entità derivante assuma stato “unknown” (a schermo, in italiano, “Sconosciuto” – ma il vero stato è sempre “unknown“), piuttosto che uno forzato stato a ‘off‘.

È un problema?

No, almeno all’apparenza.

Prendiamo il caso di uno switch gestito via MQTT, diciamo un banale Sonoff Basic riprogrammato con firmware Tasmota. Ciclicamente gli attuatori così configurati inviano un aggiornamento di stato, quindi il primo topic telemetrico ricevuto dall’HUB aggiornerebbe lo stato da “unknown” a uno stato effettivo. Diciamo pure che la cosa non ci piace particolarmente, in quanto potrebbero esserci automazioni e script influenzati da tale stato “spurio”, nel periodo in cui manchi ancora l’aggiornamento.

Il problema si fa invece ancora più critico sui sensori, come quello di cui sopra, per esempio.

Ipotizziamo infatti di avere un’automazione che ci notifichi (o faccia altro di importante) a fronte di un surriscaldamento della presa:

  - alias: "NOTIFICA - Surriscaldamenti"
    id: "notifica_surriscaldamenti"
    initial_state: true
    mode: single
    trigger:
      - platform: state
        entity_id: binary_sensor.surriscaldamento_presa
        from: 'off'
        to: 'on'
    condition: []
    action:
      - service: notify.mobile_app
        data:
          title: Domotica
          message: "{{ trigger.to_state.attributes.friendly_name }}: rilevato surriscaldamento dell'unità."
          data:
            push:
              badge: 1
              sound:
                name: default
                critical: 1
                volume: 1.0 

Tale automazione utilizza lo stato dell’entità binary_sensor.surriscaldamento_presa per notificarci la situazione di pericolo; per farlo, il trigger si innesca quando l’entità cambia il proprio stato da ‘off‘ a ‘on‘.

Il problema nasce dal fatto che l’unità potrebbe non inviare in tempo utile topic telemetrici di aggiornamento dello stato dopo un riavvio dei Home Assistant e, quando dovesse mandarne uno con stato “on” (presa surriscaldata!), l’automazione non scatterebbe, in quanto il cambio di stato non sarebbe da ‘off‘ a ‘on‘, ma da ‘unknown‘ a ‘on‘.

Certo, la soluzione è rapida: basta levare from: ‘off’ dal trigger dell’automazione, facendo in modo che essa scatti in qualsiasi caso ci sia un cambio di stato che porti quest’ultimo a ‘on’ (ottima pratica, in assoluto, su questo tipo di automazioni), ma il punto ovviamente non è questo: vi stiamo solo portando un esempio per farvi capire che gli stati “unknown“, a prescindere, andrebbero stanati ed evitati.

La soluzione

La soluzione è estremamente semplice da attuare: utilizzare la retain di MQTT. Sì:  il meccanismo della retain consente di far sì che il broker “tenga in pancia” l’ultima telemetria ricevuta per ognuno dei topic telemetrici (e non) che siano contrassegnati con retain attiva.

Questo, ovviamente, non vale solo per le telemetrie che riportano stati operativi, ma anche per esempio quelli “di disponibilità” del device, come gli “availability_topic“.

In pratica, facendo in modo che gli stati vengano inviati tramite topic con retain attiva, ogni qual volta Home Assistant dovesse ripartire, sarà il broker a comunicargli il set completo degli stati più recenti a sua conoscenza. Se non ne ha altri, è perché le unità non hanno comunicato “niente di nuovo”. 

Come farlo?

Beh: dipende. Per esempio, nel caso degli Shelly integrati via MQTT è necessario accedere al pannello di gestione delle singole unità e presso la sezione di configurazione “MQTT”, spuntare la voce Retain; su Zigbee2MQTT, selezionare i singoli componenti ZigBee che si vogliano mettere “sotto retain” e, alla voce “Impostazioni“, anche qui spuntare la voce Retain – e così via.

Ricordarsi, comunque, che è sempre “chi invia il topic da contrassegnare con la retain” a dover esser configurato in modo corretto, non Home Assistant il quale, da oggi, si comporterà come spiegato in questo breve approfondimento.

Il nostro consiglio, infine, è attivare la retain solo sui componenti e per le funzioni che, realisticamente, per le quali possa rappresentare “un problema”, lato Home Assistant, il fatto di non avere un stato aggiornato subito all’avvio dell’HUB.

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