Pourquoi l’activité en arrière-plan de Home Assistant augmente-t-elle après une modification de la configuration ou d’une intégration ?

Les tâches en arrière-plan de Home Assistant peuvent s’intensifier après une modification de configuration ou d’intégration, car une seule modification visible peut déclencher plusieurs opérations de cycle de vie cachées. Une intégration peut être déchargée puis configurée à nouveau, des entités peuvent disparaître et réapparaître, des messages de découverte peuvent être rejoués, des entrées de registre peuvent changer, des mises à jour d’état peuvent submerger Recorder, et les tableaux de bord ou automatisations peuvent réagir à l’état reconstruit.

C’est pourquoi un bref pic de CPU, d’E/S ou d’événements après une modification n’est pas automatiquement une régression des performances. La question utile est de savoir si la charge reste limitée et revient à son niveau de référence précédent, ou si une boucle de rechargement, une découverte répétée, une source d’états trop bavarde ou une intégration défaillante continue de la recréer.

Le rechargement d’une intégration recrée plus d’une connexion

Le rechargement d’une entrée de configuration décharge une intégration, puis la configure à nouveau. Cela peut fermer des sessions réseau, retirer les entités de l’environnement d’exécution actif, reconnecter les appareils, reconstruire les coordinateurs et republier l’état initial.

Les recommandations actuelles de Home Assistant indiquent que le rechargement décharge brièvement une intégration et rend ses entités indisponibles pendant la nouvelle phase de configuration. L’utilisateur voit une seule action dans le menu, mais le système effectue une transition de cycle de vie pour chaque entité et service géré par cette entrée.

Mesurez le pic depuis le début du rechargement jusqu’à la stabilisation de la disponibilité des entités et du taux d’événements. Un pic ponctuel est attendu ; un schéma répété de déchargement et de configuration indique un problème de configuration ou d’intégration.

Une mauvaise logique de rechargement peut multiplier la charge

Les intégrations personnalisées peuvent accidentellement se recharger plus souvent que prévu. Une simple modification des options ne devrait pas déclencher deux cycles de configuration qui se chevauchent ni mettre en concurrence un écouteur avec le rechargement du flux de configuration.

Home Assistant a déprécié un tel schéma en 2026, car la combinaison d’écouteurs d’entrées de configuration avec des méthodes de rechargement peut recharger une intégration deux fois ou créer une condition de concurrence.

Si la charge en arrière-plan ne revient jamais à son niveau de référence après une modification, inspectez les intégrations personnalisées et les journaux à la recherche de cycles répétés de configuration, de déchargement, de reconnexion ou d’exceptions avant d’ajouter des ressources CPU. Une boucle consomme de la capacité, quelle que soit la vitesse de l’hôte.

La découverte MQTT peut créer un pic de reconstruction

Les appareils gérés par MQTT ajoutent une autre source de charge. Lorsque MQTT est rechargé ou se reconnecte, les configurations de découverte et les messages d’état peuvent être traités à nouveau, ce qui crée des entités, met à jour leur disponibilité et restaure les états sur une courte période.

Le comportement MQTT de Home Assistant avertit explicitement que de nombreux messages de découverte conservés peuvent créer une charge élevée d’E/S lorsqu’ils sont rejoués simultanément. Le nombre et le moment d’envoi des messages de découverte font donc partie de la charge suivant une modification.

Ne renvoyez pas régulièrement toutes les charges utiles de découverte à intervalles courts uniquement pour garantir la récupération. Utilisez des identifiants uniques stables, un comportement birth/status, des configurations conservées uniquement lorsque cela est approprié et, lorsque l’émetteur le permet, répartissez dans le temps les importantes salves de redécouverte.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

La reconstruction des états peut alimenter Recorder et les automatisations dépendantes

Chaque entité qui réapparaît peut publier un état. Ces mises à jour peuvent être enregistrées, affichées, utilisées par des modèles et évaluées par des automatisations. Le pic de charge en arrière-plan peut donc se poursuivre après que l’intégration elle-même indique qu’elle est prête.

Un cas MQTT présenté par la communauté illustre cette limite de reconstruction des états : la conservation de la charge utile de découverte détermine si les entités peuvent être recréées automatiquement après le retour de Home Assistant.

Surveillez le taux de changement d’état et les écritures en base de données en parallèle du CPU. Si la phase de configuration se termine rapidement mais que Recorder reste occupé, la phase coûteuse est passée de la configuration de l’intégration à la persistance et aux consommateurs en aval.

Comparez le pic suivant une modification avec le niveau de référence stable

L’explication de ZimaSpace sur les pics de charge pilotés par les événements par rapport à un état stable au repos fournit la bonne comparaison : la demande transitoire doit être mesurée à l’aide du temps d’attente dans la file et du temps de récupération, et non confondue avec le besoin habituel en ressources.

Une modification saine de Home Assistant se stabilise. Les entités réapparaissent, le taux d’événements se normalise, Recorder rattrape son retard et le CPU ainsi que le stockage reviennent à leur plage habituelle. Diagnostiquez l’étape qui ne se stabilise pas au lieu de considérer chaque pic suivant une modification comme une raison de mettre le serveur à niveau.