O Home Assistant não tem um limite universal de utilizadores; um servidor pequeno suporta apenas as sessões simultâneas cujas cargas de trabalho reais se mantenham dentro dos objetivos definidos de latência e recuperação.
As contas nomeadas são económicas quando a maioria das pessoas está inativa, enquanto alguns painéis muito utilizados podem solicitar histórico, transmitir câmaras, processar cartões personalizados e consumir atualizações frequentes por WebSocket. O acesso remoto pode acrescentar limitações do proxy e do carregamento que os testes locais não revelam. Por isso, a capacidade deve ser expressa como carga de trabalho simultânea com um nível de serviço aceitável, e não como o número de pessoas guardadas no registo de utilizadores.
As Contas Registadas Não São Carga de Trabalho Simultânea
Uma conta acrescenta sobretudo identidade e permissões até alguém estabelecer ligação. Um telemóvel com sessão iniciada e uma ligação em segundo plano consome mais recursos do que uma conta inativa, e um painel de parede com muitas câmaras pode consumir mais do que vários utilizadores a abrir vistas simples de controlo.
Uma pergunta da comunidade sobre utilizadores simultâneos mostra que a carga de trabalho de utilizadores simultâneos não tem uma conversão documentada simples em CPU ou memória, porque o comportamento dos clientes varia muito.
Conte as sessões WebSocket ativas, as vistas do painel, as consultas ao histórico, as transmissões e as chamadas de serviço durante o mesmo intervalo. O total de utilizadores registados continua a ser útil para a administração, mas não para prever o desempenho.
O Design do Painel Altera o Custo por Utilizador
Um painel simples subscreve um conjunto limitado de entidades, enquanto gráficos, mapas, câmaras, cartões personalizados e modelos abrangentes acrescentam consultas ao servidor, transferência de rede e processamento no cliente. As atualizações frequentes de entidades multiplicam-se em todas as sessões subscritas.
As discussões sobre design para várias unidades e utilizadores expõem os problemas de isolamento e organização relacionados com o design de instâncias multiutilizador, e não apenas um número bruto de ligações.
Separe a segmentação do agregado familiar do desempenho. Uma instância pode servir tecnicamente vários grupos, mas ainda assim proporcionar limites inadequados de privacidade ou administração; aumentar a capacidade do hardware não resolve essa restrição de design.
O Cliente e a Rede Podem Falhar Antes do Servidor
Os processadores dos dispositivos móveis, a memória do navegador, a qualidade do Wi-Fi, a latência da VPN, a configuração do proxy e a largura de banda de carregamento da ligação doméstica podem dominar a velocidade percecionada. Um servidor pode responder prontamente enquanto um dispositivo demora segundos a processar uma vista complexa.
Um caso em que os painéis eram lentos no telemóvel, mas rápidos num computador, demonstra por que motivo o atraso do painel no lado do cliente deve ser medido separadamente da resposta do servidor.
Compare clientes locais e remotos com a mesma vista. Se os registos de data e hora do servidor permanecerem estáveis, mas o tempo de processamento divergir, aumentar a capacidade do servidor não elevará o número prático de utilizadores nesse percurso do cliente.
A Difusão de Eventos Cria o Limite de Saturação
Cada novo estado pode ser enviado para muitos clientes ligados, e cada vista pode desencadear trabalho adicional de modelos ou histórico. A CPU, a memória, a latência da base de dados e a largura de banda de saída podem, por isso, aumentar de forma não linear quando as sessões ocupadas se sobrepõem.
Uma investigação sobre spam de eventos WebSocket relaciona um painel lento com o volume de atualizações, ilustrando como a difusão de atualizações por WebSocket pode dominar mesmo quando o número de pessoas é reduzido.
Este é o limite de falha: o número de utilizadores não é a causa, a menos que a adição repetida de sessões idênticas aumente de forma correlacionada um recurso e a latência do serviço. Tempestades de integrações, cartões problemáticos e falhas de rede devem ser corrigidos antes de declarar que o servidor está cheio.
Encontre a Capacidade com um Teste de 2-4-8 Sessões
Crie um perfil de teste representativo e execute duas sessões simultâneas, depois quatro e, por fim, oito. Em cada etapa, repita o carregamento de um painel, uma consulta fixa ao histórico, uma chamada de serviço inofensiva e uma vista de câmara, registando a latência p95, a CPU, a memória, a fila de armazenamento e a largura de banda de saída.
A estrutura de teste de utilizadores simultâneos fornece uma estrutura de diagnóstico para utilizadores simultâneos, ajudando a definir as métricas e a condição de paragem para um servidor pequeno com Home Assistant.
Pare no primeiro nível que não cumpra o objetivo de latência do agregado familiar ou que apresente saturação sustentada; o nível anterior que passou é a capacidade testada para essa carga de trabalho, e não uma garantia universal. Repita o teste remotamente e durante a atividade normal das automatizações, reservando depois margem para cópias de segurança, atualizações e tempestades de reconexões.
Centro de Tecnologia e IA
Mais para Ler

As 10 melhores interfaces web de IA locais para laboratórios domésticos em 2026
Compare 10 interfaces Web de IA locais autoalojadas para laboratórios domésticos, abrangendo o suporte do Ollama, RAG, agentes, acesso multiutilizador, esforço de configuração e...

Quanto custa o GPT-6 Astra ao longo do tempo? Quando é que a IA na cloud faz sentido face à IA local
Um guia prático sobre os custos do GPT-6 Astra, que abrange a utilização de tokens, cargas de trabalho de IA de longa duração, as...

GPT-6 Astra vs. IA local: Que partes de um agente devem permanecer no seu servidor doméstico?
O GPT-6 Astra pode permanecer na nuvem, enquanto o seu servidor doméstico mantém localmente os ficheiros, a memória, o RAG, as ferramentas, as permissões...

