Så konfigurerar du hälsokontroller för Home Assistant och dess beroenden

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 Configure Health Checks for Home Assistant and Its Dependencies

Konfigurera hälsokontroller i lager: verifiera först Home Assistant-applikationens svar och testa sedan databasen, MQTT, DNS, lagring och fjärrsökvägen endast där varje beroende faktiskt behövs.

En container som är markerad som körande kan fortfarande hålla på att starta, vara blockerad av lagring, vara frånkopplad från sin broker eller inte kunna skriva historik. Börja med en billig lokal beredskapskontroll, lägg till separata beroendekontroller med tydliga namn, tillåt tillräckligt med startmarginal och skicka aviseringar innan du aktiverar återställningsautomatisering. Varje kontroll bör ange vad som misslyckades och vad ett godkänt resultat bevisar.

Definiera ett friskt beteende innan du skriver en kontroll

Lista de funktioner som måste fungera för ditt hushåll: det lokala gränssnittet svarar, automatiseringar körs, Recorder kan skriva, MQTT-enheter utbyter tillstånd, DNS slår upp nödvändiga namn och monterad lagring är skrivbar. En enda grön status kan inte bevisa alla dessa funktioner.

En praktisk guide till Docker-hälsokontroller skiljer applikationshälsa från att en process helt enkelt existerar och förklarar att en kontroll körs inuti containern och rapporterar lyckat eller misslyckat resultat. Använd denna skillnad på applikationsnivå när du definierar vad din Home Assistant-kontroll måste observera.

Tilldela varje kontroll en ansvarig och en betydelse vid fel. Core-kontrollen ska inte låtsas validera databasen, och en MQTT-kontroll av socketanslutningen ska inte hävda att enheternas meddelanden är aktuella. Om ett resultat inte kan leda till en specifik nästa åtgärd bör du förenkla eller ta bort kontrollen.

Lägg till en lättviktig beredskapskontroll för Home Assistant

Använd en lokal slutpunkt eller ett kommando som slutförs snabbt och bevisar att applikationen svarar, inte bara att Python-processen existerar. Ange en timeout som är kortare än intervallet, ett rimligt antal omförsök och en startmarginal som är tillräckligt lång för din uppmätta kallstart.

Compose-hälsokontroller har normalt inställningar för intervall, timeout, omförsök och startperiod, medan beroendevillkor kan fördröja en konsument tills ett krav är friskt. Det viktiga operativa beteendet är beredskap i stället för körstatus, inte ett aggressivt avfrågningsschema.

Starta Home Assistant från kall lagring och notera när kontrollen lyckas första gången. Om den misslyckas under varje normal uppstart bör du öka startmarginalen i stället för att försvaga testet. Om den lyckas innan gränssnittet eller den nödvändiga tjänsten går att använda är kontrollen för ytlig och behöver ett mer representativt svar.

Kontrollera beroenden separat och bevara felens betydelse

Skapa oberoende kontroller för databasanslutningen, MQTT-brokern, DNS-upplösningen och den nödvändiga lagringsmonteringen. Föredra en skrivskyddad fråga eller en liten återställningsbar skrivning till en särskild testplats. Ändra aldrig Home Assistant-tabeller eller publicera kommandon till riktiga enheter enbart för att bevisa tillgänglighet.

Håll beroenden för identifiering och lokal styrning åtskilda från beroenden för fjärråtkomst. ZimaSpaces översikt över beroenden mellan Home Assistant-komponenter ger en användbar karta för att avgöra vilka fel som bör utlösa en omedelbar avisering och vilka som kan förbli en varning om försämrad funktion.

Märk resultatet med det lager där felet uppstod. Om Home Assistant är friskt men databaskontrollen misslyckas bör du undersöka lagring eller autentiseringsuppgifter i stället för att starta om Core. Om endast fjärråtkomsten misslyckas ska den lokala styrningen fortsätta köras. Denna separation hindrar ett enda rött beroende från att radera bevis på att friska tjänster fungerar.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Testa fel, återställning och aviseringarnas tidsinställning

Under ett underhållsfönster kan du stoppa ett icke-kritiskt beroende i taget eller tillfälligt blockera dess testsökväg. Bekräfta att motsvarande kontroll misslyckas, att orelaterade kontroller fortfarande är gröna och att aviseringen anger rätt lager. Återställ beroendet och verifiera att samma kontroll försvinner utan manuell redigering av tillståndet.

Lägg till automatiska omstarter först efter att du har observerat flera verkliga fel. Använd nedkylningsperioder och ett maximalt antal försök, och starta aldrig om databasen och Home Assistant samtidigt utan att bevara loggarna. En omstart är en verifieringsgrind, inte ett bevis på att det underliggande beroendet har återhämtat sig.

En godkänd utformning upptäcker det kontrollerade felet inom det förväntade tidsfönstret, bevarar lokala funktioner som inte är beroende av det och återgår till godkänt läge efter återställning. Rulla tillbaka kontroller som skapar betydande belastning eller falska larm. Eskalera om tjänsten förblir obrukbar trots att alla beroendekontroller godkänns, eftersom testet på applikationsnivå då behöver djupare bevis.