Hoeveel gebruikers kan Home Assistant ondersteunen op een kleine thuisserver?

Home Assistant heeft geen universele gebruikerslimiet; een kleine server ondersteunt alleen het aantal gelijktijdige sessies waarvan de daadwerkelijke werklast binnen de vastgestelde doelwaarden voor latentie en herstel blijft.

Geregistreerde accounts kosten weinig wanneer de meeste mensen inactief zijn, terwijl enkele drukgebruikte dashboards geschiedenis kunnen opvragen, camera's kunnen streamen, aangepaste kaarten kunnen weergeven en regelmatig WebSocket-updates kunnen verbruiken. Externe toegang kan proxy- en uploadbeperkingen toevoegen die lokale tests niet aan het licht brengen. Capaciteit moet daarom worden uitgedrukt als gelijktijdige werklast bij een acceptabel serviceniveau, niet als het aantal mensen in het gebruikersregister.

Geregistreerde accounts zijn geen gelijktijdige werklast

Een account voegt voornamelijk identiteit en rechten toe totdat iemand verbinding maakt. Een ingelogde telefoon met een achtergrondverbinding kost meer dan een inactief account, en een wandpaneel met veel camerabeelden kan meer kosten dan meerdere gebruikers die eenvoudige bedieningsweergaven openen.

Een communityvraag over gelijktijdige gebruikers laat zien dat gelijktijdige gebruikerswerklast niet eenvoudig kan worden omgerekend naar CPU- of geheugengebruik, omdat het gedrag van clients sterk uiteenloopt.

Tel actieve WebSocket-sessies, dashboardweergaven, geschiedenisopvragingen, streams en serviceaanroepen binnen hetzelfde tijdsinterval. Het totale aantal geregistreerde gebruikers blijft nuttig voor beheer, maar niet voor het voorspellen van prestaties.

Dashboardontwerp verandert de kosten per gebruiker

Een eenvoudig dashboard abonneert zich op een beperkte set entiteiten, terwijl grafieken, kaarten, camera's, aangepaste kaarten en brede templates extra serverquery's, netwerkverkeer en rendering door de client veroorzaken. Regelmatige entiteitsupdates vermenigvuldigen zich over elke geabonneerde sessie.

Discussies over ontwerpen voor meerdere eenheden en gebruikers brengen de isolatie- en organisatieproblemen rond ontwerp van een multi-userinstantie aan het licht, en niet alleen een eenvoudig totaal van verbindingen.

Scheid de segmentatie van huishoudens van prestaties. Eén instantie kan technisch gezien meerdere groepen bedienen, maar toch ongeschikte privacy- of beheergrenzen bieden; krachtigere hardware lost die ontwerpbeperking niet op.

De client en het netwerk kunnen uitvallen voordat de server dat doet

Mobiele processors, browsergeheugen, wif kwaliteit, VPN-latentie, proxyconfiguratie en de uploadsnelheid van de thuisverbinding kunnen de ervaren snelheid overheersen. Een server kan snel antwoorden terwijl één apparaat enkele seconden nodig heeft om een complexe weergave te renderen.

Een geval waarin dashboards op een mobiel apparaat traag maar op een computer snel waren, laat zien waarom client-side dashboardvertraging afzonderlijk van de serverrespons moet worden gemeten.

Vergelijk lokale en externe clients met dezelfde weergave. Als de tijdstempels van de server stabiel blijven maar de rendertijd uiteenloopt, vergroot extra servercapaciteit het praktische aantal gebruikers voor dat clientpad niet.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Eventverspreiding bepaalt de verzadigingsgrens

Elke nieuwe status kan aan veel verbonden clients worden geleverd, en elke weergave kan extra template- of geschiedenisverwerking activeren. CPU, geheugen, databaselatentie en uitgaande bandbreedte kunnen daardoor niet-lineair toenemen wanneer drukke sessies elkaar overlappen.

Een onderzoek naar WebSocket-eventspam koppelt een traag dashboard aan het volume van updates en laat zien hoe verspreiding van WebSocket-updates de doorslag kan geven, zelfs wanneer het aantal mensen klein is.

Dit is de uitvalgrens: het aantal gebruikers is niet de oorzaak, tenzij het toevoegen van identieke sessies herhaaldelijk leidt tot een gecorreleerde stijging van een bepaalde systeemresource en de servicelatentie. Integratiepieken, slechte kaarten en netwerkstoringen moeten worden opgelost voordat je verklaart dat de server vol is.

Vind de capaciteit met een test voor 2-4-8 sessies

Maak één representatief testprofiel en voer eerst twee gelijktijdige sessies uit, daarna vier en vervolgens acht. Herhaal bij elke stap het laden van een dashboard, een vaste geschiedenisopvraging, een onschadelijke serviceaanroep en een camerabeeld, terwijl je p95-latentie, CPU, geheugen, opslagwachtrij en uitgaande bandbreedte registreert.

Het testkader voor gelijktijdige gebruikers biedt een diagnostisch kader voor gelijktijdige gebruikers en helpt bij het vaststellen van de meetwaarden en het stopcriterium voor een kleine Home Assistant-server.

Stop bij het eerste niveau waarop de doelstelling voor huishoudelijke latentie niet wordt gehaald of waarop aanhoudende verzadiging optreedt; het vorige niveau dat wel slaagde, is de geteste capaciteit voor die werklast en geen universele garantie. Herhaal de test op afstand en tijdens normale automatiseringsactiviteit en houd daarna ruimte over voor back-ups, updates en pieken door opnieuw verbinden.