Como é que a latência da rede afeta o Home Assistant durante falhas de Internet?

A latência da rede afeta o Home Assistant durante uma interrupção da Internet apenas quando o pedido que falha ainda depende de um caminho de rede. Uma automação Zigbee local pode continuar rápida, enquanto uma integração na nuvem aguarda pelos tempos limite de DNS ou TCP; uma câmara na LAN pode ficar lenta porque o Wi-Fi está congestionado, mesmo que a interrupção do ISP não tenha relação.

A distinção fundamental é entre perda da WAN e atraso na rede local. A falha da Internet elimina a acessibilidade externa. A latência acrescenta espera a um caminho que ainda existe. Um design fiável do Home Assistant mantém o controlo crítico em caminhos locais curtos e impede que dependências remotas lentas se expandam para esses caminhos.

Os protocolos locais podem evitar a WAN, mas continuam dependentes da LAN

O tráfego dos dispositivos Zigbee e Z-Wave não precisa da Internet pública, mas o Home Assistant pode ainda ter de comunicar com um coordenador, broker, bridge ou serviço Thread/Z-Wave através de Ethernet ou Wi-Fi. Essa rede local pode desenvolver o seu próprio atraso.

Um guia recente sobre o Home Assistant com prioridade local salienta que o controlo independente da Internet continua dependente de a infraestrutura local permanecer ligada e acessível.

Teste o caminho entre o sensor e a ação com a WAN desligada, mas com a LAN intacta. Em seguida, introduza separadamente carga na LAN. Assim, evita atribuir a interrupção a um problema de Wi-Fi, switch, DNS ou bridge.

Os tempos limite de DNS podem acrescentar atraso sem consumir muita largura de banda

Uma consulta DNS falhada é pequena, mas o chamador pode aguardar pelas tentativas ou pelos tempos limite do resolvedor. As integrações na nuvem, as verificações de atualizações, as notificações ou as chamadas a APIs externas podem, por isso, passar segundos à espera, mesmo quando a rede local transporta quase nenhum tráfego.

Utilizadores do Home Assistant associaram falhas de automações a erros de tempo limite de DNS que surgem exatamente quando os pedidos externos falham. A lição útil é medir o tempo de resolução e o comportamento em caso de falha, em vez de analisar apenas a utilização da interface.

Mantenha os nomes de anfitrião internos resolvíveis durante uma falha da WAN quando esses nomes forem necessários para serviços locais. Não faça um broker MQTT ou uma base de dados local depender de um resolvedor externo se o verdadeiro responsável for um endereço local ou uma zona DNS local.

Os gateways de rádio ligados à rede acrescentam o seu próprio pequeno orçamento de latência

Um coordenador ligado através da LAN acrescenta atraso de transporte em comparação com um dispositivo USB direto, embora o atraso possa ser reduzido numa rede saudável. O efeito torna-se mais visível quando o Wi-Fi é fraco ou a rede está congestionada.

Os testes do Home Assistant com Z-Wave através de Wi-Fi/PoE concluíram que o transporte pela rede acrescentou um atraso mensurável em comparação com o USB direto e tornou-se mais variável através de Wi-Fi.

Isso não torna, por defeito, os rádios ligados à rede pouco fiáveis. Significa que o seu caminho pela LAN faz parte do orçamento temporal e deve ser medido separadamente da disponibilidade da WAN.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Os tempos limite da nuvem devem degradar funcionalidades opcionais, não o controlo local

Os dispositivos dependentes exclusivamente da nuvem, o estado do tempo, o controlo de voz remoto, o acesso remoto e as notificações externas podem falhar durante a interrupção. Uma automação local só fica sensível a essa falha quando aguarda um desses resultados remotos antes de emitir a ação física.

Uma arquitetura com prioridade local recomenda manter o DNS, a automação e os serviços críticos disponíveis localmente, permitindo que as funções opcionais da nuvem se degradem de forma independente.

Numa regra crítica, execute primeiro a ação local quando não for necessária confirmação remota. Trate a notificação ou a análise na nuvem como um ramo secundário que pode falhar sem atrasar a alteração do estado físico.

Meça a latência na etapa em que o utilizador fica à espera

O modelo de caminho de acesso remoto da ZimaSpace é uma continuação útil, pois separa a LAN privada das etapas do ISP, NAT, VPN e túnel, em vez de tratar a “rede” como um único componente.

Durante uma interrupção, o resultado mais saudável é uma degradação seletiva: o controlo local permanece dentro do seu intervalo normal de latência, enquanto as chamadas externas falham rapidamente ou são repetidas em segundo plano. Se tudo ficar lento ao mesmo tempo, investigue o DNS partilhado, o encaminhamento, o Wi-Fi, as integrações personalizadas e as chamadas de rede bloqueantes.