L'intégration Hilo utilise des noms d'entités hardcoder, comme sensor.hilo_energy_total et des compteurs générés comme sensor.hilo_energy_total_low, etc.
Pendant le premier setup, j'ai renommé la valeur par défaut Meter00 à Compteur électrique, donc Home Assistant a généré un entity_id différent du défaut. L'intégration continue de chercher les noms hardcodés, et ça casse la génération des energy meters.
Résultat:
sensor.compteur_electrique_hilo_energy_total
au lieu de:
Le code Hilo ensuite recherche:
sensor.hilo_energy_total_low
donne des warnings comme:
check_tarif: Unable to find state for sensor.hilo_energy_total_low
Impact
Le problème devient complexe à corriger une fois que HA a stocké les anciens noms en cache.
Dans mon cas, j'ai du:
- delete ma connection hilo
- cleanup manuel des traces Hilo dans
.storage
- shutdown Home Assistant
- mount le PVC HA dans un container de debug
- edit
core.restore_state, core.entity_registry, core.device_registry
- reboot HA
- enroll hilo
core.restore_state est loadé en ram et est réécrit par Home Assistant si on edit pendant que HA roule. Sur Kubernetes, j'ai du mount le PVC dans un autre pod parce que HA gardait l'état en ram et le restaurait à chaque reboot.
J'imagine pas un débutant se débrouiller avec ça!
Idéfix
L'intégration devrait éviter de résoudre les sensors à partir de strings hardcodées comme:
sensor.hilo_energy_total
sensor.hilo_energy_total_low
À la place, elle pourrait:
- garder en ram ou en registry l'
entity_id réellement créé
- retrouver les entités via leur
unique_id Hilo
- utiliser l'entity registry de Home Assistant pour résoudre l'entity_id courant
- stocker explicitement l'entity_id source du compteur d'énergie dans les options/config entry
- éviter de baser la logique métier sur un slug généré à partir du nom d'appareil
Par exemple, au lieu de supposer:
l'intégration pourrait retrouver l'entité ayant le unique_id du compteur énergétique Hilo, puis utiliser cet entity_id réel comme source pour les utility meters.
tl;dr
Les noms d'entités sont très faciles à changer dans Home Assistant, surtout pendant l'onboarding. C'est quasiment comme si on piégais l'utilisateur. Si un simple rename peut casser les compteurs d'énergie et nécessiter un nettoyage manuel de .storage, l'expérience est ordinaire.
L'intégration Hilo utilise des noms d'entités hardcoder, comme
sensor.hilo_energy_totalet des compteurs générés commesensor.hilo_energy_total_low, etc.Pendant le premier setup, j'ai renommé la valeur par défaut
Meter00àCompteur électrique, donc Home Assistant a généré unentity_iddifférent du défaut. L'intégration continue de chercher les noms hardcodés, et ça casse la génération des energy meters.Résultat:
au lieu de:
Le code Hilo ensuite recherche:
donne des warnings comme:
Impact
Le problème devient complexe à corriger une fois que HA a stocké les anciens noms en cache.
Dans mon cas, j'ai du:
.storagecore.restore_state,core.entity_registry,core.device_registrycore.restore_stateest loadé en ram et est réécrit par Home Assistant si on edit pendant que HA roule. Sur Kubernetes, j'ai du mount le PVC dans un autre pod parce que HA gardait l'état en ram et le restaurait à chaque reboot.J'imagine pas un débutant se débrouiller avec ça!
Idéfix
L'intégration devrait éviter de résoudre les sensors à partir de strings hardcodées comme:
À la place, elle pourrait:
entity_idréellement crééunique_idHiloPar exemple, au lieu de supposer:
l'intégration pourrait retrouver l'entité ayant le
unique_iddu compteur énergétique Hilo, puis utiliser cet entity_id réel comme source pour les utility meters.tl;dr
Les noms d'entités sont très faciles à changer dans Home Assistant, surtout pendant l'onboarding. C'est quasiment comme si on piégais l'utilisateur. Si un simple rename peut casser les compteurs d'énergie et nécessiter un nettoyage manuel de
.storage, l'expérience est ordinaire.