Le développement d’intégrations Home Assistant évolue avec Home Assistant Core 2026.10 : l’accès à trois anciennes propriétés du registre des appareils déclenche désormais un signal d’exécution. Pour les intégrations du cœur de Home Assistant, cet accès produit immédiatement une erreur ; pour les intégrations personnalisées, il reste fonctionnel mais inscrit un avertissement dans les journaux. Cette étape ne modifie pas, à elle seule, le fonctionnement des tableaux de bord, automatismes ou appareils déjà installés dans une maison connectée.
Ce qui change dans le registre des appareils
Jusqu’ici, un appareil Home Assistant pouvait être représenté par plusieurs entrées de configuration, par exemple lorsque plusieurs intégrations identifiaient le même matériel. Depuis Home Assistant Core 2026.8, le modèle a changé : un appareil ordinaire appartient à une seule entrée de configuration et, au plus, à une sous-entrée. Cette refonte évite notamment de mélanger dans une même fiche les entités et métadonnées issues de plusieurs intégrations.
Les propriétés DeviceEntry.config_entries, DeviceEntry.config_entries_subentries et DeviceEntry.primary_config_entry sont donc devenues obsolètes pour les appareils ordinaires. Elles sont remplacées respectivement par config_entry_id et, lorsque nécessaire, config_subentry_id. Le code est plus simple : il ne doit plus parcourir une collection d’entrées pour un appareil qui n’en possède désormais qu’une.
Une alerte pour les développeurs, pas une panne pour les foyers
Le mot « enforced » employé par Home Assistant ne signifie pas que toutes les intégrations tierces cessent de fonctionner avec Core 2026.10. À ce stade, les intégrations personnalisées qui lisent encore ces propriétés héritées continuent de s’exécuter, mais Home Assistant consigne un avertissement. Les intégrations maintenues directement dans le cœur du projet, elles, reçoivent une RuntimeError immédiate afin que le code interne soit mis à jour sans délai.
La suppression annoncée pour les intégrations personnalisées est prévue avec Home Assistant Core 2027.10, soit deux versions plus tard que l’échéance initialement évoquée pour cette série de propriétés. Home Assistant applique habituellement une période minimale de dépréciation de douze mois pour les API destinées aux développeurs ; celle-ci peut être prolongée, mais pas raccourcie.
Les remplacements à utiliser par une intégration
| Ancien accès | Accès à privilégier | Usage |
|---|---|---|
| DeviceEntry.config_entries | DeviceEntry.config_entry_id | Lire l’identifiant de l’unique entrée de configuration |
| DeviceEntry.config_entries_subentries | DeviceEntry.config_entry_id et DeviceEntry.config_subentry_id | Identifier l’entrée et son éventuelle sous-entrée |
| DeviceEntry.primary_config_entry | DeviceEntry.config_entry_id | Lire l’entrée propriétaire de l’appareil |
Les développeurs qui parcouraient les anciennes entrées pour retrouver celle de leur domaine peuvent également recourir à la méthode async_get_device_and_config_entry_for_domain(). Elle répond directement au besoin sans reconstituer une logique basée sur le modèle historique à plusieurs entrées.
Les rares cas qui conservent l’ancien comportement
Une exception existe pour les appareils composites créés pour la compatibilité avec des identifiants antérieurs à la migration. Lorsqu’un ancien appareil était partagé par plusieurs entrées, Home Assistant peut fournir un objet composite, en lecture seule, qui couvre réellement plusieurs entrées. Dans ce cas précis, les trois propriétés historiques restent pertinentes et ne génèrent pas d’alerte. Le code qui accepte des identifiants d’appareil enregistrés avant la migration doit donc vérifier is_composite_device avant de choisir la bonne lecture.
Les appareils supprimés et les appareils enfants, eux, ne bénéficient pas de cette exception. Pour un appareil supprimé orphelin, les nouveaux champs peuvent être absents ; une intégration doit donc gérer la valeur nulle plutôt que de s’appuyer sur les anciennes collections vides.
Faut-il agir sur son installation Home Assistant ?
Pour un utilisateur qui installe ses appareils via l’interface Home Assistant, aucune action n’est demandée. Les clients WebSocket, dont l’interface et les cartes personnalisées qui se limitent à l’API WebSocket documentée, ne sont pas affectés par ce changement précis : il concerne les propriétés Python. Les anciens champs restent encore sérialisés pendant la période de compatibilité, selon leur calendrier propre.
En revanche, l’auteur d’une intégration personnalisée devrait tester son projet sous Home Assistant Core 2026.10, consulter les avertissements au démarrage, puis remplacer les accès concernés. Il est préférable de ne pas attendre 2027.10 : une intégration silencieuse aujourd’hui peut devenir bruyante dans les logs, puis incompatible lorsque la couche de compatibilité sera retirée.
FAQ
Home Assistant Core 2026.10 est-il un déploiement stable général ?
La note développeur confirme que ce changement arrive dans Home Assistant Core 2026.10. Elle documente une évolution d’API, sans détailler dans cette annonce les modalités de diffusion selon les méthodes d’installation.
Mes automatisations risquent-elles de disparaître ?
Non, le changement vise le code Python des intégrations qui consultent le registre des appareils avec des propriétés dépréciées. Il ne modifie pas directement les automatismes d’un utilisateur. Les identifiants composites historiques restent d’ailleurs pris en charge par un mécanisme de compatibilité.
Une carte personnalisée doit-elle être modifiée ?
Pas nécessairement. Home Assistant indique que ce durcissement ne touche que les propriétés Python ; les clients utilisant la liste d’appareils via WebSocket ne reçoivent pas ces avertissements. Une carte qui exploite néanmoins les anciens champs WebSocket devra suivre leur calendrier de dépréciation distinct.
