O que causa atrasos no controlo local no Home Assistant durante falhas de Internet?

O controlo local do Home Assistant atrasado durante uma falha de Internet normalmente significa que um percurso supostamente local continua à espera de uma dependência da WAN ou de trabalho acumulado.

Comece por separar a chegada do acionamento da conclusão da ação: se o sensor de movimento muda imediatamente, mas a luz acende mais tarde, o percurso do evento está ativo e o atraso encontra-se mais à frente na cadeia. Se a entidade-alvo fica indisponível, o problema está mais abaixo no percurso do dispositivo; trate a falha como uma variável controlada e identifique a primeira etapa cuja latência muda.

A causa principal costuma ser uma dependência oculta no percurso de controlo

Uma instalação do Home Assistant pode ser local ao nível do servidor, enquanto entidades individuais, resolução de nomes, notificações ou serviços auxiliares continuam a depender da Internet. O utilizador vê um único toque num botão, mas esse pedido pode atravessar um painel local, um resolvedor de nomes, o ciclo de eventos do Home Assistant, uma integração, uma API do fornecedor e, por fim, um dispositivo físico. Basta uma etapa dependente da WAN para atrasar toda a ação visível.

Um artigo sobre arquitetura local-first salienta o mesmo ponto ao distinguir o controlo essencial da casa das funções WAN opcionais; os percursos de controlo offline-first só permanecem fiáveis quando a cadeia entre o sensor e a ação se mantém dentro de casa. Notificações remotas, meteorologia e serviços dos fornecedores podem falhar separadamente sem bloquear a luz ou a fechadura.

Não comece por alterar a CPU, a base de dados ou as definições das automações. Primeiro, registe a hora do estado do sensor, do início da automação, de cada etapa da ação, da chamada ao serviço-alvo e da confirmação do estado do dispositivo. O primeiro intervalo que aumenta apenas quando a WAN está indisponível identifica a classe de dependência que merece investigação.

As quatro causas do atraso local relacionado com falhas

A divisão mais útil distingue entre uma ação lenta na nuvem, um nome ou percurso local que depende secretamente de infraestrutura WAN, uma integração de dispositivo mediada pela nuvem e uma fila criada por trabalho anteriormente falhado. Estas causas podem parecer idênticas no painel, porque todas terminam com um resultado local tardio.

Uma investigação da comunidade observou que o Home Assistant ficava lento quando as integrações na nuvem tinham ligações deficientes ou inexistentes, fornecendo um exemplo real de falhas da nuvem afetarem a capacidade de resposta. A observação é útil porque separa a presença do Core local do comportamento das integrações pelas quais o Core está à espera.

Use as assinaturas abaixo como hipóteses, não como diagnósticos definitivos. Reproduza a mesma ação local com a WAN ativa e desligada e, em seguida, remova apenas uma dependência suspeita de cada vez. Uma causa é confirmada quando a etapa alterada e o atraso visível para o utilizador mudam em conjunto, enquanto o restante percurso de controlo permanece constante.

Causa 1: uma ação na nuvem mantém a execução aberta

• Mecanismo: um acionamento local chega a uma ação dependente da nuvem que aguarda um tempo limite ou uma nova tentativa.
• Assinatura: os estados locais chegam a horas, mas o rastreio da automação fica bloqueado numa chamada remota.
• SE–ENTÃO: se remover essa chamada repuser o tempo de resposta durante a mesma falha, a etapa na nuvem atrasada é a causa.

Causa 2: a resolução do nome ou do percurso local também depende da WAN

• Mecanismo: os clientes ou as integrações utilizam DNS, proxy ou percursos de encaminhamento que fazem fallback para fora da LAN.
• Assinatura: o acesso direto pelo IP local é rápido, enquanto o nome de anfitrião habitual ou o percurso encaminhado pausa.
• SE–ENTÃO: se um nome e um percurso totalmente locais eliminarem o atraso, a lógica de controlo era local, mas o percurso de acesso não era.

Causa 3: um dispositivo local é, na realidade, mediado pela nuvem

• Mecanismo: a entidade apresentada no Home Assistant representa uma API do fornecedor, e não um ponto final direto na LAN ou por rádio.
• Assinatura: a automação é executada, mas a entidade-alvo fica indisponível ou só é atualizada depois de a Internet ser restabelecida.
• SE–ENTÃO: se Zigbee, Z-Wave, ESPHome ou outro alvo local continuar a responder enquanto este dispositivo não responde, a fronteira da integração é a causa.

Causa 4: o trabalho acumulado durante a falha atrasa execuções locais posteriores

• Mecanismo: trabalho colocado em fila ou executado em paralelo durante a falha consome os mesmos recursos da automação ou do anfitrião depois da primeira falha.
• Assinatura: as ações totalmente locais só ficam atrasadas depois de se acumularem várias tentativas remotas falhadas.
• SE–ENTÃO: se limpar ou impedir a acumulação repuser a latência local, o atraso secundário deve-se à fila, não ao protocolo local.

Distinguir a perda de Internet da perda da rede local

Uma falha de Internet não deve ser confundida com a perda do router, do ponto de acesso Wi-Fi, do switch Ethernet, do DNS local, do coordenador Zigbee ou do anfitrião do Home Assistant. Se a própria LAN estiver degradada, o controlo local pode falhar mesmo que o desenho não contenha qualquer dependência da nuvem. O teste de falha deve manter a infraestrutura local ligada e acessível, removendo apenas o percurso de Internet a montante.

Um guia recente sobre o Home Assistant local-first descreve exatamente esta separação e salienta que o controlo local é uma questão de desenho de dependências, e não apenas o facto de o Home Assistant funcionar em casa. Os rádios locais, as APIs da LAN, o DNS e o controlador também têm de sobreviver de forma independente da WAN.

Se o acesso direto pelo IP local, os dispositivos por rádio e os serviços locais continuarem rápidos, enquanto apenas o nome de anfitrião habitual fica lento, teste a resolução DNS e do proxy antes de alterar as automações. Se o próprio Home Assistant deixar de estar acessível a partir da LAN, o problema não é uma falha exclusivamente da Internet e deve ser investigado na camada da rede local ou do anfitrião.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Execute um teste de isolamento com quatro marcas temporais

Escolha uma automação simples com um sensor local e um atuador local. Um fluxo de depuração baseado em rastreios atual pode registar o acionamento, as condições, os dados da ação processados e o tempo de cada etapa; associe-lhe a confirmação observada do estado do dispositivo. Repita dez vezes com a Internet disponível e depois dez vezes com a WAN bloqueada, mantendo a LAN intacta, e compare a mediana e as execuções mais lentas, em vez de uma única experiência.

O ZimaSpace mostra como uma aplicação aparentemente rápida na LAN pode, ainda assim, pausar antes do percurso da aplicação, porque a latência do DNS pode ocorrer antes do início da ligação. O mesmo princípio de isolamento aplica-se aqui: cronometre cada etapa para que um atraso na resolução de nomes não seja confundido com um atraso na execução da automação.

Considere o desenho de controlo local validado quando a remoção da WAN não altera materialmente o intervalo entre o acionamento e o dispositivo local e as tarefas na nuvem falhadas não conseguem criar uma fila que bloqueie posteriormente o percurso local. Se uma marca temporal aumentar, corrija primeiro essa dependência. Não aumente a simultaneidade, não altere as bases de dados nem substitua o hardware até que as evidências temporais demonstrem que esses recursos estão realmente envolvidos.