Agendamento de recursos do Home Assistant: por que as falhas de Internet alteram o comportamento do controlo local

Uma falha de ligação à Internet não faz automaticamente falhar a automatização local do Home Assistant. As integrações locais Zigbee, Z-Wave, Matter, ESPHome, MQTT e LAN podem continuar a funcionar enquanto a WAN está indisponível. O que muda é a carga de trabalho envolvente: os pedidos para a cloud atingem o tempo limite, as integrações tentam novamente, as pesquisas DNS falham, as ligações remotas desaparecem e o trabalho de recuperação pode chegar em rajadas quando a conectividade regressa.

Por isso, o agendamento de recursos é importante durante uma falha, mesmo quando o caminho de controlo local permanece intacto. A questão não é “o Home Assistant precisa da Internet?”. É saber se o trabalho remoto falhado continua isolado ou começa a consumir tempo do ciclo de eventos, threads do executor, capacidade DNS, E/S de registos ou recarregamentos de integrações que se sobrepõem ao controlo local.

Os pedidos falhados para a cloud transformam caminhos rápidos de sucesso em caminhos sujeitos a timeouts

Quando a WAN está saudável, um pedido para a cloud pode ser concluído rapidamente. Durante uma falha, a mesma chamada pode ocupar a sua janela de timeout, ser repetida e registar um erro antes de regressar. Algumas chamadas são inofensivas; muitas integrações a fazer o mesmo em simultâneo criam um perfil de agendamento diferente do funcionamento normal.

O ciclo de vida das entradas de configuração do Home Assistant tem um estado explícito de setup retry para dependências que não estão prontas, aumentando ao longo do tempo o intervalo entre tentativas automáticas. O modo exato da falha continua a depender de cada integração, mas o trabalho de repetição é uma parte definida do funcionamento degradado, e não um caso excecional.

Impeça que as automatizações críticas aguardem uma API remota antes de emitir a ação local. Envie a notificação, a atualização na cloud ou o webhook externo depois da ação física, quando esse resultado remoto não for necessário para decidir o que a casa deve fazer.

Os timeouts de rede podem manter recursos ocupados mesmo sem utilização elevada do CPU

Uma operação de rede bloqueada pode apresentar pouca utilização do CPU e, ainda assim, ocupar uma tarefa, ligação, thread ou orçamento de timeout. É por isso que “o CPU está apenas a 10%” não prova que uma falha seja isenta de custos.

Um caso do Home Assistant em 2026 associou timeouts repetidos de uma integração e recarregamentos em cascata a um caminho IPv6 avariado que fazia as ligações aguardar em vez de falharem rapidamente. O sintoma era um atraso de agendamento associado às chamadas de rede, e não um esgotamento do poder de processamento.

Observe as tarefas de rede pendentes, os avisos das integrações, as falhas DNS e o tempo entre o acionamento e a chamada do serviço local. Se as ações locais continuarem rápidas enquanto as entidades na cloud ficam indisponíveis, a falha está corretamente isolada. Se a latência local aumentar com as chamadas remotas falhadas, identifique a integração ou o código personalizado que está a ocupar o ambiente de execução partilhado.

O trabalho bloqueante é mais perigoso do que a espera assíncrona

O núcleo do Home Assistant é assíncrono, pelo que as integrações bem implementadas podem suspender-se enquanto aguardam E/S e permitir que outras tarefas sejam executadas. O caso perigoso é o trabalho bloqueante que ocupa o próprio ciclo de eventos ou o código personalizado que executa operações de rede síncronas no local errado.

A documentação para programadores do Home Assistant explica que uma operação bloqueante no ciclo de eventos impede a execução de outro trabalho até ser concluída. Uma falha da Internet pode expor esta fragilidade, porque uma chamada que normalmente regressa de imediato pode subitamente aguardar um timeout prolongado.

É por isso que uma integração personalizada pode fazer com que uma falha pareça uma lentidão de toda a plataforma, mesmo quando as integrações locais nativas continuam bem concebidas. Compare o comportamento com os componentes personalizados desativados antes de culpar o hardware.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

A recuperação pode criar um segundo pico de carga de trabalho

Quando a conectividade à Internet regressa, várias integrações podem voltar a ligar-se, atualizar o estado, voltar a autenticar-se, atualizar entidades e escrever novo histórico quase ao mesmo tempo. Por isso, o período de recuperação pode ser mais movimentado do que o meio da falha.

Não interprete um pico de CPU, rede ou escritas do Recorder imediatamente após o regresso da WAN como prova de que a capacidade normal em regime estável é insuficiente. Meça a duração do pico e verifique se a latência do controlo local regressa aos valores de referência depois disso.

O artigo da ZimaSpace sobre mensagens retidas, em fila, de descoberta e de disponibilidade após a religação demonstra o mesmo princípio de recuperação: a religação de componentes distribuídos pode reproduzir estados e criar trabalho que não existia enquanto a ligação estava estável.

Agende para o modo degradado, não apenas para o modo normal

Durante uma perda da WAN, os caminhos locais de movimento para iluminação devem continuar a funcionar sem depender de um requisito remoto. A consulta periódica da cloud pode entrar num ciclo de tentativas limitado, as notificações remotas podem falhar ou ficar em fila, os serviços dependentes de DNS devem falhar de forma previsível e o regresso da conectividade pode criar um breve pico de atualização.

O objetivo de conceção é uma degradação seletiva: o trabalho remoto opcional fica mais lento ou desaparece, enquanto o controlo local se mantém dentro do seu intervalo de temporização normal. O teste mais exigente a uma falha consiste em desligar a WAN durante uma carga de trabalho doméstica normal, medir algumas automatizações locais críticas e, em seguida, voltar a ligar e medir tanto o pico de recuperação como o tempo necessário para regressar aos valores de referência.

Perguntas frequentes

Uma falha de Internet torna as automatizações locais do Home Assistant mais lentas?

Não necessariamente. Uma automatização totalmente local pode continuar à velocidade normal. Fica mais lenta quando o trabalho falhado da cloud, do DNS, de integrações personalizadas ou da rede partilhada consome recursos no mesmo caminho crítico.

Devo adicionar tentativas agressivas para que as integrações na cloud recuperem mais depressa?

Não. As tentativas agressivas podem amplificar uma falha e criar trabalho desnecessário. Prefira um comportamento de tentativas limitado e mantenha a recuperação da cloud fora do caminho de temporização das automatizações locais críticas.