Affichage de la consommation d'eau dans "Energie" du tableau de bord depuis un compteur KNX

Pulpy-Luke · Décembre 2, 2022, 11:19

Pas qu’une impression, le doublon est bien là

Mais bon on va dire que c’est pas ça DANS ta config

Normal c’est à toi d’écrire le truc…
Simple copié/collé comme le contenu du template

{{states('sensor.compteur_eau_p') | multiply(0.001) }}

Oui ça c’est clair. Ce qui l’est moins c’est le format qu’utilise HA dans ce cas pour stocker la valeur .
Si c’est une chaine (string), ça peux poser problème de mélanger lors de ta division avec un nombre à virgule (float)
D’ailleurs, naturellement moi, soit je divise par 0.0001 ou je multiplie par 1000 pour convertir des m3 en litres…

Ives · Décembre 2, 2022, 11:34

Dans les messages précédents, j’ai utilisé l’option Paramètres/ teste préformaté de l’éditeur de message pour copier/coller le code. Voici en collant directement ; il n’y a pas de double espace

name: eau
unit_of_measurement: « L »
state_class: total_increasing
device_class: water
state: « {{states(‹ sensor.compteur_eau_p ›) | multiply(0.001) }} »

Je n’avais jamais utilisé l’outil des templates !

Pulpy-Luke · Décembre 2, 2022, 11:36

Oui… c’est pas un interpréteur YAML mais un pour le JINJA (comme le message à propos de la doc le confirme)
Donc il faut seulement coller la ligne du ‹ calcul ›… CF mon message précédent
Un exemple qui traine chez moi

Et là aussi tu as une erreur

Donc la valeur issue de KNX n’est pas bonne à mon avis

Ives · Décembre 2, 2022, 11:54

Tu as raison concernant le format

Pour l’instant je laisse tomber la conversion

J’ai redémarré HA

J’ai créé un entrée Conso eau3 de type « Compteur de sevices publics » avec comme capteur d’entrée sensor.eau

Lorsque je veux ajouter une source, Conso eau 3 n’est pas proposé

Pulpy-Luke · Décembre 2, 2022, 11:59

Moi je mettrais un truc du genre
{{states('sensor.compteur_eau_p') | float(0) * 1000 |int(0) }}
Mais avant il faut trouver pourquoi sensor.compteur_eau_p ne remonte rien

Normal, c’est pas typé !

      unit_of_measurement: "L"
      state_class: total_increasing
      device_class:  water

Mais c’est pas ça le souci…

Le souci c’est la valeur du KNX.
Si sensor.compteur_eau_p ne remonte pas un chiffre (ou une chaine de caractères qui y ressemble) tu pourras toujours essayer de transformer, ça ne donnera rien de plus que ce que tu as déjà maintenant

ça c’est pas normal

Et c’est pas cohérant avec ça (plus vieux)

Il devrait y avoir le 800 dans les 2 cas

Ives · Décembre 2, 2022, 3:59

J’ai avancé un peu en créant dans mon module logique knx une conversion de données le volume en m3 (DPT 14.076) est converti en litres (DPT 12.1200).
knx.yaml

#Compteur eau (litres)
  - name: compteur_eau2_litres
    state_address: "9/7/12"
    type: "volume_liquid_litre"

configuration.yaml

- name: eaulitres
      unit_of_measurement: "L"
      state_class: total_increasing
      device_class: water
      state: "{{states('sensor.compteur_eau2_litres') }}"

Je récupère dans « eaulitres » l’index du compteur en litres

J"ai créé une entrée « Conso eau litres2 » de type « Compteur de services publics » avec comme capteur d’entrée eaulitres

Lorsque je veux ajouter une source, Conso eau litres2 n’est pas proposé.

Pulpy-Luke · Décembre 2, 2022, 4:19

Attention, l’indentation normale d’un yaml c’est 2 espaces, pas 6…

Ok donc là on a 1 int ou un string, mais la valeur est là on dirait

Super mais tu ne partages pas sa config, donc je ne peux rien dire.
Enfin si ,on voit une notion de cron dans l’écran un peu plus bas et que c’est pas bien courant. Et en plus il manque sa device_class: water…
Et comme tout à l’heure, tu as valeur unknown à la place du state.

Donc Normal que ça ne marche pas pour moi… HA ne sait même pas que c’est de l’eau…

ça je connais pas…

du coup, ça démontre quoi ton exemple ? Très résumé, de mon point de vue : tu as refait (avec les mêmes erreurs) la même chose que ce qui ne marchait déjà pas avant…

Ives · Décembre 2, 2022, 4:36

La différence c’est que j’ai déjà une valeur de l’index eau knx qui remonte dans un sensor HA !

configuration.yaml (complet)

homeassistant:
  packages: !include_dir_named knx

template:
  - sensor:
    - name: gaz2
      unit_of_measurement: "m³"
      state_class: total_increasing
      device_class: gas
      state: "{{states('sensor.compteur_gaz3') | multiply(1.000) }}"

    - name: eaulitres
      unit_of_measurement: "L"
      state_class: total_increasing
      device_class: water
      state: "{{states('sensor.compteur_eau2_litres') }}"

 

  # Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

# Text to speech
tts:
  - platform: google_translate

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

Ives · Décembre 2, 2022, 4:43

C’est ce qui permet à partir d’un sensor d’avoir des compteurs heure, jour, semaine mois, année
HA fait les calculs et stocke les valeurs

Pulpy-Luke · Décembre 2, 2022, 4:49

OK donc tu ne fais pas un truc en YAML mais un truc via l’interface. C’est un détail important.
Tu l’alimentes avec quoi ?

EDIT : ça sent le bug

alors qu’index à la base c’est bien quelque chose…

ça vaudrait le coup de le faire manuellement, mais là je découvre

Ives · Décembre 2, 2022, 5:15

En yaml il y a ce que j’ai mis dans le knx et dans le configuration.yaml

Dans ton exemple on voit que tu utilises une intégration veolia
Dans mon cas les index sont dans des compteurs knx

Pour l’électricité c’est pris en compte directement car il dispose du type « active_energy » (je suppose)
knx.yaml

#Compteur elec 
  - name: compteur_elec
    state_address: "9/7/0"
    type: "active_energy"

ensuite depuis Paramètres/Appareils et services/Entrées , je créé une nouvelle entrée « Conso elec" de type "Compteur de services publics » avec comme capteur d’entrée sensor.compteur_elec

Pour le gaz
knx.yaml

#Compteur gaz 
  - name: compteur_gaz3
    state_address: "9/7/1"
    type: "volume"

pas de type gas
donc passage par un template dans le configuration .yaml

template:
  - sensor:
    - name: gaz2
      unit_of_measurement: "m³"
      state_class: total_increasing
      device_class: gas
      state: "{{states('sensor.compteur_gaz3') | multiply(1.000) }}"

ensuite depuis Paramètres/Appareils et services/Entrées , je créé une nouvelle entrée « gaz2" de type "Compteur de services publics » avec comme capteur d’entrée sensor.gaz2

Pour l’eau, voir mon message précédent mais c’est le même principe que pour le gaz sauf que j’ai un message d’erreur indiquant que la device-class : water n’est pas acceptée

Pulpy-Luke · Décembre 2, 2022, 5:19

C’est pas fondamental, j’ai comme toi une valeur numérique dans son état.

Tout à fait

Par ailleurs, j’ai refait la même chose ici (en plus de faire un utility_meter (c’est le nom des compteurs publique ) et ça donne exactement la même chose que via l’ui

utility_meter:
  veolia3:
    source: sensor.veolia_last_index
    name: veolia3
    cycle: daily

Pulpy-Luke · Décembre 2, 2022, 5:23

J’ai l’impression qu’il y a plusieurs anomalies et que c’est techniquement coincé

L’utility meter n’hérite pas de l’infos device_class quand il est crée (via l’ui ou en yaml)
Le calcul de la valeur de l’utility meter ne fonctionne pas
Le sensor template (une alternative officielle) n’accepte pas les device_class: water

D’ailleurs il y a 1 an, tu avais presque les mêmes questions

Ives · Décembre 2, 2022, 5:50

Oui et de ce côté j’ai avancé mais la gestion avec influx db et grafana est prise de tête.
J’utilise Utility meter pour la consommation d’eau journalière

La nouvelle carte Energie de HA est super et permet une navigation directe heure, jour, semaine mois et année.

Je pensais qu’il y avait moyen de contourner ce problème de device_class mais visiblement ce n’est pas le cas.
J’espère qu’il y aura une évolution car KNX est le seul système domotique approuvé en tant que :

Norme Internationale (ISO/IEC14543-3),
Norme Européenne (CENELEC EN50090 et CEN EN 13321-1 et 13321-2),
Norme Chinoise (GB/Z 20965),
Norme ANSI/ASHRAE (ANSI/ASHRAE 135).
et la surveillance de la consommation d’eau devient de plus en plus nécessaire !

Pulpy-Luke · Décembre 2, 2022, 5:57

Le knx c’est bien quand c’est prévu par dès le départ.
Quant à la norme, c’est pas aussi utile pour un particulier que pour un pro

Ives · Décembre 3, 2022, 1:29

Oui mais le fait qu’il soit normé au niveau mondial montre que ce n’est pas « confidentiel ».

Cette partie Energie fonctionne très mal car je viens de faire un copié/collé pour le gaz dans une autre instance de HA et ça ne fonctionne pas. Il n’y a que l’elec qui ne pose pas de problème.

Pulpy-Luke · Décembre 3, 2022, 1:39

C’est pas forcément la norme qui fait que c’est confidentiel ou pas…
Zigbee c’est pas confidentiel

Ives · Décembre 3, 2022, 1:45

Je n’ai pas dit que ce qui n’était pas normé était confidentiel.

Pulpy-Luke · Décembre 3, 2022, 2:38

ça reste quand même assez européen à mon avis, peu importe la norme obtenue.
Son gros avantage c’est que c’est robuste, c’est un fait qui compte lors d’un choix sur une solution.
Par contre si c’est pas prévu un minimum avant (pendant la construction ou la reno), c’est compliqué à installer dans une maison

Ives · Décembre 3, 2022, 5:21

Bien d’accord, uniquement pour une construction ou une grosse rénov.

8 ans que c’est installé chez moi et pas un bug. J’utilise HA essentiellement pour la supervision, l’accès distant et quelques fonctions secondaires comme la météo, la carte des poubelles, …

Jai installé un contrôleur logique évolué KNX et HA n’est utilisé que pour le passage des paramètres.

Il y a deux mois, nous étions en vacances et il y a une coupure d’électricité de plus de 2 heures ( c’est très rare) et l’onduleur est arrivé au bout de son autonomie.
Lorsque le réseau a été rétabli, HA n’a pas redémarré j’ai été très content, notamment, que la gestion de la piscine soit confiée au knx.