Mémorisation de la valeur d'un sensor dans un input_number

Entraide Home Assistant
1

Bonjour,
Dans le cadre d’une automatisation plus complexe, je souhaite juste recopier la valeur d’un sensor dans un input_text quand la valeur du sensor change.
J’ai écrit l’automatisation de test suivante via le GUI, pourtant très basique, mais elle ne fonctionne pas :

alias: 'IPX800 : calcul conso'
description: ''
mode: single
trigger:
  - platform: state
    entity_id: sensor.compteur
action:
  - service: input_number.set_value
    data:
      value: {{states('sensor.compteur')|float}}
    target:
      entity_id: input_number.memo_compteur

J’ai toujours une erreur du type :

Error while executing automation automation.calcul_conso: expected float for dictionary value @ data['value']

J’ai bien testé mon template {{states(‹ sensor.compteur ›)|float}} dans l’outils de développement et il fonctionne.
Je n’ai pas vu de data_template qui serait à mettre à la place de data dans la doc.

Auriez vous une idée ?
Merci.

2

Essaie d’ajouter des guillemets :

value: "{{states('sensor.compteur')|float}}"

Et je suis pas sûr de la nécessité de convertir en float,essaie de l’enlever si la première ne suffit pas.

3

Mon dieu, oui, j’ai oublié les quotes et je passais systématiquement à côté !! Un grand merci @Clemalex. Je reste très impressionné par ta capacité à aider tout le monde avec tant de pertinence.

Home Assistant a beaucoup de bon côtés, mais je trouve que toutes ces syntaxes mélangeant YAML - template Jinja2 et javascript sont très lourdes, souvent peu homogènes et exotiques. L’UI des automations n’est pas terrible. Je persévère à utiliser les automations plutôt que nodered sauf pour traiter des flux complexes. Mais je vais regarder de près ce qu’on peut faire avec l’intégration « python script », et surtout pyscript avec ses decorators permettant de spécifier les triggers des automations. Certes question de culture. Mais la syntaxe est plus élégante et colle aux pratiques usuelles du développement, ce avec le langage le plus utilisé au monde.

4

:hacf:
:heart:

tu as quelques exemples sur le forum (Installer la carte Météo France - #46 par Clemalex, ✅ Carte Timer, Résultats de recherche pour « python_script » - Home Assistant Communauté Francophone) mais qui ne sont pas représentatif de la puissance de l’intégration mais permettent de les introduires en douceur.

Pas eu la nécessité encore de l’utiliser, mais je n’en ai lu que du bien :+1:

En fait, de base, le produit ne comprends que du JINJA2 pour la partie code et du YAML pour la partie configuration.
Mais si on veux faire des choses plus poussées que ce que nous permet HA nativement, on ajoutes des scripts JAVASCRIPT qui veulent qu’on leur parle en … javascript.

Tu n’es pas le seul et même moi encore j’ai des doute, mais le doute existe simplement par le fait que certains développeurs de plugins essayent de tout transcrire en YAML pour justement n’avoir pas à jongler entre les langages, mais cela prends du temps et ce n’est pas toujours possible…

En tout cas, ravi d’avoir pu aider :+1:

1 « J'aime »
5

Très intéressant tes retours, merci. Je vais essayer pyscript mais le problème serait d’être isolé (peu de partages) et de ne pas être standard avec HA. Ce n’est jamais très bon et me fait hésiter.

Je viens seulement de comprendre pourquoi je passais toujours à côté de la bonne syntaxe avec les quotes.
Ce type de syntaxe, que j’avais vu, marche aussi, et sans les quotes cette fois. En mettant « >- » pour aller à la ligne, il n’y a ensuite plus besoin des quotes.

service: input_number.set_value
data:
  value: >-
    {{states('sensor.ipx800_compteur_electrique')|float}}
target:
  entity_id: input_number.ipx800_compteur_electrique_1

Je découvre doucement. Mais tout cela n’est pas toujours très intuitif…

2 « J'aime »
6

Bonjour,

Et avec NodeRed ?

Perso je n’ai pas assez d’expérience pour juger, mais j’apprécie NodeRed pour son coté graphique et « organisé »

Bon, j’ai encore du boulot avant de maitriser !

7

Bonne remarque. « Node-Red versus Automation » ferait l’objet d’un sujet à part entière. Je te donne quand même mon avis ici, qui n’engage que moi, suite à mes quelques mois d’expérience HA.

Node-Red est orienté No code (ou Low Code) et offre d’énormes possibilités, en particulier pour des flux complexes. La mise au point est facile. L’intégration HA est bien faite. Enfin effectivement la représentation graphique permet d’appréhender la logique de flux complexes. Il est relativement facile d’entrer dans Node-Red. Enfin, il est générique et utilisable ailleurs que dans HA.

Automation est plus difficile à appréhender si on sort de ce que propose l’UI. Moins de possibilités que NodeRed. L’interface graphique a des lacunes et n’est pas très sexy. Syntaxe YAML JINJA2 pas intuitive et demandant un investissement.
MAIS quand on maîtrise la syntaxe, il est possible de rapidement créer ses règles de type trigger-condition-actions (soit 90% des cas) en souvent une dizaine de lignes. Le YAML permet l’échange et les sources restent très succincts, lisibles et modifiables rapidement (contre ouverture-fermeture des noeuds avec pleins d’options dans node red). Les développeurs apprécieront pour GIT. Les blue print permettent de mutualiser du code. Automation est probablement plus léger en ressource que Node-red. Enfin une entité est créée permettant d’activer/désactiver simplement une automation dans Lovelace ou via un service (plus pénible dans Node-Red).
Et pour conclure, j’ai la conviction que les automations vont évoluer vite.

Donc pour moi je persévère sur automation pour les règles type trigger-condition-actions.
J’utilise NodeRed uniquement pour les flux complexes (à cause logique ou contenu du flux), ou quand les noeuds proposés permettent de faire des choses difficiles à faire ailleurs.
En parallèle, de par ma culture d’informaticien, je regarde comment utiliser python.

Chacun pourra faire pencher d’un côté ou de l’autre la balance en fonction de sa culture ou ses attentes.

2 « J'aime »
8

D’autre exemple en fin de ce post :+1:

1 « J'aime »