Comment Home Assistant protège-t-il la cohérence lors de modifications simultanées ?

Home Assistant limite les conflits liés aux changements concurrents grâce à la planification de la boucle d’événements, aux mises à jour de la machine à états, aux modes d’automatisation, à la coordination des intégrations et aux écritures transactionnelles dans la base de données.

Ces mécanismes maintiennent la cohérence des structures internes, mais ils ne déterminent pas laquelle de deux intentions domestiques valides doit l’emporter. Une automatisation de détection de mouvement peut allumer une lampe tandis qu’une automatisation du coucher l’éteint, et les deux appels de service peuvent être exécutés correctement. La cohérence s’étend donc sur deux niveaux : Core doit préserver des transitions d’état valides, tandis que la configuration doit définir l’ordre, l’annulation ou la priorité des actions concurrentes.

La boucle d’événements sérialise les opérations critiques au sein du processus

Home Assistant Core utilise une planification asynchrone afin que de nombreuses tâches puissent attendre des entrées-sorties sans que chacune possède son propre thread. Le code exécuté dans la boucle d’événements progresse de manière coopérative, ce qui maintient l’ordre des opérations centrales sur l’état lorsque les intégrations respectent le contrat asynchrone.

Une analyse détaillée de la concurrence dans Home Assistant explique comment la sérialisation de la boucle d’événements coordonne les rappels et les tâches, tandis que le code bloquant doit être déplacé hors de la boucle.

La sérialisation à ce niveau empêche la modification simultanée de certaines structures internes, mais elle ne rend pas atomique une automatisation entière en plusieurs étapes. Une tâche peut attendre des entrées-sorties d’un appareil pendant qu’une autre tâche valide progresse.

Les modes d’automatisation définissent l’admission et l’ordre d’exécution

Le mode unique rejette une nouvelle exécution lorsqu’une autre est active ; le mode redémarrage annule l’exécution précédente ; le mode file d’attente préserve l’ordre ; le mode parallèle autorise le chevauchement. Choisir un mode constitue donc une décision de politique concernant la signification des déclenchements concurrents pour cette automatisation.

Une discussion sur les conditions de concurrence impliquant des automatisations contradictoires montre pourquoi les écritures d’automatisations contradictoires doivent être choisies en fonction de la ressource contrôlée et de la priorité souhaitée.

Le mode file d’attente peut préserver l’ordre d’arrivée au sein d’une même automatisation, mais des automatisations distinctes peuvent toujours entrer en conflit. Il est nécessaire de centraliser la gestion ou d’ajouter un arbitre explicite lorsque plusieurs règles écrivent sur la même entité.

Les intégrations réconcilient l’état souhaité et l’état observé de l’appareil

Un appel de service exprime une action souhaitée, tandis que les retours ultérieurs de l’appareil fournissent l’état observé. Les intégrations peuvent utiliser des verrous, des coordinateurs, des mises à jour optimistes, l’interrogation périodique ou des accusés de réception afin d’éviter les opérations protocolaires simultanées et de réconcilier les différences.

Des exemples de modes d’automatisation montrent comment l’exécution en file d’attente ou en parallèle modifie l’ordre d’exécution, mais le protocole de l’appareil peut encore réordonner ou rejeter les commandes après leur transmission par Core.

L’ordre interne ne garantit pas l’ordre physique sur un réseau radio instable, un service cloud ou un appareil en veille. Lorsque le protocole le permet, le résultat de référence doit provenir de l’état confirmé de l’appareil, et non uniquement de l’ordre dans lequel les appels de service ont été émis.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Les transactions protègent le stockage, pas les intentions domestiques

Les transactions du composant Recorder maintiennent la validité des modifications associées lors des validations et de la récupération. Elles protègent la représentation stockée contre les écritures partielles, mais la persistance de l’historique intervient après les décisions d’état et ne peut pas résoudre des commandes contradictoires.

Un guide pratique avertit que le mode d’automatisation par défaut peut ne pas correspondre au comportement souhaité, ce qui confirme que la politique d’intention de l’automatisation est distincte de la cohérence de la base de données.

Voici la limite de défaillance : si deux règles correctes encodent des objectifs incompatibles, Core peut rester cohérent en interne tandis que l’appareil oscille. Ajoutez une attribution, une priorité, un délai de refroidissement ou une machine à états partagée ; l’optimisation de la base de données ne peut pas corriger une intention ambiguë.

Testez un conflit avec un calendrier déterministe

Choisissez une entité sans risque et déclenchez les chemins concurrents à des décalages contrôlés : simultanément, à une seconde d’intervalle et pendant un délai délibéré de l’appareil. Enregistrez l’ordre des traces d’automatisation, les appels de service, les accusés de réception, les événements d’état et l’état physique final.

Les limites entre entrée et commande suivent une automatisation locale depuis les entrées jusqu’à la commande, fournissant les repères nécessaires pour distinguer l’ordre de Core de la réconciliation de l’appareil.

Le test n’est réussi que lorsque le vainqueur déclaré et l’état final de l’appareil correspondent lors d’essais répétés, y compris dans les cas de redémarrage et d’appareil indisponible. Si les résultats varient, attribuez la responsabilité à une seule automatisation et faites-y passer les autres intentions ; n’ajoutez pas de délais arbitraires avant que les traces aient identifié la limite contestée.