Planification des ressources de Home Assistant : pourquoi les pannes d’Internet modifient le comportement du contrôle local
Une coupure d’Internet n’entraîne pas automatiquement l’échec des automatisations locales de Home Assistant. Les intégrations locales Zigbee, Z-Wave, Matter, ESPHome, MQTT et LAN peuvent continuer à fonctionner lorsque le WAN est indisponible. Ce qui change, c’est la charge de travail qui les entoure : les requêtes cloud expirent, les intégrations réessaient, les recherches DNS échouent, les connexions distantes disparaissent et les opérations de récupération peuvent se produire par vagues lorsque la connectivité revient.
La planification des ressources reste donc importante pendant une panne, même lorsque le chemin de contrôle local fonctionne toujours. La question n’est pas « Home Assistant a-t-il besoin d’Internet ? », mais plutôt de savoir si le travail distant qui échoue reste isolé ou commence à consommer du temps de boucle d’événements, des threads d’exécution, de la capacité DNS, des entrées-sorties de journalisation ou des rechargements d’intégrations qui se chevauchent avec le contrôle local.
Les requêtes cloud échouées transforment les chemins rapides en chemins soumis à expiration
Lorsque le WAN fonctionne correctement, une requête cloud peut se terminer rapidement. Pendant une panne, le même appel peut occuper toute sa fenêtre d’expiration, être relancé, puis journaliser une erreur avant de retourner. Quelques appels sont inoffensifs ; de nombreuses intégrations qui font cela simultanément créent un profil de planification différent de celui du fonctionnement normal.
Le cycle de vie des entrées de configuration de Home Assistant dispose explicitement d’un état setup retry pour les dépendances qui ne sont pas prêtes, l’intervalle entre les tentatives automatiques augmentant au fil du temps. Le mode d’échec exact dépend toujours de chaque intégration, mais les tentatives constituent une partie définie du fonctionnement dégradé, et non un cas limite exceptionnel.
Évitez que les automatisations critiques attendent une API distante avant de lancer l’action locale. Envoyez la notification, la mise à jour cloud ou le webhook externe après l’action physique lorsque ce résultat distant n’est pas nécessaire pour décider de ce que la maison doit faire.
Les délais d’expiration réseau peuvent monopoliser des ressources même sans forte utilisation du processeur
Une opération réseau bloquée peut utiliser peu de processeur tout en occupant une tâche, une connexion, un thread ou une partie du budget de délai d’expiration. C’est pourquoi « le processeur n’est utilisé qu’à 10 % » ne prouve pas qu’une panne est sans coût.
Un cas Home Assistant documenté en 2026 a attribué des délais d’expiration répétés d’une intégration et des rechargements en cascade à un chemin IPv6 défaillant qui permettait aux connexions d’attendre au lieu d’échouer rapidement. Le symptôme était un retard de planification autour des appels réseau, et non un épuisement de la puissance de calcul brute.
Surveillez les tâches réseau en attente, les avertissements des intégrations, les échecs DNS ainsi que le délai entre le déclencheur et l’appel du service local. Si les actions locales restent rapides tandis que les entités cloud deviennent indisponibles, la panne est correctement isolée. Si la latence locale augmente avec les appels distants échoués, identifiez l’intégration ou le code personnalisé qui monopolise l’environnement d’exécution partagé.
Le travail bloquant est plus dangereux que l’attente asynchrone
Le cœur de Home Assistant est asynchrone : les intégrations bien conçues peuvent suspendre leur exécution pendant une attente d’entrées-sorties et permettre l’exécution d’autres tâches. Le cas dangereux est celui d’un travail bloquant qui monopolise la boucle d’événements elle-même, ou d’un code personnalisé qui effectue des opérations réseau synchrones au mauvais endroit.
Les recommandations destinées aux développeurs de Home Assistant expliquent qu’une opération bloquante dans la boucle d’événements empêche les autres tâches de s’exécuter jusqu’à sa fin. Une panne d’Internet peut révéler cette faiblesse, car un appel qui retourne normalement immédiatement peut soudainement attendre pendant un long délai d’expiration.
C’est pourquoi une intégration personnalisée peut donner l’impression que toute la plateforme ralentit pendant une panne, même si les intégrations locales natives restent bien conçues. Comparez le comportement avec les composants personnalisés désactivés avant d’accuser le matériel.
La récupération peut créer un second pic de charge
Lorsque la connectivité Internet revient, plusieurs intégrations peuvent se reconnecter, actualiser leur état, se réauthentifier, mettre à jour leurs entités et écrire presque simultanément de nouvelles données dans l’historique. La phase de récupération peut donc être plus chargée que le cœur de la panne.
Ne considérez pas un pic de processeur, de réseau ou d’écritures du Recorder immédiatement après le retour du WAN comme la preuve que la capacité normale en régime stable est insuffisante. Mesurez la durée du pic et vérifiez si la latence du contrôle local revient ensuite à son niveau de référence.
L’article de ZimaSpace consacré aux messages conservés, mis en file d’attente, de découverte et de disponibilité après une reconnexion illustre le même principe de récupération : la reconnexion de composants distribués peut rejouer l’état et créer une charge qui n’existait pas lorsque la connexion était stable.
Planifiez le mode dégradé, pas seulement le fonctionnement normal
Pendant une perte du WAN, les chemins locaux allant du mouvement à l’éclairage doivent continuer à fonctionner sans dépendance distante. L’interrogation du cloud peut passer à des tentatives limitées, les notifications distantes peuvent échouer ou être mises en file d’attente, les services dépendant du DNS doivent échouer de manière prévisible et le retour de la connectivité peut créer un bref pic d’actualisation.
L’objectif est une dégradation sélective : le travail distant facultatif ralentit ou disparaît, tandis que le contrôle local reste dans sa plage de temps normale. Le test de panne le plus pertinent consiste à déconnecter le WAN pendant une charge domestique normale, à mesurer quelques automatisations locales critiques, puis à reconnecter le réseau et à mesurer à la fois le pic de récupération et le temps nécessaire pour revenir au niveau de référence.
FAQ
Une panne d’Internet ralentit-elle les automatisations locales de Home Assistant ?
Pas nécessairement. Une automatisation entièrement locale peut continuer à la vitesse normale. Elle ralentit lorsque le travail lié au cloud, au DNS, à une intégration personnalisée ou au réseau partagé consomme des ressources sur le même chemin critique.
Dois-je ajouter des tentatives agressives pour que les intégrations cloud récupèrent plus rapidement ?
Non. Des tentatives agressives peuvent amplifier une panne et créer une charge inutile. Préférez un comportement de nouvelle tentative limité et maintenez la récupération cloud en dehors du chemin temporel des automatisations locales critiques.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi Home Assistant fonctionne-t-il différemment sur le réseau local et à distance ?
Les sessions Home Assistant en réseau local et à distance utilisent des chemins réseau différents ; la latence à distance ajoute le DNS, le...
Home Assistant fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le CGNAT et le double NAT n’affectent généralement pas le contrôle local de Home Assistant ; ils modifient principalement la façon dont les clients...
Comment la latence du réseau affecte-t-elle Home Assistant pendant les pannes d’Internet ?
La perte de connexion Internet et la latence du réseau sont deux problèmes distincts : les chemins locaux entre les appareils peuvent rester rapides...
