Question : Comment récupérer la valeur « Température » d’un appareil connecté en Z2M pour agir sur une prise connectée (d’un chauffage) ce fonction d’une valeur de consigne.
La valeur T° de l’appareil (TH01) est visible dans l’aperçu global (par pièce) et dans le tableau de bord Zigbee2MQTT.
MQTT global (capteur Température et Humidité type TH01) :
" zigbee2mqtt/T°H% 2 - Chambre"
Nom convivial : « T°H% 2 - Chambre »
Topic (?) : T°H% 2 - Chambre Température
Il faut utiliser les template pour récupérer l’état de ton capteur tu trouvera le nom de cet état dans la partie outils développeurs de HA dans l’onglet et etat tu peux trier tes valeur pour retrouver ton état
Bonjour,
Merci pour la réponse, même si j’ai buté - partiellement - sur l’interprétation de celle-ci.
Pourquoi ne pas utiliser vterm ou versatile thermostat ?
Je ne l’exclue pas ultérieurement, mais en tant qu’informaticien, j’essaye d’abord de comprendre les bases sous-jacentes (d’autant plus que j’ignore tout au départ de YAML et que jinja2 m’est plus explicite), quitte à utiliser ensuite un ensemble plus élaboré existant.
J’ai pris l’exemple d’un capteur température, mais la demande est générique car la méthode - une fois comprise - devrait s’appliquer à d’autres capteurs et actionneurs : Présence, 4-boutons, mouvement, ouverture, prises commutées, clavier RFID codé, etc.
En fait, pour ce qui concerne la température j’ai déjà téléchargé versatile thermostat, mais j’en diffère l’usage pour l’instant pour les raisons évoquées plus haut.
J’ai récupéré - via « outils de développement » - (pour la température) :
T°H% 2 - Chambre (capteur)
sensor.tdegh_2_chambre_temperature
: Attributs d’état YAML
Note : capteur renommé pour simplification (soupçon [injustifié] sur le « % » inclus dans le nom pouvant interférer) : Temp_Hum_2_Chambre
(via Zigbee > Appareils )
ET via Paramètres > Appareils et services > MQTT >
… renommage (icone crayon)
(Pourquoi les deux ne sont pas [toujours…] synchronisés ?)
Note : Le capteur 2 semble légèrement différent des autres (achetés ensemble) en ajoutant détection d’ouverture et de vibration n’existant pas chez les autres du même lot !
(Peut-être une erreur dans deux approches (identifications] pour un même capteur)
state_class: measurement
unit_of_measurement: °C
device_class: temperature
friendly_name: Temp_Hum_2_Chambre
Mon erreur initiale vient de la confusion entre l’utilisation du friendly_name (Temp_Hum_2_Chambre) et le nom du capteur avec sa composante temperature
(sensor.temp_hum_2_chambre_temperature)
=> (Résultat)
15.89
Type de résultat: number
Ce modèle écoute les événements de changement d’état suivants :
Entité: sensor.temp_hum_2_chambre_temperature
…
Pour éviter éventuellement à d’autres la confusion initiale sur le nommage (entre les id, les friendly name et les noms utilisés dans les templates), j’ai entouré - en pas à pas (en image) - les endroits ou on trouve certaines des informations utiles :
En espérant que cela puisse être utile pour éliminer certaines confusions.
…
Pour la suite, le test :
{% set tempe = states('sensor.temp_hum_2_chambre_temperature') | float %}
{{ tempe }} {# affichage de variable "tempe" #}
renvoie bien la valeur de température,
suivi d’une tentative de comparaison :
{% set tempe = states('sensor.temp_hum_2_chambre_temperature') | float %}
{{ tempe }} {# affichage de variable "tempe" #}
{% if tempe < 19 %}
{# ultérieurement appel de macro_chauffage ON #}
{% elif tempe > 20 %}
{# chauffage OFF #}
{% else %}
{# Ne rien faire #}
{% endif %}
Renvoie (résultat): 15.41 Type de résultat: number
En bonne voie. Note : L’oubli bête du % final dans une occurrence du test provoque un message un peu difficile à comprendre initialement :
TemplateSyntaxError: unexpected ‹ } ›
car la ligne en défaut n’est pas indiquée.
…
À suivre (pour paramétrer les valeurs de consigne selon un certain nombre de critères)
