Home Assistant har inget användbart universellt svar som ”20 användare” eller ”100 användare”. Ett inloggat konto som är inaktivt skapar en annan belastning än en väggmonterad surfplatta som renderar en komplex instrumentpanel, en telefon som öppnar Historik eller flera användare som tittar på kamerakort medan tusentals entiteter uppdateras.
Dimensionera för samtidig användning genom att mäta anslutna klienter och det arbete varje klient orsakar. Den praktiska gränsen går där dina representativa instrumentpaneler, WebSocket-uppdateringar, serveråtgärder och nätverksväg börjar överskrida den svarstid du anser vara acceptabel.
Räkna anslutna klienter, inte bara användarkonton
Att skapa 100 konton innebär inte 100 samtidiga sessioner. Omvänt kan en person ha en webbläsare, telefon, surfplatta och kiosk anslutna samtidigt.
Home Assistants WebSocket-integration kan visa sensor.connected_clients som det aktuella antalet anslutna WebSocket-klienter. Använd detta antal som en signal för samtidighet medan du återskapar belastningen.
Registrera antalet klienter tillsammans med serverns CPU-användning, minnesbelastning, nätverkstrafik och åtgärdernas svarstid. Ett anslutningsantal utan den bakomliggande belastningen är inget kapacitetsresultat.
Frontendkostnaden beror på tillståndsuppdateringar och instrumentpanelsarbete
Frontend skapar en WebSocket-anslutning och håller Home Assistants tillstånd synkroniserat med webbläsaren. Varje klient måste också rendera den instrumentpanel som öppnas, så klienthårdvara och anpassade kort kan bli begränsningar innan servern blir det.
Den aktuella frontendarkitekturen beskriver hur frontend tar emot kärntillstånd och ytterligare prenumerationer via WebSocket-API:t. En aktiv installation skapar därför kontinuerligt uppdateringsarbete efter den första sidinläsningen.
Testa den faktiska blandningen av instrumentpaneler som hushållet använder i stället för att öppna en tom testsida på varje klient.
Hög uppdateringsfrekvens för entiteter kan belasta klienterna innan användarantalet verkar stort
Ett system med tusentals sensorer som ändras ofta kan skicka betydligt mer frontendarbete än en större användargrupp som huvudsakligen visar statiska entiteter. Detta märks särskilt på äldre surfplattor och resurssnåla väggpaneler.
Ett Home Assistant-ärende dokumenterade ett fall där stora mängder entitetsuppdateringar överbelastade instrumentpanelsklienterna även när den synliga instrumentpanelen var enkel.
Det definierar inte någon universell tröskel, men visar varför ”användare” är fel som enda måttenhet. Mät uppdateringar per sekund och klienternas responsivitet tillsammans med anslutningsantalet.
Det finns inget publicerat maximum för hushållsskala att kopiera
Frågor från communityn om ovanligt stora installationer illustrerar osäkerheten. I en diskussion om ungefär 200 användare framkom inget tydligt maximalt antal som stöds, och den skalan betraktades som ett ovanligt användningsfall som bör testas i stället för att tas för given.
För ett vanligt hushåll innebär detta att du inte behöver jaga ett leverantörsaktigt maxantal sessioner. För en gemensam entré, en delad byggnad, ett labb eller annan installation med många användare kanske Home Assistant inte är rätt plattform för identitets- och åtkomsthantering, även om servern tekniskt kan upprätthålla anslutningarna.
ZimaSpaces metod för dimensionering utifrån samtidig belastning gäller även här: kapaciteten bör kopplas till den mest intensiva realistiska överlappningen, inte till det totala antalet registrerade konton.
Genomför ett stegtest tills ett mått upprepade gånger visar felet
| Steg | Mät | Stoppa när |
|---|---|---|
| Lägg till aktiva klienter i små grupper | Anslutna klienter | Representativ samtidighet har uppnåtts |
| Öppna riktiga instrumentpaneler | Första rendering och interaktionsfördröjning | Upprepad fördröjning som användaren märker |
| Generera normal entitetstrafik | WebSocket-/uppdateringsbelastning | Klienterna hinner inte med |
| Utför vanliga åtgärder | Fördröjning från serveråtgärd till enhet | Styrfördröjningen ökar märkbart |
| Upprepa vid toppbelastning | CPU, minne, nätverk och klientbelastning | Samma begränsande lager visar sig igen |
Välj en kapacitet ett steg under den första upprepningsbara felpunkten och lämna utrymme för säkerhetskopieringar, uppdateringar, kameratrafik och ovanliga belastningstoppar. Om bara en gammal surfplatta blir långsam medan serveråtgärderna fortfarande är snabba, kanske ett serverbyte inte ökar den användbara samtidigheten.
Vanliga frågor
Motsvarar 20 Home Assistant-användarkonton 20 samtidiga användare?
Nej. Konton är identiteter; samtidighet handlar om aktiva klientanslutningar och det arbete dessa klienter skapar. En användare kan ha flera klienter, medan många konton kan vara helt inaktiva.
Gör enklare instrumentpaneler att alltid fler användare kan ansluta?
De kan minska klienternas renderingsarbete, men serverkapaciteten beror också på entiteternas uppdateringsfrekvens, WebSocket-trafik, historikfrågor, kameror, nätverksväg och bakgrundstjänster. Mät hela belastningen.
Support och tips
Mer att läsa

Tecken på att en Home Assistant-databas behöver underhåll eller bytas ut
En stor Home Assistant-databas behöver vanligtvis underhåll av lagringstid eller rensning; återkommande korruption eller integritetsfel är starkare signaler på att den bör bytas ut.

Kan Home Assistant använda en extern databas utan att uppgraderingar slutar fungera?
En extern Recorder-databas kan överleva uppgraderingar, men medför eget ansvar för tillgänglighet, schemamigrering, säkerhetskopiering, återställning och versionshantering.

Så testar du om DNS orsakar anslutningsfel i Home Assistant
Bevisa ett DNS-fel i Home Assistant genom att testa samma värdnamn från den berörda sökvägen, jämföra nåbarhet via direkt IP-adress och kontrollera A-/AAAA-svar.

