Pourquoi Home Assistant perd-il un contrôle local fiable après un redémarrage ?

Home Assistant peut sembler être « opérationnel » après un redémarrage, alors que le contrôle local fiable n’est pas encore complètement rétabli. L’interface web peut se charger avant que chaque intégration, module radio, automatisation, assistant, chemin de base de données et connexion d’appareil ne soit de nouveau utilisable.

Diagnostiquez le redémarrage comme une séquence plutôt que comme un événement unique. Vérifiez que Home Assistant a atteint son état d’exécution, identifiez les intégrations encore en cours de chargement ou indisponibles, vérifiez que l’état persistant a été correctement restauré, puis testez un parcours local allant d’un capteur à une action. Si la même automatisation fonctionne après un rechargement manuel ou un deuxième redémarrage, le problème relève probablement davantage de l’ordre de démarrage ou de la disponibilité des dépendances que d’une défaillance permanente de la configuration.

Vérifiez que le démarrage est réellement terminé

Commencez par consulter les journaux et l’état des intégrations plutôt que d’activer et de désactiver immédiatement toutes les automatisations. Un processus de conteneur peut être en cours d’exécution alors que Home Assistant restaure encore des entités, se connecte aux intégrations, ouvre Recorder ou attend un coordinateur radio.

Un récent problème de démarrage de Home Assistant a montré qu’une intégration ZHA retardait suffisamment l’initialisation pour que les entités d’automatisation YAML restent indisponibles après le redémarrage. Cela ne signifie pas que ZHA est généralement peu fiable ; cela montre pourquoi « l’interface s’est ouverte » ne prouve pas que l’environnement d’automatisation complet est prêt.

Notez le premier horodatage auquel Home Assistant signale un fonctionnement normal, puis comparez-le au moment où vos entités critiques deviennent disponibles. Si une intégration est systématiquement la dernière dépendance à se rétablir, concentrez d’abord l’enquête sur celle-ci avant de modifier une logique d’automatisation sans rapport.

Attendez les dépendances réellement nécessaires à l’automatisation

Une automatisation d’éclairage déclenchée par un mouvement peut nécessiter l’intégration du capteur de mouvement, l’intégration de l’éclairage cible, le réseau local ou le coordinateur radio, ainsi que les assistants utilisés par ses conditions. Une seule dépendance indisponible peut donner l’impression que l’automatisation est peu fiable, même lorsque Home Assistant Core fonctionne correctement.

Cette limite temporelle est également visible dans des intégrations réelles qui ne font pas partie du moteur d’automatisation natif. Une discussion de la communauté Home Assistant indique qu’un client WebSocket peut se connecter avant que Home Assistant soit entièrement opérationnel ; ainsi, attendre l’état d’exécution évite d’envoyer des commandes pendant le chargement des entités.

Ne résolvez pas ce problème en ajoutant partout des délais arbitraires de 30 ou 60 secondes. Déterminez d’abord quelle dépendance est en retard, puis limitez l’attente au seul flux de démarrage qui nécessite réellement sa disponibilité.

Faites la distinction entre l’état de l’automatisation et celui de l’appareil

Home Assistant restaure de nombreux états après un redémarrage, mais la valeur restaurée d’une entité n’est pas toujours équivalente à une confirmation récente provenant de l’appareil physique. Un interrupteur peut afficher temporairement sa valeur précédente pendant que l’intégration se reconnecte.

Lorsque des entités redeviennent unavailable après un redémarrage, évitez de les supprimer ou de les associer de nouveau avant d’avoir identifié le parcours défaillant. Un guide de dépannage récent recommande de vérifier l’accessibilité, l’adressage, la découverte, le courtier, la radio et les journaux de l’intégration avant de réinitialiser les appareils. Vous éviterez ainsi qu’un problème de redémarrage ne se transforme en problème de reconfiguration plus important.

Pour chaque automatisation critique, notez si l’entité déclencheuse est restaurée, inconnue, indisponible ou fraîchement mise à jour après le redémarrage. Cette distinction permet de déterminer si l’échec se produit lors de la restauration de l’état, de la reconnexion de l’intégration ou dans l’automatisation elle-même.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testez le parcours de contrôle local sans le WAN

Les problèmes de redémarrage peuvent être confondus avec des problèmes Internet lorsque le DNS local, MQTT, le Wi-Fi, un proxy inverse ou une intégration connectée au cloud du fabricant change également d’état pendant le démarrage. Conservez un test simple de contrôle local qui ne dépend pas d’Internet.

Utilisez un parcours représentatif, par exemple un capteur de mouvement Zigbee qui allume une lampe locale, ou un bouton local qui commande un relais. Si ce parcours fonctionne alors qu’un appareil connecté au cloud ne fonctionne pas, le contrôle local de Home Assistant est opérationnel et la défaillance restante concerne la dépendance distante.

Le guide ZimaSpace consacré à la création d’une plateforme locale d’automatisation avec des limites explicites pour le contrôle local et la récupération constitue une référence utile pour maintenir le parcours domestique critique indépendant des services Internet facultatifs.

Utilisez un test d’acceptation après redémarrage au lieu de tâtonner

Corrigez la plus petite couche qui a échoué. Rechargez ou réparez une intégration lorsque ses entités sont absentes ; réparez l’état ou le stockage lorsque les valeurs restaurées sont incorrectes ; ne modifiez la séquence de démarrage que lorsqu’une dépendance est manifestement en retard. Il est inutile de reconstruire Home Assistant tant que la configuration persistante reste fiable et que l’échec est reproductible dans une seule branche de démarrage.