Porque é que o Home Assistant tem um desempenho diferente em ligações LAN e remotas?

O Home Assistant pode parecer rápido na LAN e mais lento remotamente, mesmo quando o Core executa a mesma automatização, porque a ligação do cliente segue um caminho diferente. Um navegador local pode atravessar um switch para chegar ao Home Assistant; um telemóvel remoto pode resolver o DNS público, atravessar redes móveis ou de escritório, percorrer o caminho do ISP, entrar num proxy cloud, VPN, túnel ou proxy inverso e, depois, manter uma sessão WebSocket de volta ao servidor.

A diferença de desempenho deve, por isso, ser medida como entrega entre o cliente e o servidor, em vez de ser imediatamente atribuída à CPU do Home Assistant. Uma automatização física pode concluir-se localmente no mesmo tempo, enquanto o painel remoto demora mais a mostrar o novo estado.

O acesso pela LAN tem menos etapas de rede

Dentro de casa, um cliente pode usar o endereço privado do servidor ou um nome DNS interno e evitar a Internet pública. Os tempos de ida e volta são curtos e a ligação normalmente não é afetada pela capacidade de upload do ISP nem por um relay remoto.

O modelo de rede do Home Assistant Companion suporta caminhos de ligação internos e externos separados, incluindo URLs internas, URLs externas, DNS dividido e requisitos de proxy inverso compatível com WebSocket.

Uma sessão lenta na LAN deve, por isso, ser investigada primeiro dentro de casa: Wi-Fi, DNS, apresentação no navegador/cliente, proxy inverso utilizado internamente, encaminhamento entre VLANs ou o próprio equipamento anfitrião do Home Assistant.

O acesso remoto acrescenta DNS, WAN, encriptação e um método de entrada

Um cliente remoto precisa normalmente de um nome público ou sobreposto, TLS, uma rota externa e uma fronteira de acesso, como o Home Assistant Cloud, uma VPN, um proxy inverso ou um túnel. Cada etapa pode acrescentar latência ou um ponto de reconexão.

As redes sobrepostas remotas também podem utilizar diferentes tipos de ligação. As orientações atuais da Tailscale explicam que as ligações diretas entre pares normalmente proporcionam a menor latência e o maior débito, enquanto as ligações através de relay são uma alternativa quando a conectividade direta não é possível. A própria rota pode, por isso, alterar a capacidade de resposta percebida do Home Assistant sem alterar o tempo de execução do Core.

Não adote um limiar universal para a latência remota. Meça a sua própria rota a partir dos locais onde realmente utiliza o serviço — rede móvel, Wi-Fi do escritório, redes durante viagens ou uma segunda casa — e registe se o caminho é direto ou utiliza relay.

A estabilidade do WebSocket é importante depois de a página inicial carregar

Os painéis do Home Assistant recebem alterações contínuas de estado depois de carregarem o HTML e o JavaScript iniciais. Uma ligação que cai e se restabelece repetidamente pode parecer muito pior do que a sua largura de banda média sugere.

Um proxy inverso ou túnel tem de preservar corretamente o caminho do WebSocket. As orientações de rede do Companion alertam para que os proxies inversos geridos pelo próprio utilizador precisam de suporte para WebSocket; caso contrário, a interface pode estabelecer ligação parcialmente, enquanto as atualizações em tempo real funcionam mal.

Observe as reconexões, as atualizações WebSocket falhadas, os registos do proxy e as transições da rede móvel. Um telemóvel que muda de Wi-Fi para LTE pode alterar o endereço de origem e a rota, mesmo quando o próprio servidor do Home Assistant continua saudável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

O desempenho remoto pode ser limitado pelo upload de casa

Os planos de Internet doméstica são frequentemente assimétricos. Um pedido do painel remoto viaja até casa, mas as miniaturas das câmaras, os recursos do painel, as cargas úteis de estado e as transmissões têm de sair através da capacidade de upload da ligação doméstica.

Vídeos de câmaras com elevada taxa de bits ou vários utilizadores remotos podem expor limites de upload que nenhum cliente local deteta. Uma sessão remota lenta apenas quando é aberto um cartão de câmara é um problema diferente de uma automatização que demora demasiado tempo a executar.

O guia de cargas de trabalho de servidores domésticos para casas inteligentes da ZimaSpace faz a mesma distinção entre a automatização principal e as câmaras, a análise e os serviços complementares mais exigentes, que acrescentam requisitos de recursos separados.

A seleção do caminho do cliente pode fazer com que dois telemóveis se comportem de forma diferente

A aplicação Companion escolhe as definições de ligação com base na rede doméstica e nos URLs configurados do Home Assistant. Um dispositivo que nunca reconhece a rede doméstica pode continuar a utilizar a rota externa, mesmo quando está ligado ao mesmo Wi-Fi que o Home Assistant.

Um caso de suporte da comunidade mostra esta dependência prática: a aplicação precisa do URL externo correto e da definição da rede doméstica antes de o URL interno se tornar o caminho local pretendido.

Ao investigar o desempenho, compare o URL exato, a resposta DNS, o caminho do proxy/VPN, o painel e o cliente. “O mesmo servidor Home Assistant” não constitui o mesmo teste se os dois clientes utilizarem rotas de entrada diferentes.

Meça a execução do servidor separadamente da entrega ao cliente

Chame ao servidor “mais lento remotamente” apenas quando a própria execução no lado do servidor mudar. Se o dispositivo físico responder a tempo, mas o ecrã remoto for atualizado mais tarde, a diferença de desempenho ocorre depois do Core, no caminho de entrega remota.

Perguntas frequentes

Porque é que a aplicação Home Assistant é rápida por Wi-Fi, mas lenta através de dados móveis?

Os dados móveis acrescentam a rota de acesso remoto pública ou privada, incluindo a latência do ISP, DNS, TLS e, possivelmente, um proxy, VPN, túnel ou relay. O servidor do Home Assistant pode estar a executar à mesma velocidade.