O Home Assistant coordena o Zigbee2MQTT através do MQTT, em vez de tratar o Zigbee2MQTT como parte do Home Assistant Core. O Zigbee2MQTT gere o coordenador Zigbee e a interação com a rede mesh, um broker MQTT transporta as mensagens e a integração MQTT do Home Assistant transforma os tópicos de descoberta e de estado em entidades que as automações podem utilizar.
Esta separação é poderosa porque o transporte Zigbee, o encaminhamento de mensagens e a lógica de domótica podem ser reiniciados ou movidos de forma independente. Também cria uma cadeia de dependências composta por três serviços: um dispositivo Zigbee pode estar a funcionar corretamente enquanto o Home Assistant o apresenta como indisponível se o Zigbee2MQTT, o broker, a descoberta ou as mensagens de disponibilidade estiverem com problemas.
O Zigbee2MQTT Gere a Comunicação do Dispositivo no Lado Rádio
O Zigbee2MQTT comunica com o coordenador, mantém as definições dos dispositivos Zigbee, recebe relatórios da rede mesh e converte-os em mensagens MQTT. O Home Assistant não precisa de ter acesso direto a esse coordenador quando este é gerido pelo Zigbee2MQTT.
O guia de integração do Zigbee2MQTT com o Home Assistant explica que a descoberta MQTT é o método padrão para criar automaticamente dispositivos e entidades Zigbee2MQTT no Home Assistant.
Esta fronteira de responsabilidade é importante durante a recuperação. Reiniciar o Home Assistant não deve exigir a reparação da rede mesh Zigbee, e reiniciar o Zigbee2MQTT não deve apagar as automações do Home Assistant que fazem referência a identificadores de entidade estáveis.
O Broker MQTT É a Fronteira de Mensagens Entre os Dois Serviços
O Zigbee2MQTT publica o estado dos dispositivos e as informações da bridge em tópicos MQTT. O Home Assistant subscreve os tópicos relevantes e publica comandos de volta quando uma automação ou um utilizador altera um dispositivo.
O broker MQTT é a fronteira de mensagens porque o Zigbee2MQTT publica mensagens em tópicos, enquanto o Home Assistant subscreve os tópicos de que necessita e publica comandos de volta através do mesmo broker. Um guia atual sobre a arquitetura MQTT explica como os publicadores e subscritores permanecem desacoplados enquanto o broker encaminha entre eles mensagens baseadas em tópicos.
Se o broker falhar, a rede mesh Zigbee pode continuar a existir enquanto a vista do Home Assistant deixa de ser atualizada. Diagnostique o broker separadamente do coordenador e do Core.
A Descoberta Descreve as Entidades; os Tópicos de Estado Mantêm-nas Atualizadas
As mensagens de descoberta indicam ao Home Assistant que entidade deve existir, que tópicos fornecem o estado e os comandos, a que dispositivo pertence e como os valores devem ser interpretados. Depois de a entidade existir, as mensagens de estado normais mantêm-na atualizada.
Um recarregamento ou reinício pode revelar problemas nesta área. Um caso da comunidade do Home Assistant documenta como as entidades descobertas através de MQTT podem permanecer indisponíveis quando o processo esperado de redescoberta ou de estado retido não é reconstruído corretamente.
Utilize identificadores únicos estáveis e uma estratégia de redescoberta definida de forma deliberada. Recriar entidades com novos identificadores após cada alteração da bridge quebra os painéis, a continuidade do histórico e as automações, mesmo que o dispositivo Zigbee físico não tenha sofrido alterações.
A Disponibilidade É um Sinal Separado do Estado do Dispositivo
Um estado como ON indica ao Home Assistant o último valor comunicado; não prova que o Zigbee2MQTT ou o dispositivo estejam atualmente acessíveis. Os tópicos de disponibilidade fornecem um contrato de atividade separado.
A disponibilidade do Zigbee2MQTT trata de forma diferente os dispositivos alimentados pela rede elétrica e os dispositivos a bateria, porque os dispositivos passivos não podem ser consultados a pedido. A documentação atual especifica que os dispositivos ativos utilizam janelas de verificação mais curtas e lógica de ping/backoff, enquanto os dispositivos passivos dependem de janelas de verificação muito mais longas. Por isso, a disponibilidade deve ser interpretada separadamente do último estado retido.
Não desencadeie ações críticas para a segurança com base num estado obsoleto sem considerar a disponibilidade. Um valor retido pode ser útil para a reconstrução e, ainda assim, representar um dispositivo que está atualmente offline.
A Ordem de Arranque Deve Reconstruir o Contrato, Não Depender da Sorte
A sequência de arranque correta não é simplesmente “primeiro o broker, depois o Zigbee2MQTT e, por fim, o Home Assistant”. Os serviços podem arrancar por ordens diferentes, pelo que o contrato de mensagens deve tolerar reconexões. O Zigbee2MQTT deve voltar a ligar-se ao broker, a descoberta deve ficar disponível, o Home Assistant deve subscrever os tópicos e o estado atual deve ser republicado ou retido conforme definido.
Os exemplos de eventos de casas inteligentes da ZimaSpace mostram como o MQTT permite que os serviços de casas inteligentes troquem eventos locais sem partilharem o mesmo processo ou o mesmo servidor físico. O Zigbee2MQTT é um exemplo concreto desse desacoplamento.
| Camada | Responsabilidade principal | Sintoma de falha |
|---|---|---|
| Zigbee2MQTT | Rede mesh Zigbee e tradução dos dispositivos | Não chegam mensagens Zigbee recentes |
| Broker MQTT | Entrega de mensagens entre serviços | O caminho de publicação/subscrição falha |
| MQTT do Home Assistant | Descoberta de entidades e mapeamento do estado | Entidades em falta/indisponíveis |
| Automação/Core | Regras e chamadas de serviço | A entidade está operacional, mas a lógica da ação falha |
FAQ
O Zigbee2MQTT precisa que o Home Assistant se mantenha ativo para manter a rede Zigbee?
Não. O Zigbee2MQTT gere a rede Zigbee do lado do coordenador. O Home Assistant é um consumidor e uma fonte de comandos através do MQTT. O Home Assistant pode estar offline enquanto o serviço Zigbee2MQTT e o broker continuam em execução.
Porque é que as entidades do Zigbee2MQTT ficam indisponíveis depois de reiniciar o broker ou o Home Assistant?
Normalmente, porque a descoberta, o estado retido, a disponibilidade ou as mensagens de reconexão ainda não reconstruíram todo o contrato MQTT. Verifique o estado da bridge do Zigbee2MQTT, a conectividade do broker, os tópicos de descoberta e a disponibilidade das entidades antes de voltar a emparelhar os dispositivos.
Centro de Tecnologia e IA
Mais para Ler

Um gateway de IA local pode impor um limite rígido de contexto antes da alocação da GPU?
Uma explicação do mecanismo do gate de contexto rígido, das suas cedências em termos de recursos partilhados, de três perguntas frequentes sobre a expansão...

Um servidor de IA doméstico pode mapear pesos de modelos na memória a partir de um NAS remoto através de 2.5GbE?
Uma explicação baseada primeiro no mecanismo do mapeamento de memória do modelo NAS remoto, das suas contrapartidas em termos de recursos partilhados, três perguntas...

Vários contentores podem partilhar uma GPU integrada sem expor cargas de trabalho?
Uma explicação baseada primeiro no mecanismo do isolamento de contentores com iGPU partilhada, das suas contrapartidas em termos de recursos partilhados, três perguntas frequentes...

