Hur skyddar Home Assistant konsekvensen vid samtidiga ändringar?

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 Does Home Assistant Protect Consistency During Concurrent Changes?

Home Assistant begränsar konflikter vid samtidiga ändringar genom schemaläggning i händelseloopen, uppdateringar av tillståndsmaskinen, automationslägen, samordning mellan integrationer och transaktionella databasskrivningar.

De mekanismerna håller interna strukturer konsekventa, men de avgör inte vilken av två giltiga avsikter i hemmet som ska vinna. En rörelseautomation kan tända en lampa samtidigt som en läggdagsautomation släcker den, och båda tjänsteanropen kan ha utförts korrekt. Konsekvens sträcker sig därför över två lager: Core måste bevara giltiga tillståndsövergångar, medan konfigurationen måste definiera ordning, avbrytande eller prioritet för konkurrerande åtgärder.

Händelseloopen serialiserar kritiskt arbete i processen

Home Assistant Core använder asynkron schemaläggning så att många uppgifter kan vänta på I/O utan att varje uppgift behöver äga en tråd. Kod som körs i händelseloopen gör framsteg kooperativt, vilket håller centrala tillståndsoperationer ordnade när integrationerna följer det asynkrona avtalet.

En detaljerad diskussion om samtidighet i Home Assistant förklarar hur serialisering i händelseloopen samordnar återanrop och uppgifter, medan blockerande kod måste flyttas bort från loopen.

Serialisering på den här nivån förhindrar samtidiga ändringar av vissa interna strukturer, men gör inte en hel automation med flera steg atomär. En uppgift kan vänta på enhets-I/O medan en annan giltig uppgift fortsätter.

Automationslägen definierar tillträde och ordning

Enkelläget avvisar en ny körning medan en annan är aktiv; omstartsläget avbryter den tidigare körningen; köat läge bevarar ordningen; parallellt läge tillåter överlappning. Att välja läge är därför ett policybeslut om vad samtidiga utlösare betyder för automationen.

En diskussion om race conditions med konkurrerande automationer visar varför skrivningar från konkurrerande automationer måste väljas utifrån den styrda resursen och den önskade prioriteten.

Köat läge kan bevara ankomstordningen inom en automation, men separata automationer kan fortfarande hamna i konflikt. När flera regler skriver till samma entitet krävs det att ägarskapet samlas eller att en uttrycklig skiljedomare läggs till.

Integrationer sammanför önskat och observerat enhetstillstånd

Ett tjänsteanrop uttrycker en önskad åtgärd, medan senare återkoppling från enheten anger det observerade tillståndet. Integrationer kan använda lås, samordnare, optimistiska uppdateringar, avläsning eller bekräftelser för att undvika överlappande protokolloperationer och sammanföra skillnader.

Exempel på automationslägen tydliggör hur köad och parallell körning ändrar körningsordningen, men enhetsprotokollet kan fortfarande ändra ordningen på eller avvisa kommandon efter att Core har skickat dem.

Intern ordning garanterar inte fysisk ordning över en opålitlig radioanslutning, molntjänst eller vilande enhet. Det auktoritativa resultatet bör komma från bekräftat enhetstillstånd när protokollet stöder det, inte enbart från ordningen som tjänsteanropen skickades i.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Transaktioner skyddar lagring, inte avsikten i hemmet

Recorder-transaktioner håller relaterade databasändringar giltiga mellan genomföranden och vid återställning. De skyddar den lagrade representationen mot ofullständiga skrivningar, men historisk lagring sker efter tillståndsbesluten och kan inte lösa motstridiga kommandon.

En guide för användare varnar för att standardläget för automationer kanske inte motsvarar det önskade beteendet, vilket förstärker att policy för automationsavsikt är separat från databasens konsekvens.

Detta är gränsen för vad som kan fallera: om två korrekta regler uttrycker oförenliga mål kan Core förbli internt konsekvent medan enheten växlar fram och tillbaka. Lägg till ägarskap, prioritet, nedkylningsperiod eller en gemensam tillståndsmaskin; databasjusteringar kan inte reparera en tvetydig avsikt.

Testa en konflikt med ett deterministiskt schema

Välj en ofarlig entitet och utlös de konkurrerande vägarna med kontrollerade tidsförskjutningar: samtidigt, med en sekunds mellanrum och under en avsiktlig enhetsfördröjning. Dokumentera ordningen i automationens spårning, tjänsteanrop, bekräftelser, tillståndshändelser och det slutliga fysiska tillståndet.

Gränserna från indata till styrning följer en lokal automation från indata till styrning och ger de gränser som behövs för att skilja Core-ordning från enhetsavstämning.

Godkänn endast när den angivna vinnaren och enhetens slutliga tillstånd överensstämmer i upprepade tester, inklusive fall med omstart och otillgänglig enhet. Om resultaten varierar, låt en automation äga styrningen och dirigera andra avsikter genom den; lägg inte till godtyckliga fördröjningar innan spårningen har identifierat den omstridda gränsen.