Home Assistant har ingen universell användargräns; en liten server stöder endast de samtidiga sessioner vars faktiska arbetsbelastning håller sig inom definierade mål för svarstid och återhämtning.
Namngivna konton är billiga när de flesta personer är inaktiva, medan några få aktiva instrumentpaneler kan begära historik, strömma kameror, återge anpassade kort och förbruka frekventa WebSocket-uppdateringar. Fjärråtkomst kan dessutom medföra begränsningar för proxy och uppladdning som lokala tester inte upptäcker. Kapacitet måste därför uttryckas som samtidig arbetsbelastning vid en acceptabel servicenivå, inte som antalet personer som finns lagrade i användarregistret.
Registrerade konton är inte samma sak som samtidig arbetsbelastning
Ett konto lägger huvudsakligen till identitet och behörigheter tills någon ansluter. En inloggad telefon med en bakgrundsanslutning kostar mer än ett vilande konto, och en väggpanel med många kameror kan kosta mer än flera användare som öppnar enkla kontrollvyer.
En communityfråga om samtidiga användare visar att samtidig användarbelastning inte har någon enkel dokumenterad omvandling till CPU eller minne, eftersom klientbeteendet varierar kraftigt.
Räkna aktiva WebSocket-sessioner, instrumentpanelvyer, historikfrågor, strömmar och tjänsteanrop under samma intervall. Det totala antalet registrerade användare är fortfarande användbart för administration, men inte för att förutsäga prestanda.
Instrumentpanelens utformning ändrar kostnaden per användare
En enkel instrumentpanel prenumererar på en begränsad uppsättning entiteter, medan diagram, kartor, kameror, anpassade kort och breda mallar lägger till serverfrågor, nätverksöverföring och rendering på klienten. Frekventa entitetsuppdateringar multipliceras för varje prenumererande session.
Diskussioner om utformning för flera enheter och användare belyser isolerings- och organisationsproblemen kring utformning av instanser för flera användare, inte bara ett rått antal anslutningar.
Håll isär hushållssegmentering och prestanda. En instans kan tekniskt sett betjäna flera grupper men ändå ge olämpliga gränser för integritet eller administration; kraftfullare hårdvara löser inte den designbegränsningen.
Klienten och nätverket kan fallera före servern
Mobila processorer, webbläsarminne, Wi-Fi-kvalitet, VPN-latens, proxykonfiguration och hemmets uppladdningsbandbredd kan dominera den upplevda hastigheten. En server kan svara snabbt medan en enhet behöver flera sekunder för att återge en komplex vy.
Ett fall där instrumentpaneler var långsamma på mobilen men snabba på en dator visar varför fördröjning i instrumentpanelen på klientsidan måste mätas separat från serversvaret.
Jämför lokala och fjärranslutna klienter med samma vy. Om serverns tidsstämplar förblir stabila men renderingstiden skiljer sig åt, kommer ökad serverkapacitet inte att höja det praktiska användarantalet för den klientvägen.
Händelsespridning skapar mättnadsgränsen
Varje nytt tillstånd kan levereras till många anslutna klienter, och varje vy kan utlösa ytterligare mall- eller historikarbete. CPU, minne, databaslatens och utgående bandbredd kan därför öka icke-linjärt när aktiva sessioner överlappar varandra.
En undersökning av WebSocket-händelsespam kopplar en trög instrumentpanel till mängden uppdateringar och visar hur spridning av WebSocket-uppdateringar kan dominera även när antalet personer är litet.
Detta är gränsen där fel uppstår: användarantalet är inte orsaken om inte tillägg av identiska sessioner upprepade gånger höjer en korrelerad resurs och tjänstelatens. Integrationsstormar, felaktiga kort och nätverksfel måste åtgärdas innan servern förklaras full.
Hitta kapaciteten med ett test av 2–4–8 sessioner
Skapa en representativ testprofil och kör två samtidiga sessioner, sedan fyra och därefter åtta. Upprepa vid varje steg en inläsning av instrumentpanelen, en fast historikfråga, ett ofarligt tjänsteanrop och en kameravy, medan du registrerar p95-latens, CPU, minne, lagringskö och utgående bandbredd.
Testmetoden för samtidiga användare tillhandahåller ett diagnostiskt ramverk för samtidiga användare som hjälper till att definiera mätvärden och stoppvillkor för en liten Home Assistant-server.
Avsluta vid den första nivån som missar hushållets mål för svarstid eller visar ihållande mättnad; den föregående godkända nivån är den testade kapaciteten för den arbetsbelastningen, inte ett universellt löfte. Upprepa testet på distans och under normal automationsaktivitet, och reservera sedan marginal för säkerhetskopior, uppdateringar och stormar av återanslutningar.
Teknik- och AI-hubb
Mer att läsa

Topp 10 lokala AI-webbgränssnitt för hemmalabb 2026
Jämför 10 lokalt driftade webbgränssnitt för AI för hemlabb, med fokus på stöd för Ollama, RAG, agenter, åtkomst för flera användare, installationsinsats och idealiska...

Hur mycket kostar GPT-6 Astra över tid? När moln-AI är ett bättre val än lokal AI
En praktisk kostnadsguide för GPT-6 Astra som omfattar tokenanvändning, långvariga AI-arbetsbelastningar, avvägningar mellan moln och lokalt samt varför hybrid AI-infrastruktur är viktig.

GPT-6 Astra kontra lokal AI: Vilka delar av en agent bör köras på din hemmaserver?
GPT-6 Astra kan stanna i molnet medan din hemserver håller filer, minne, RAG, verktyg, behörigheter och beständigt agenttillstånd lokalt.

