Så optimerar du Home Assistant för styrning av hela hemmet på en liten server

Eva Wong

IceWhale author

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.

How to Tune Home Assistant for Whole-Home Control on a Small Server - Zima Store Online

En liten server kan köra tillförlitlig Home Assistant-styrning i hela hemmet när den latenskänsliga delen hålls enkel och bakgrundsarbete hindras från att överbelasta samma CPU-, minnes-, lagrings- eller nätverksresurser. Målet är inte att maximera antalet instrumentpanelsfunktioner eller hur länge historik sparas, utan att bevara förutsägbara tider från sensor till åtgärd under hushållets mest belastade normala förhållanden.

Börja med en representativ lokal automatisering och mät den medan systemet är obelastat. Lägg sedan till Recorder-aktivitet, instrumentpaneler, säkerhetskopior, kamera- eller mediearbete och andra containrar, en i taget. Justera den arbetsbelastning som förändrar styrningens latens i stället för att tillämpa generiska ”prestandainställningar” på varje komponent.

Skydda den aktiva styrningsvägen innan du optimerar historiken

Kartlägg en kritisk automatisering från utlösare till åtgärd: enhetshändelse, Home Assistants statusuppdatering, utvärdering av automatiseringen, tjänsteanrop och enhetens svar. Den vägen bör vara lokal där det är möjligt och ska inte vara beroende av en historikfråga från en instrumentpanel eller en molntjänst som saknar samband med den fysiska åtgärden.

Om rörelsestyrd belysning är snabb medan historikdiagrammen är långsamma, håll isär de två problemen. Om båda blir långsamma vid intensiva skrivningar eller under ett annat containerjobb är den delade värden eller lagringsvägen den troligare orsaken.

Diskussionen på ZimaSpace om att hålla vägen från sensor till åtgärd lokal ger rätt utgångspunkt: tillförlitlig styrning i hela hemmet bevisas av den väg som måste fungera när valfria tjänster försvinner.

Minska Recorder-arbete som inte ger hushållet något värde

Recorder kan generera kontinuerliga databasskrivningar från entiteter som ändras snabbt, utförliga attribut och händelser som ingen senare tittar på. Mer data innebär inte automatiskt mer användbar historik.

I ett aktuellt Home Assistant Recorder-fall minskade databastillväxten från ungefär 160 MB per dag till under 50 MB genom att utesluta störande entiteter och begränsa den sparade historiken. Den viktiga lärdomen är inte att varje installation ska kopiera dessa undantag, utan att skrivvolymen bör spegla den information hushållet faktiskt använder.

Identifiera sensorer med hög uppdateringsfrekvens, stora attribut, diagnostiska entiteter och integrationer som skapar onödiga statusförändringar. Ta endast bort data som du inte behöver för automatiseringar, historik, statistik eller felsökning och jämför sedan databastillväxt och styrningslatens innan du gör nästa ändring.

Förhindra att databaslatens blir ett problem på den delade värden

Små Home Assistant-värdar har ofta gott om CPU-kapacitet medan de väntar på lagringen. Databasskrivningar, historikfrågor, säkerhetskopior, uppdateringar och andra containrar kan dela på samma SSD- eller flashenhet och skapa köbildning som inte syns i ett genomsnittligt CPU-diagram.

En fristående guide till Home Assistant-databaser konstaterar att ett byte av databasmotor inte är en universell prestandalösning. Mät först lagringens tjänstetid och databasens beteende och avgör sedan om snabbare lagring, färre registrerade entiteter eller en annan databastopologi löser den faktiska väntetiden.

Förvara applikationstillstånd på tillförlitlig lagring med låg latens. Placera stora medier, kameraarkiv eller säkerhetskopior någon annanstans när de skapar ihållande sekventiell trafik som konkurrerar med databasen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Förlägg tungt bakgrundsarbete utanför styrningens belastningstopp

Säkerhetskopior, databasunderhåll, kameraindexering, mediesökningar, paketuppdateringar och lokala AI-jobb kan skapa korta perioder med CPU-, lagrings- eller minnesbelastning som inte syns i en skärmbild från viloläge. Flytta flexibelt batcharbete till en lugnare period innan du köper mer maskinvara.

Anta inte att midnatt alltid är lugnt. Ett stort antal sensorer, uppvärmningsscheman, energijobb eller Recorder-underhåll kan redan köras på natten. Jämför den faktiska tidslinjen för händelser och resurser innan du lägger ytterligare en schemalagd uppgift i samma tidsfönster.

Om ett bakgrundsjobb orsakar fördröjningar i automatiseringarna endast medan det körs, begränsar eller schemalägg om jobbet. Om styrningsvägen fortfarande är långsam när jobbet har avslutats, fortsätt felsökningen till den kvarstående resurs som inte återhämtade sig.

Håll samlokaliserade tjänster inom en uppmätt budget

Home Assistant placeras ofta tillsammans med MQTT, Zigbee2MQTT, Pi-hole, Node-RED, kameraprogramvara, medieservrar eller säkerhetskopieringsverktyg. Dessa tjänster är inte ”gratis” bara för att värden för det mesta är obelastad.

Kör din vanliga lokala automatisering medan den tyngsta förväntade kompletterande arbetsbelastningen är aktiv. Bevaka CPU-mättnad, tillgängligt minne, växlingsutrymme, lagringslatens och nätverksbeteende tillsammans. Den första resurs vars belastning följer styrningsfördröjningen är den komponent du bör justera.

På en mycket liten server kan det vara enklare att separera en tung tjänst än att uppgradera varje komponent. En aktuell storleksguide för hemlabb från ZimaSpace rekommenderar att gå över till mer maskinvara först när den faktiska container-, medie-, indexerings- eller VM-arbetsbelastningen upprepade gånger behöver det extra utrymmet.

När värden är delad bör du övervaka belastning snarare än procenttal i viloläge. Linux tryckmodell skiljer tillgänglig beräkningskapacitet från arbete som faktiskt väntar, vilket är den skillnad som spelar roll när Home Assistant måste förbli responsivt bredvid batchtjänster.

Sluta justera när belastningsfönstret har passerat

Observerat symtom	Mest användbara nästa test	Undvik
Långsam historik, snabb enhetsstyrning	Recorder-/databasvägen	Att byta CPU först
Styrningen är långsam endast under säkerhetskopiering	Överlappning mellan lagring och CPU	Att ändra automatiseringslogiken
Endast en integration är fördröjd	Integrations-, enhets- eller nätverksvägen	Globala Recorder-ändringar
Värden börjar använda växlingsutrymme under normal toppbelastning	Arbetsmängden i minnet	Att lägga till fler instrumentpaneler i testet
Allt fungerar under normal överlappning	Sluta	Att optimera för benchmarkresultat

En väljusterad liten Home Assistant-server är inte den maskin som har lägst CPU-användning i viloläge. Det är den maskin vars viktiga automatiseringar förblir förutsägbara medan Recorder, instrumentpaneler, säkerhetskopior och vanliga kompletterande tjänster utför sitt normala arbete.