Pourquoi Home Assistant retraite-t-il les données existantes après une mise à niveau ?

Home Assistant peut retraiter les données existantes après une mise à niveau, car le nouveau code doit faire correspondre les schémas stockés, les index, les caches, les statistiques et l’état des intégrations avec les nouvelles attentes.

Les relevés d’origine des capteurs ne sont pas nécessairement collectés une nouvelle fois. Le système mis à niveau peut plutôt transformer des tables, reconstruire des structures dérivées, recharger des entrées de configuration ou recalculer des synthèses afin que l’ancien état reste exploitable avec la nouvelle version. La durée dépend du volume de données, de la latence du stockage, de l’espace temporaire disponible, du nombre d’intégrations, du moteur de base de données et du chemin exact de mise à niveau.

Une mise à niveau modifie la manière dont l’état existant est interprété

Home Assistant conserve bien plus que du texte de configuration. Les tables du Recorder, les registres d’entités, les métadonnées des appareils, les entrées d’intégration, les statistiques et les caches encodent tous des hypothèses faites par la version qui les a écrits. Lorsque le nouveau code modifie ces hypothèses, il doit soit traduire l’état existant, soit régénérer une représentation compatible avant l’utilisation normale.

C’est l’objectif général d’une migration logicielle contrôlée : transférer les données et le comportement d’une ancienne représentation vers une nouvelle sans perdre le résultat attendu. La présentation de la migration logicielle publiée par The Pragmatic Engineer distingue la préparation, l’exécution, le travail post-migration et la phase de suivi, ce qui explique pourquoi le processus ne s’arrête pas à l’installation du nouveau code.

Le retraitement est donc une opération de compatibilité, et non la preuve que Home Assistant a oublié les données sources. Les questions importantes sont de savoir quelle représentation stockée a changé, si le traitement progresse et quelles fonctions restent disponibles. Selon les versions, aucune, une ou plusieurs de ces couches peuvent être concernées.

Les migrations de schéma peuvent lire et réécrire de grandes tables

Un schéma de base de données définit les tables, les colonnes, les types, les index et les contraintes. Une mise à niveau peut ajouter une colonne, élargir un identifiant, reconstruire un index ou transformer des lignes pour adopter une nouvelle organisation. Des opérations qui semblent mineures dans les notes de version peuvent parcourir ou copier une grande base de données du Recorder et générer d’importantes entrées-sorties temporaires.

Une migration observée du Recorder de Home Assistant a consigné la suppression et la recréation d’index sur une base de données de plusieurs gigaoctets, avec un avertissement indiquant que la création d’index pouvait prendre plusieurs minutes sur les grandes bases ou les machines plus lentes.

La charge dépend des lignes concernées et du comportement du stockage, pas uniquement du pourcentage d’utilisation du processeur. Une migration peut être limitée par les entrées-sorties, les verrous ou le moteur de base de données, alors que l’utilisation du processeur semble faible. L’interrompre à répétition peut relancer le traitement ou laisser le système nécessiter une validation : la progression et les journaux comptent donc davantage qu’une estimation arbitraire du temps écoulé.

Les index dérivés et les caches doivent correspondre au nouveau code

Les index, les caches, les ressources compilées et les structures de recherche sont dérivés des données faisant autorité. Les réutiliser après une modification de leur format ou de leurs règles d’invalidation pourrait renvoyer des entités obsolètes, des requêtes incorrectes ou des ressources d’interface incompatibles. Les supprimer puis les reconstruire remplace un travail temporaire par un résultat cohérent avec la nouvelle version.

La cohérence du cache dépend de la suppression des entrées dont les hypothèses sources ont changé. L’analyse technique de Meta sur l’invalidation et la cohérence des caches explique qu’un cache n’est pas la source de vérité et peut rester incohérent indéfiniment lorsque l’invalidation est mal gérée.

Ce mécanisme explique pourquoi le premier démarrage ou le premier chargement du tableau de bord peut être plus lent que les suivants. Une fois l’état dérivé compatible créé, les accès ultérieurs le réutilisent. Si la même reconstruction coûteuse se répète à chaque redémarrage, cherchez plutôt pourquoi le résultat n’est pas enregistré ou reconnu, au lieu de considérer cela comme une simple phase normale de préchauffage.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Les intégrations rapprochent les appareils, les entités et les sessions

Chaque intégration doit restaurer les identifiants, établir les sessions, détecter les appareils, associer les identifiants et mettre à jour la disponibilité des entités. Une mise à niveau peut modifier la logique d’installation, les modèles d’entités, les versions de bibliothèques ou les gestionnaires de migration. La configuration existante est alors rechargée par le nouveau code afin que l’intégration produise un état cohérent avec l’environnement d’exécution actuel.

Le comportement lors du rechargement des intégrations rend ce cycle visible. Une explication publiée par la communauté sur le rechargement des entrées de configuration de Home Assistant décrit une action qui décharge puis réinstalle une intégration, ce qui constitue la même limite générale de rapprochement que celle utilisée au démarrage.

Une API cloud, un appareil fonctionnant sur batterie en veille ou une passerelle indisponible peuvent prolonger le rapprochement indépendamment du travail de la base de données. Des entités absentes au début du démarrage peuvent réapparaître temporairement, mais des échecs d’authentification répétés ou des changements incessants d’identifiants ne sont pas des signes de progression normale. Séparez les nouvelles tentatives des intégrations des journaux de migration du Recorder avant d’en déterminer la cause.

Les statistiques peuvent être reconstruites à partir de l’historique conservé

Home Assistant conserve l’historique brut ou à courte durée parallèlement aux statistiques dérivées utilisées dans les vues à plus long terme. Lorsqu’une règle de calcul, une relation de métadonnées ou une structure de synthèse change, les lignes conservées doivent parfois être relues pour corriger ou régénérer la série dérivée. Cela entraîne des lectures et des écritures supplémentaires sans modifier les mesures sources des appareils.

La distinction entre l’historique des entités et les statistiques à long terme est importante en pratique. Un guide détaillé de la communauté consacré à la récupération des statistiques de Home Assistant traite les statistiques résumées comme une couche de données distincte, qui peut être reconstruite ou déplacée indépendamment de l’historique éphémère.

Une synthèse reconstruite devrait converger vers des valeurs stables et un volume d’écriture normal. Surveillez les lacunes, les doublons, les changements d’identifiants de métadonnées ou les tâches qui redémarrent toujours au même point. Ces signes indiquent plutôt un problème de compatibilité ou d’intégrité qu’un simple parcours fini des données conservées.

Une progression normale n’a pas la même apparence qu’un échec

Le travail post-mise à niveau attendu comporte une tâche nommée, une progression croissante ou des étapes de journal qui évoluent, une consommation de ressources maîtrisée et une fin prévisible. Un échec répète la même erreur, épuise l’espace disque, redémarre la migration, laisse le Recorder indisponible indéfiniment ou génère de nouveaux avertissements de corruption. Le temps écoulé ne suffit pas à les distinguer de manière fiable, car les bases de données et le matériel varient.

Une migration échouée montre concrètement qu’il n’est pas toujours prudent d’attendre. Lors d’un échec de mise à niveau d’une base de données Home Assistant, le stockage disponible de la machine virtuelle a été rempli et le traitement n’a repris qu’après l’augmentation de sa capacité, ce qui montre qu’un échec répété peut être dû à une limite de ressources plutôt qu’à un manque de patience.

Ne supprimez pas une base de données simplement parce que le démarrage est plus lent que d’habitude. Conservez la sauvegarde antérieure à la mise à niveau, notez précisément les deux versions et surveillez l’espace libre, l’activité de la base de données et les journaux. Passez à l’escalade lorsque la même erreur se répète, que la progression s’arrête pendant plusieurs périodes d’observation ou que les services nécessaires dépassent la fenêtre d’interruption prévue.

Utilisez un protocole d’observation post-mise à niveau par étapes

Avant la mise à niveau, notez la taille de la base de données, l’espace libre, la durée normale du démarrage, le nombre d’intégrations et l’identifiant d’une sauvegarde fiable. Après le démarrage de la nouvelle version, vérifiez les messages de migration, l’augmentation du stockage, la disponibilité du Recorder, le retour des entités et la cohérence des statistiques à intervalles fixes. Évitez les sauvegardes ou analyses simultanées qui pourraient fausser la charge du premier démarrage.

Il est plus facile d’interpréter une migration lorsque les éléments de récupération et l’état des versions sont documentés à l’avance. Le récit d’une migration Home Assistant par un utilisateur illustre comment les sauvegardes, le comportement de restauration et les changements d’environnement font partie intégrante de la transition, plutôt que d’être une réflexion tardive.

Ne déclarez la réussite que lorsque les journaux ne signalent plus de travail de migration, que le Recorder accepte de nouveaux événements, que l’historique et les statistiques répondent aux vérifications, que les intégrations se stabilisent et qu’un second redémarrage revient près du niveau habituel. Gardez le processus de récupération ZimaSpace pour une sauvegarde connue comme fiable de la base de données à portée de main, mais ne l’utilisez qu’une fois que l’échec observé a dépassé le seuil justifiant une récupération.