In che modo Home Assistant coordina Zigbee2MQTT con il Core?
Home Assistant coordina Zigbee2MQTT tramite MQTT, invece di trattare Zigbee2MQTT come parte di Home Assistant Core. Zigbee2MQTT gestisce il coordinatore Zigbee e l'interazione con la rete mesh, un broker MQTT trasporta i messaggi e l'integrazione MQTT di Home Assistant trasforma i topic di discovery e di stato in entità utilizzabili dalle automazioni.
Questa separazione è potente perché il trasporto Zigbee, l'instradamento dei messaggi e la logica domotica possono essere riavviati o spostati indipendentemente. Crea però anche una catena di dipendenze composta da tre servizi: un dispositivo Zigbee può funzionare correttamente mentre Home Assistant lo mostra come non disponibile se Zigbee2MQTT, il broker, la discovery o i messaggi di disponibilità presentano problemi.
Zigbee2MQTT gestisce la comunicazione con i dispositivi dal lato radio
Zigbee2MQTT comunica con il coordinatore, mantiene le definizioni dei dispositivi Zigbee, riceve i report dalla rete mesh e li converte in messaggi MQTT. Home Assistant non deve accedere direttamente al coordinatore quando quest'ultimo è gestito da Zigbee2MQTT.
La guida all'integrazione di Zigbee2MQTT con Home Assistant spiega che la discovery MQTT è il metodo standard per creare automaticamente dispositivi ed entità Zigbee2MQTT in Home Assistant.
Questo confine di responsabilità è importante durante il ripristino. Il riavvio di Home Assistant non dovrebbe richiedere il nuovo abbinamento della rete mesh Zigbee e il riavvio di Zigbee2MQTT non dovrebbe cancellare le automazioni di Home Assistant che fanno riferimento a identità stabili delle entità.
Il broker MQTT è il confine dei messaggi tra i due servizi
Zigbee2MQTT pubblica lo stato dei dispositivi e le informazioni sul bridge nei topic MQTT. Home Assistant si iscrive ai topic pertinenti e pubblica i comandi quando un'automazione o un utente modifica un dispositivo.
Il broker MQTT è il confine dei messaggi perché Zigbee2MQTT pubblica i messaggi nei topic, mentre Home Assistant si iscrive ai topic necessari e pubblica i comandi attraverso lo stesso broker. Una guida aggiornata sull'architettura MQTT spiega come publisher e subscriber rimangano disaccoppiati mentre il broker instrada tra loro i messaggi basati sui topic.
Se il broker si arresta, la rete mesh Zigbee può continuare a esistere mentre la visualizzazione in Home Assistant smette di aggiornarsi. Diagnostica il broker separatamente dal coordinatore e da Core.
La discovery descrive le entità; i topic di stato le mantengono aggiornate
I messaggi di discovery indicano a Home Assistant quale entità deve esistere, quali topic forniscono lo stato e i comandi, a quale dispositivo appartiene e come interpretare i valori. Una volta creata, l'entità viene mantenuta aggiornata dai normali messaggi di stato.
Un ricaricamento o un riavvio può far emergere errori in questo punto. Un caso della community di Home Assistant documenta come le entità rilevate tramite MQTT possano rimanere non disponibili quando il percorso previsto di nuova discovery o di stato persistente non viene ricostruito correttamente.
Usa ID univoci stabili e una strategia deliberata per la nuova discovery. Ricreare le entità con nuove identità dopo ogni modifica al bridge danneggia dashboard, continuità dello storico e automazioni, anche se il dispositivo Zigbee fisico non è cambiato.
La disponibilità è un segnale distinto dallo stato del dispositivo
Uno stato come ON indica a Home Assistant l'ultimo valore segnalato; non dimostra che Zigbee2MQTT o il dispositivo siano attualmente raggiungibili. I topic di disponibilità forniscono un contratto separato di operatività.
La disponibilità in Zigbee2MQTT tratta in modo diverso i dispositivi alimentati dalla rete elettrica e quelli a batteria, perché i dispositivi passivi non possono essere interrogati su richiesta. La documentazione aggiornata specifica che i dispositivi attivi utilizzano finestre di controllo più brevi e una logica di ping e backoff, mentre quelli passivi si basano su finestre di controllo molto più lunghe. La disponibilità deve quindi essere interpretata separatamente dall'ultimo stato persistente.
Non attivare azioni critiche per la sicurezza basandoti su uno stato obsoleto senza considerare la disponibilità. Un valore persistente può essere utile per la ricostruzione, pur rappresentando un dispositivo attualmente offline.
L'ordine di avvio dovrebbe ricostruire il contratto, non dipendere dalla fortuna
La sequenza di avvio corretta non consiste semplicemente in «prima il broker, poi Zigbee2MQTT e infine Home Assistant». I servizi possono avviarsi in ordini diversi, quindi il contratto di messaggistica deve tollerare le riconnessioni. Zigbee2MQTT dovrebbe riconnettersi al broker, la discovery dovrebbe diventare disponibile, Home Assistant dovrebbe iscriversi e lo stato corrente dovrebbe essere ripubblicato o mantenuto come previsto.
Gli esempi di eventi per la casa intelligente di ZimaSpace mostrano come MQTT permetta ai servizi per la casa intelligente di scambiarsi eventi locali senza condividere lo stesso processo o lo stesso server fisico. Zigbee2MQTT è un esempio concreto di questo disaccoppiamento.
| Livello | Responsabilità principale | Segnale di errore |
|---|---|---|
| Zigbee2MQTT | Rete mesh Zigbee e traduzione dei dispositivi | Nessun nuovo messaggio Zigbee |
| Broker MQTT | Consegna dei messaggi tra i servizi | Il percorso di pubblicazione/sottoscrizione non funziona |
| MQTT di Home Assistant | Discovery delle entità e mappatura dello stato | Entità mancanti o non disponibili |
| Automazioni/Core | Regole e chiamate ai servizi | L'entità funziona, ma la logica dell'azione non funziona |
FAQ
Zigbee2MQTT richiede che Home Assistant rimanga attivo per mantenere in funzione la rete Zigbee?
No. Zigbee2MQTT gestisce la rete Zigbee dal lato del coordinatore. Home Assistant è un consumer e una sorgente di comandi tramite MQTT. Home Assistant può essere offline mentre il servizio Zigbee2MQTT e il broker rimangono in esecuzione.
Perché le entità Zigbee2MQTT diventano non disponibili dopo il riavvio del broker o di Home Assistant?
Di solito perché la discovery, lo stato persistente, la disponibilità o i messaggi di riconnessione non hanno ancora ricostruito completamente il contratto MQTT. Controlla lo stato del bridge Zigbee2MQTT, la connettività del broker, i topic di discovery e la disponibilità delle entità prima di associare nuovamente i dispositivi.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Perché Home Assistant offre prestazioni diverse sulla rete locale e con le connessioni remote?
Le sessioni di Home Assistant sulla LAN e da remoto utilizzano percorsi di rete diversi; la latenza da remoto aggiunge DNS, crittografia, WAN, proxy...
Home Assistant funziona in modo affidabile dietro CGNAT o doppio NAT?
CGNAT e doppio NAT di solito non influiscono sul controllo locale di Home Assistant; cambiano principalmente il modo in cui i client remoti possono...
In che modo la latenza di rete influisce su Home Assistant durante le interruzioni di Internet?
La perdita della connessione Internet e la latenza di rete sono problemi diversi: i percorsi dei dispositivi locali possono rimanere veloci mentre DNS, integrazioni...
