Varför återskapar Home Assistant ett annat tillstånd efter en omstart av containern?

En omstart av en Home Assistant-container kan få systemet att se tillfälligt annorlunda ut även när den beständiga konfigurationen är helt intakt. Anledningen är att en körande instans innehåller både varaktigt tillstånd på disken och tillfälligt körtillstånd i minnet. När containern startas om förstörs det senare och integrationerna måste bygga upp det igen.

Därför kan en entitet tillfälligt få statusen unknown eller unavailable, en MQTT-enhet kan dyka upp igen så snart kvarhållna meddelanden anländer och en extern tjänst kan fortsätta saknas tills ett nytt anslutningsförsök lyckas. En omstart är en händelse där tillståndet återskapas, inte bara en paus och återupptagning av samma process i minnet.

Containerkörningen kan ersättas; /config är den beständiga gränsen

Home Assistant Container körs normalt genom att containeravbildningen återskapas medan konfigurationsmonteringen behålls. Att uppdatera avbildningen, ändra körmiljön eller starta om processen ska inte kräva att hemmet byggs upp från grunden när den beständiga sökvägen fortfarande är korrekt ansluten.

Det aktuella arbetsflödet för Home Assistant Container återskapar uttryckligen containern när versioner ändras. Modellen fungerar eftersom applikationens tillstånd förväntas överleva utanför den tillfälliga körmiljön.

Allt som endast finns i processens minne försvinner vid en omstart. Den nya processen måste läsa in konfiguration, register, databaser och integrationsdata igen innan den kan återskapa samma aktuella vy.

Core startar en ny tillståndsmaskin för körningen

Vid varje start bygger Home Assistant en ny Core-process med en ny händelseloop, tillståndsmaskin, tjänster, tidsinställare och objekt för integrationskörningen. Entitetsregistret kan identifiera kända entiteter, men det aktuella värdet för en fysisk enhet måste fortfarande återställas, hämtas eller rapporteras.

Recorder skapar också en ny Recorder-körning varje gång Home Assistant startar. Historiska databasposter finns kvar, men den aktuella processen utgör ett nytt körningsintervall och är inte en fortsättning på det gamla.

Denna skillnad är viktig när loggar eller databastidsstämplar kring en omstart jämförs. En historikpost visar vad Home Assistant tidigare observerade; den bevisar inte automatiskt att den nya processen redan har återupprättat den aktiva enhetsanslutningen.

Integrationer fyller på körtillstånd i olika hastigheter

Vissa integrationer återansluter omedelbart till en lokal enhet. Andra väntar på DNS, en broker, ett moln-API, en radiobrygga eller en annan container. Därför blir deras entiteter tillgängliga vid olika tidpunkter, även om Home Assistant Core redan körs.

Home Assistants aktuella modell för konfigurationsfel kräver att tillfälligt otillgängliga integrationer går in i en återförsökssökväg så att de kan återhämta sig när enheten eller tjänsten blir nåbar. Det innebär att det synliga tillståndet efter en omstart kan förändras under flera minuter utan att det beständiga datat har ändrats.

En andra omstart när alla beroenden redan är aktiva kan verka mycket snabbare än en omstart av hela stacken, eftersom nätverket, brokern, databasen och enheterna inte längre behöver stabiliseras samtidigt.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

MQTT gör återskapandet av tillstånd särskilt tydligt

MQTT är ett användbart exempel eftersom brokern kan behålla meddelanden om identifiering eller tillstånd oberoende av Home Assistant-processen. När Home Assistant återansluter kan kvarhållna data spelas upp igen, och entiteter kan snabbt återfå sitt senast rapporterade värde.

MQTT-integrationen dokumenterar att identifierade entiteter är otillgängliga efter en omstart tills identifieringen har bearbetats, medan kvarhållna identifierings- och tillståndsmeddelanden kan spelas upp när prenumerationerna byggs upp igen. Home Assistant skickar också ett Birth-meddelande som enheter kan använda för att publicera identifiering och aktuellt tillstånd igen.

Ett kvarhållet värde är fortfarande en senast känd rapport, inte ett bevis på att den fysiska enheten är nåbar just nu. Tillgänglighetstopics och färsk telemetri bör bedömas separat.

Omstartsbeteendet beror på var källan till sanningen finns

• Beständig konfiguration och register: läses in igen från Home Assistants varaktiga lagring.
• Aktuellt enhetstillstånd: hämtas eller rapporteras ofta på nytt av en integration.
• MQTT-tillstånd: kan återskapas från kvarhållna meddelanden eller nya publiceringar.
• Molnbaserat tillstånd: beror på anslutning till det externa API:t och giltiga inloggningsuppgifter.
• Historiskt tillstånd: finns kvar i Recorder men är inte samma sak som aktuellt tillstånd.
• Rena körningsobjekt: återskapas av den nya Home Assistant-processen.

Förklaringen av MQTT-tillstånd efter en omstart på ZimaSpace visar en specifik väg för återskapande. Den bredare regeln är att omstartsbeteendet följer var varje komponents källa till sanningen finns.

Vanliga frågor

Raderar en omstart av Home Assistant-containern historiken?

Nej, inte när den beständiga konfigurationen och Recorder-databasen är korrekt monterade. En omstart ersätter körningsprocessen, medan historiska data finns kvar i den beständiga databasen.

Varför kan en entitet visa sitt gamla värde direkt efter en omstart?

Värdet kan komma från Home Assistants återställningsmekanism, en integrationscache, ett kvarhållet MQTT-tillstånd eller en omedelbar avläsning från enheten. Kontrollera integrationen och tillgänglighetsvägen innan du betraktar det visade värdet som en färsk fysisk avläsning.