Quanti utenti può supportare Home Assistant su un piccolo server domestico?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How Many Users Can Home Assistant Support on a Small Home Server?

Home Assistant non ha un limite universale di utenti; un piccolo server supporta solo le sessioni simultanee i cui carichi di lavoro effettivi rimangono entro obiettivi definiti di latenza e ripristino.

Gli account nominativi sono poco costosi quando la maggior parte delle persone è inattiva, mentre alcuni dashboard molto utilizzati possono richiedere lo storico, trasmettere telecamere, eseguire il rendering di schede personalizzate e consumare aggiornamenti WebSocket frequenti. L’accesso remoto può aggiungere limiti del proxy e della velocità di upload che i test locali non rilevano. La capacità deve quindi essere espressa come carico di lavoro simultaneo a un livello di servizio accettabile, non come numero di persone registrate nel registro utenti.

Gli account registrati non equivalgono al carico di lavoro simultaneo

Un account aggiunge principalmente identità e autorizzazioni finché qualcuno non si connette. Un telefono connesso e autenticato, con una connessione in background, consuma più risorse di un account inattivo, mentre un pannello a parete ricco di telecamere può consumarne più di diversi utenti che aprono semplici viste di controllo.

Una domanda della community sugli utenti simultanei mostra che il carico di lavoro degli utenti simultanei non ha una semplice conversione documentata in CPU o memoria, perché il comportamento dei client varia notevolmente.

Conta le sessioni WebSocket attive, le viste del dashboard, le query dello storico, gli stream e le chiamate ai servizi durante lo stesso intervallo. Il totale degli utenti registrati resta utile per l’amministrazione, non per prevedere le prestazioni.

La progettazione del dashboard modifica il costo per utente

Un dashboard semplice si iscrive a un insieme limitato di entità, mentre grafici, mappe, telecamere, schede personalizzate e modelli estesi aggiungono query al server, trasferimento di rete e rendering sul client. Gli aggiornamenti frequenti delle entità si moltiplicano per ogni sessione iscritta.

Le discussioni sulla progettazione multi-unità e multiutente evidenziano i problemi di isolamento e organizzazione relativi alla progettazione di un’istanza multiutente, non semplicemente il numero totale di connessioni.

Separa la segmentazione del nucleo familiare dalle prestazioni. Un’istanza può tecnicamente servire diversi gruppi, ma offrire confini di privacy o amministrazione inadeguati; potenziare l’hardware non risolve questo vincolo progettuale.

Il client e la rete possono avere problemi prima del server

I processori dei dispositivi mobili, la memoria del browser, la qualità del Wi-Fi, la latenza della VPN, la configurazione del proxy e la larghezza di banda in upload della connessione domestica possono determinare in larga misura la velocità percepita. Un server può rispondere rapidamente mentre un dispositivo impiega secondi per eseguire il rendering di una vista complessa.

Un caso in cui i dashboard erano lenti su dispositivi mobili ma veloci su un computer dimostra perché il ritardo del dashboard lato client debba essere misurato separatamente dalla risposta del server.

Confronta i client locali e remoti usando la stessa vista. Se i timestamp del server rimangono stabili ma il tempo di rendering diverge, aumentare la capacità del server non aumenterà il numero pratico di utenti per quel percorso client.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

La distribuzione degli eventi crea il limite di saturazione

Ogni nuovo stato può essere inviato a molti client connessi e ogni vista può attivare ulteriore elaborazione di modelli o dello storico. CPU, memoria, latenza del database e larghezza di banda in uscita possono quindi aumentare in modo non lineare quando le sessioni impegnative si sovrappongono.

Un’indagine sullo spam di eventi WebSocket collega un dashboard lento al volume degli aggiornamenti, mostrando come la distribuzione degli aggiornamenti WebSocket possa predominare anche quando il numero di persone è ridotto.

Questo è il limite di funzionamento: il numero di utenti non è la causa, a meno che l’aggiunta ripetuta di sessioni identiche non aumenti in modo correlato una risorsa e la latenza del servizio. Picchi delle integrazioni, schede difettose e problemi di rete devono essere risolti prima di dichiarare che il server è al completo.

Trova la capacità con un test a 2, 4 e 8 sessioni

Crea un profilo di test rappresentativo ed esegui due sessioni simultanee, poi quattro e infine otto. A ogni passaggio ripeti il caricamento di un dashboard, una query dello storico predefinita, una chiamata innocua a un servizio e la visualizzazione di una telecamera, registrando la latenza p95, l’utilizzo della CPU, la memoria, la coda dello storage e la larghezza di banda in uscita.

Il framework di test per utenti simultanei fornisce un framework diagnostico per utenti simultanei, aiutando a definire le metriche e la condizione di arresto per un piccolo server Home Assistant.

Fermati al primo livello che non raggiunge l’obiettivo di latenza domestico o mostra una saturazione persistente; il livello precedente superato è la capacità testata per quel carico di lavoro, non una garanzia universale. Ripeti il test da remoto e durante la normale attività delle automazioni, quindi lascia margine per backup, aggiornamenti e picchi di riconnessioni.