Après à un premier changement « conséquent » sur mon installation (passage de Zigbee Home Automation (ZHA) à Zigbee2MQTT (Z2M)) je m’interroge sur une façon de minimiser les « problèmes » suite à ce genre d’opération.
Typiquement il faut revoir les automatisations, scripts, etc. Mais on perd aussi l’historique des valeurs (e.g. températures).
Ma question/idée : est-ce que créer une entité virtuelle (note : ce nom n’est peut-être pas le bon dans l’écosystème Home Assistant) pour chaque entité physique est une solution intéressante/viable ? Ça ferait une sorte de référence indirecte.
Exemple :
Disons que j’ai 3 sondes de température Z-Wave :
Sonde Zooz ZSE44 XS Bureau
Sonde Zooz ZSE44 XS Chambre
Sonde Zooz ZSE44 XS Salon
J’ai donc 3 × x entités :
TempératureZooz ZSE44 XS Bureau
Température Zooz ZSE44 XS Chambre
Température Zooz ZSE44 XS Salon
HumiditéZooz ZSE44 XS Bureau
Humidité Zooz ZSE44 XS Chambre
Humidité Zooz ZSE44 XS Salon
Puissance signalZooz ZSE44 XS Bureau
Puissance signal Zooz ZSE44 XS Chambre
Puissance signal Zooz ZSE44 XS Salon
BatterieZooz ZSE44 XS Bureau
Batterie Zooz ZSE44 XS Chambre
Batterie Zooz ZSE44 XS Salon
…
Si je change de sonde (pour du ZigBee, ou pour un autre modèle Z-Wave) je perdrais donc mon historique de suivi de la température et humidité dans le bureau, la chambre et le salon.
Sauf si j’historise les valeurs d’entités virtuelles correspondantes :
Température Bureau
Température Chambre
Température Salon
Humidité Bureau
Humidité Chambre
Humidité Salon
Puissance signalsonde … (facultatif, puisque peu pertinent)
Batteriesonde … (facultatif, puisque peu pertinent)
…
Ça me semble une bonne idée mais je manque de recul pour trancher.
Ajouter une couche de virtuels au dessus des entités, ça ressemble à une vieille technique jeedom.
Même jeedom a fini par reconnaitre que c’était lourd et pas forcement plus efficace.
Comme tu l’as noté, l’historique se base sur le nom (entity_id), donc si tu le conserves tout le temps, tu es bon.
Par ailleurs dans le même ordre d’idée, si tu change de matériel, le fait d’avoir Zooz ZSE44 dans l’id, c’est compliqué. Donc sauf a sacrifier l’historique maintenant, c’est raté.
La solution idéale, c’est donc d’avoir directement des noms génériques, que l’on adapte directement en renommant.
Par contre dans ton cas, rien n’empêche de renommer les entités z2m avec l’ancien nom de zha.
Mais si je n’indique pas le vrai nom (marque + modèle) de l’appareil dans son nom sous Home Assistant ça devient compliqué de savoir réellement quoi est quoi…
J’aimais bien l’idée d’avoir une abstraction, chose qu’on fait déjà pour corriger certaines valeurs par exemple (sur une sonde qu’on sait être quelque degrés en dessous de la réalité par exemple).
On a rarement 2 capteurs de température dans la même pièce. Et s’il y a plusieurs équipements de même type ils n’ont pas le même but ou pas exactement le même emplacement normalement.
Pour moi mettre la marque et le modèle dans le nom n’est pas une bonne pratique. Mieux vaut y coller une étiquette si besoin.
Dans tous les cas, sur HA comme ailleurs, plus il y a d’entités plus le système sera chargé et plus les performances se dégraderont.
OK, je vois. donc concernant mes entités, vu que je comptais nommer les virtuelles « Température/Humidité Bureau/Chambre/Salon », si j’applique cela aux entités réelles, j’aurais bien :
sensor.temperature_bureau
sensor.temperature_chambre
sensor.temperature_salon
sensor.humidite_bureau
sensor.humidite_chambre
sensor.humidite_salon
Sans mention de la marque/modèle du périphérique sous-jacent.
En fait, je peux nommer mes périphériques comme je veux (ça tombe dans le « friendly name » et ne touche pas à leur ID hexadécimal, celui qu’on peut lire dans l’URL de l’interface web) car ce qui importe ce sont les noms des entités (sensor.*, lock.*, ) ?
Avoir un périphérique « Prise Toto » et nommer ses entités de manière anonyme (sans marque ni modèle) serait donc suffisant pour ne pas tout perdre aux changements ?
Et c’est HA qui fait le lien entre une entité et le périphérique.
(Je note cependant le bon conseil d’appliquer un ordre « générique→précis » sur les parties du nom du périphérique)
Par contre, pourquoi mentionner « sonde » dans l’ID de l’entité ?
C’est redondant avec le préfixesensor. mais surtout : une température et l’humidité viennent bien logiquement d’une sonde non ?
La mention de « sonde » est plus pertinente pour la notion de signal car c’est bien le signal (de communication) de la sonde qu’on mesure/relève.
Alors que dans les autres cas (température, humidité, ensoleillement, force du vent, mouvement, etc.) c’est bien lié au lieu/emplacement, pas à la sonde.
Oui, c’est pas faux. Mais sensor c’est aussi le type le plus libre. Et donc c’est pas limité uniquement à des appareils physiques qui balancent des mesures. On y mets aussi des templates par exemple.
L’autre avantage c’est de retrouver un lien entre les entités d’un même appareil quand les types sont différents, par exemple chez moi :
ici la chaine volet_sam et fait le lien avec tout ce qui concerne le volet de la salle à manger cover.volet_xxxx => c’est con effectivement (cover/volet), mais input_boolean.volet_xxx ça l’est moins. Et c’est tout l’interet de respecter l’ordre générique => précis.
*.cover_ concerne tous mes volets
*.cover_salon concerne tous mes volets du salon
*.cover_salon_rue concerne le volet du salon coté rue
input_number.cover_salon_rue_memory concerne la position en mémoire du volet du salon coté rue
Quoique…
A force de tester des objets j’ai fini pour les sondes de température par créer un helper min/max sensor.temp_cuisine (par exemple) dans lequel j’ajoute des sondes et j’obtient la moyenne (de fait proche de chaque sonde). Avantage, si l’une n’a plus de pile, ce qui peut être dommageable pour du chauffage par exemple (encore que certains thermostats virtuels le gèrent maintenant) j’ai toujours la température de la pièce, non par un virtuel mais la moyenne…
