Hur många användare kan Home Assistant stödja på en liten hemmaserver?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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.

-15% OFF
Single board computer zimaboard2

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.