J’utilise HA depuis quelques semaines; et vue la volatilité de mes noms d’appareils (bon, à présent je les stabilise, mais j’ai longtemps hésité), je me suis dit que c’était une bonne idée (ou pas ?) de créer des template sensors avec des noms immuables pour certaines variables clé.
Ainsi, dans mon fichier templates.yaml, j’ai mis :
- sensor:
(...)
# Contient les Template Sensors (Alias) pour la stabilité des références critiques.
# --- Alias pour les entités physiques (Source unique de vérité) ---
- name: "Alias flux puissance réseau (négatif = import)"
unique_id: alias_grid_power_v1
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{{ states('sensor.gites_consometre_puissance_active') | float(0) }}
- name: "Alias flux production solaire"
unique_id: alias_pv_power_v1
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{{ states('sensor.atelier_onduleur_puissance_active') | float(0) }}
- name: "Alias flux consommation total"
unique_id: alias_total_consumption_v1
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set pv = states('sensor.alias_pv_power_v1') | float(0) %}
{% set grid = states('sensor.alias_grid_power_v1') | float(0) %}
{{ (pv - grid) | round(0) }}
- name: "Alias flux consommé depuis PV V1"
unique_id: alias_pv_consumption_v1
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set grid = states('sensor.alias_grid_power_v1') | float(0) %}
{% set pv = states('sensor.alias_pv_power_v1') | float(0) %}
{{ (pv - (grid if grid > 0 else 0)) | round(0) }}
Mais voilà, si je vais voir ensuite mes entités, je vois que HA crée des noms de sensor basés sur “name” et s’assoit sur les unique_id dont je rêvais dans mon templates.yaml
Du coup, je suis censé les modifier 1 par 1 dans l’UI. Assez galère.
Donc je dois sûrement m’y prendre mal.
Est-ce que j’ai raison d’essayer de créer des noms de paramètres de base faciles à mettre à jour si les appareils sous-jacents bougent ?
Si oui, quelle est la meilleure pratique / la méthode la plus élégante ?
Salut,
Tu viens de jeedom j’imagine pour faire ce genre de choses
Ça n’as pas trop de sens de créer des sensors virtuels dans HA ça ne fait que dupliquer les informations.
Le jour où tu dois changer des éléments il suffit de garder le même nom et cela conserve la continuité des informations
Comme indiqué plus haut la notion de virtuel (à la jeedom que tu évoques ou du moins qui y ressemble, et que ne confirme ou n’infirme pas ) n’a pas de sens.
Il n’y a pas besoin de persévérer dans ce sens, @ddfdom l’indique clairement : seul gain doubler la configuration et sa complexité …
Et malgré ce que je tu penses, relis un peu. Le renommage est la solution. Elle s’applique dès le début.
Après si ta question conserne la bonne façon de trouver le nom, ce qui n’est pas la question initiale, c’est autre chose.
Et donc puisque tu as édité pour expliciter. As-tu regarder les résultats de recherche?
Par exemple
Merci de ta réponse, désolé pour le “dérapage”, en tout cas il n’y avait strictement rien d’agressif dans ma réponse, plutôt une façon assez argotique de m’exprimer.
Mais en fait pour moi je crois que c’est le fond de mon problème. Voilà, condensé en une semaine conceptuelle, le chemin que j’ai fait en quelques semaines :
lundi : “bon, go donner des noms français à mes appareils, Molière FTW !”
mardi : “bon, on va décider d’aller du plus précis vers le plus large, genre type_appareil_pièce c’est plus pratique quand dans les tableaux Z2M les noms sont tronqués”
mercredi : “bon en fait mon coco tu devrais mettre des noms en anglais, c’est plus universel et ça facilitera quand tu devras demander de l’aide sur des communautés anglophones”
jeudi : “bon en fait faire du plus large vers le plus précis, c’est mieux quand on trie, donc pièce_appareil_type”
vendredi : “oh tiens quelle surprise, c’est le souk tes appareils ils sont nommés de façon chaotique, tu ne t’y retrouves pas. bon allez, on les renomme tous. ah mais oui du coup ça a un impact sur tes tdb et tes automatismes. pas simple pas simple…”
samedi : “bon, j’ai bien galéré à tout nommer, mais quand même j’ai un doute, est-ce que je ne devrais pas nommer mes équipements et capteurs en français ?”
dimanche : “bon tu sais quoi, tu te fais des template sensors qui eux ne bougeront pas et seront référencés dans les automatismes, scripts et autres tableaux de bord, et si tu décides de renommer tes capteurs t’auras que templates.yaml à mettre à jour. et puis t’as demandé à ChatGPT qui a dit ‘mais tu as une idée géniale, fonce, bien sûr qu’il faut faire comme ça’, un peu comme l’autre jour quand il t’a dit ‘mais bien sûr qu’écrabouiller ta voiture c’est la solution à tes problèmes de lave-vitre qui se bouchent. veux-tu que je t’explique comment rouler à 160 sur une route de montagne ?’”
…on arrive à lundi, et je réalise que la clef c’est une règle de nommage claire et cohérente, robuste, pérenne… et avant de tout reprendre, mesdames messieurs je m’en remets à votre expérience sur ce sujet.
en fait j’ai lu pas mal de tuto, fils de forums FR et EN qui visent à donner des conseils sur la question, mais j’ai la sensation que plus j’en lis plus je suis perdu, car si je comprends bien, HA fait beaucoup de modifications conceputelles ces derniers années (moins de modif directe des YAML, plus de modifs de l’UI, par exemple), et les conseils de, mettons, 2023 ou 2024 ne sont plus forcément les bonnes pratiques de fin 2025.
Même si effectivement HA évolue et utilise de moins en moins le yaml, le concept ne change pas :
Petit récap des notions :
entity_id
Définition : Identifiant unique d’une entité dans Home Assistant, sous la forme domain.object_id (ex. sensor.temperature_salon).
Usage : Sert à référencer l’entité dans les automatisations, scripts, tableaux de bord, etc.
Modifiable ? : Non directement dans l’interface. Il est généré automatiquement à partir du nom de l’objet (object_id). Pour le modifier, il faut :
Renommer l’objet dans l’intégration (si possible).
Utiliser une entité personnalisée via YAML ou customize: dans configuration.yaml.
name
Définition : Nom donné à l’entité lors de sa création ou dans sa configuration.
Usage : Sert à identifier l’entité dans l’interface ou dans les intégrations.
Modifiable ? : Oui, dans l’interface graphique ou via YAML selon l’intégration. Modifier le name ne change pas le entity_id.
friendly_name
Définition : Nom lisible et convivial affiché dans l’interface utilisateur (Lovelace, cartes, etc.).
Usage : Améliore la lisibilité pour l’utilisateur final.
Modifiable ? : Oui, via :
L’interface graphique (dans les paramètres de l’entité).
Le fichier customize: dans configuration.yaml :
YAML
homeassistant:
customize:
sensor.temperature_salon:
friendly_name: "Température du salon"
unique_id
Définition : Identifiant global unique attribué par l’intégration (souvent basé sur l’adresse MAC, UUID, etc.).
Usage : Permet à Home Assistant de suivre l’entité même si son entity_id change.
Modifiable ? : Non. Il est défini par l’intégration et ne peut pas être modifié manuellement. Il est essentiel pour permettre la personnalisation via l’interface graphique.
Bref le seul truc vraiement important pour l’utilisation dans les automatisations et scripts c’est le name ou l'entity_id, quasi la même chose dans 99% des cas. Dans ton cas Alias flux consommé depuis PV V1 est trop explicite et pas exploitable du point de vue technique. C’est là ou il faut faire un truc assez générique et simple
Pour les affichages, tu peux utiliser le friendly_name, voire remplacer à la volée dans la carte.
Difficile à dire, car j’ai pas vraiment connaissance de ce que ça mesure/représente mais oui. Et ça dépend aussi de chacun dans la façon de s’organiser
Perso j’ai toujours un truc du genre : sensor.type_piece_valeur
Donc sensor.sonde_*_temperature me donne toutes les températures connues dans HA et sensor.sonde_salon_* me donne toutes les valeurs dans le salon
Je ne garde jamais les références aux numéro de série ou aux marques si ce n’est pas important
qu’apporte le type_, au final ? N’est-il pas redondant avec le préfixe (switch., sensor.…) ? sensor.suite_temperature ferait tout aussi l’affaire dans tes filtrages : sensor.*_temperature et sensor.salon_*
P.S.: je découvre qu’on peut utiliser les wildcards dans les outils de dev, c’est cool.
Merci de ta réponse.
Dans ton exemple, le fait que tu aies dans le premier cas pièce_appareil, et dans le deuxième cas appareil_pièce_précision n’est pas un problème ?
ok, si j’ai bien compris en fait ce que tu appelles type_ (et que je pensais être bouton, capteur, etc.) est plutôt un appareil ? Donc si tu avais un salon grand comme celui de Jeff Bezos et que tu aurais 3 sondes de t° et humidité dans ton salon, tu les appellerais sonde1_salon, sonde2_salon, pour avoir les entités
sensor.sonde1_salon_temperature
sensor.sonde1_salon_humidity (ou sensor.probe1_livingroom_humidity ? ou sensor.sonde1_salon_humidite ? (*) )
binary_sensor.sonde1_salon_battery_plus_low
sensor.sonde2_salon_temperature
sensor.sonde2_salon_humidity
binary_sensor.sonde2_salon_battery_plus_low
(*) Question subsidiaire : est-ce je me prends la tête pour rien à essayer d’être homogène dans les langues ? Rien qu’en quelques semaines j’ai une floppée de sensors en tout genre, et quand je fais une recherche sur, mettons, salon, en n’étant pas homogène je galère à retrouver une entité que j’avais mis sous sensor.livingroom_temperature.
Oui c’est proche de la notion d’appareil, on va dire le nommage le plus générique/englobant.
Et oui j’ia bien sonde1 /sonde2 parfois
C’est tout le souci pour bien démarrer… C’est facile de mettre une norme au début et de la suivre assez précisément dans le temps. Si tu laisses HA faire au bout de 5 mois, c’est l’anarchie (personnellement).
C’est jouable de laisser HA faire, ça n’empêche pas que ça fonctionne mais c’est une gymnastique d’esprit à avoir d’une façon ou d’une autre.
C’est là où la notion de pièce/area qu’évoque Barto95 est intéressante, par contre historiquement ça ne permet pas de tout faire aussi simplement que les filtres.
Par exemple, trouver tous les éléments d’une pièce, ça marche bien, mais derrière si tu ne pas faire un critère de sélection, tu es revenu au point de départ.
Et puis de temps en temps ça ne marche pas partout : retrouver dynamiquement la pièce d’un appareil pour l’exploiter c’est OK, mais pas dans la config yaml de google home car ça retourne rien ..
Mais surtout, si je veux corriger / clarifier le entity ID, parfois un peu fantaisiste (ou dans la mauvaise langue), le sensor devient indisponible. Exemple : quand je tente de renommer sensor.batiment_consometre_tension_de_la_phase_a en sensor.batiment_consometre_tension_phase_a, le sensor devient unavailable. Pourquoi ?
Sur l’affichage, tu t’en fous un peu. C’est pas ce qui est important et en tout cas pas en lien avec l’entity_id (qui découle du name). Personnellement j’aime bien le friendly_name.
Il y a un ordre
Name <=> Entity_ID (en remplaçant les espaces, accents etc)
Name => Friendly_name => Traduction (si existante) => Valeur en dur dans une carte
Donc fixe ton entity_id en bas, un truc simple, le tien est beaucoup trop long je trouve sensor.batiment_conso_phaseA suffit. Ensuite adapte le champs name en haut, avec ce que tu veux que ça affiche
Fondamentalement, c’est quoi le problème de la longueur ?
Parce que j’ai conféré avec moi-même, et nous avons unanimement conclu que si nous voulons garder un truc cohérent sur le long-terme, et pas finir en plat de spaghetti, nous essaierions de nous en tenir à:
Se tenir à [type].[logement]_[pièce ou équipement]_[appareil]
En tous cas ça j’aimerais bien, mais pourquoi j’ai “This entity is unavailable” ?
Ah bah non, ce matin ça marche, je peux bien changer mes entity IDs, je n’ai plus le message. Si je n’avais pas pris la photo d’écran hier soir j’aurais cru que c’est moi qui avais bugué. Étrange…
Est-ce que j’ai raison d’essayer de créer des noms de paramètres de base faciles à mettre à jour si les appareils sous-jacents bougent ?
et avant de tout reprendre, mesdames messieurs je m’en remets à votre expérience sur ce sujet.
