Comptage energie

[XeNo]

sensor.tarif_en_cours
C'est la sortie en mode chiffre (0 à 10) du TE332 (TIC)

Après l'automation sur le TIC est faite, je l'ai publiée déjà.
Ce qui ne fonctionne pas c'est 1 automation pour tout, là j'ai 6 automations (HC Bleu/HC Blanc/HC Rouge/HP Bleu/HP Blanc/HP Rouge)

[Ives]

sensor.tarif_en_cours
C'est la sortie en mode chiffre (0 à 10) du TE332 (TIC)

Après l'automation sur le TIC est faite, je l'ai publiée déjà.
Ce qui ne fonctionne pas c'est 1 automation pour tout, là j'ai 6 automations (HC Bleu/HC Blanc/HC Rouge/HP Bleu/HP Blanc/HP Rouge)

Le ton premier post de code c'est :

Code :

alias: Tempo Rouge HP
description: ""
triggers:
- at: "06:00:00"
  variables:
    tariff: Rouge HP
  trigger: time
conditions:
- condition: or
  conditions:
    - condition: state
      entity_id: sensor.rte_tempo_prochaine_couleur

Ensuite tu indiques que tu as remplacé le trigger par :

Code :

triggers:
- trigger: state
  entity_id:
    - sensor.tarif_en_cours
  variables:
    tariff: Bleu HC
conditions:
- condition: state
  entity_id: sensor.tarif_en_cours
  state: "5"

Après la partie trigger, ce n'est pas "raccord" entre les deux (sans parler du tarif Rouge HP dans un cas et  Bleu HC dans l'autre). C'est pour cette raison que je t'avais demandé de poster une version complète (pour un des tarifs)

[XeNo]

C'est sensiblement pareil, c'est le nom de l'automation qui va compter (et encore, on peut l'appeler "toto").
Il doit juste y avoir raccord entre la variable "tariff" qui est en mode texte qui sert aux utility meter et "tarif_en_cours" qui vient du knx (du TIC) (tu peux utiliser un sensor de texte que tu set depuis HA en fonction du chiffre du TIC si tu préfères)
Ensuite il faut créer une automation par tarif comme expliqué plus haut. (HC Bleu/HC Blanc/HC Rouge/HP Bleu/HP Blanc/HP Rouge)

Voici donc un exemple limité dans les entités à basculer pour HP Bleu

Code :

alias: Tempo HP Bleu
description: ""
triggers:
 - trigger: state
   entity_id:
     - sensor.tarif_en_cours
   variables:
     tariff: Bleu HP
conditions:
 - condition: state
   entity_id: sensor.tarif_en_cours
   state: "8"
actions:
 - target:
     entity_id: select.energy_total_usage_daily
   data:
     option: "{{ tariff }}"
   action: select.select_option
 - target:
     entity_id: select.energy_total_usage_weekly
   data:
     option: "{{ tariff }}"
   action: select.select_option
 - target:
     entity_id: select.energy_total_usage_monthly
   data:
     option: "{{ tariff }}"
   action: select.select_option
 - target:
     entity_id: select.energy_total_usage_yearly
   data:
     option: "{{ tariff }}"
   action: select.select_option
.......
.......
.......
mode: single

[XeNo]

Je rencontre un soucis plutôt embêtant sur le comptage d'énergie.
Lorsque j'ai une coupure d'électricité (ce qui est très rare), lorsque cela repart, le TE332 renvoie la valeur d'index total une fois avant de reprendre son comptage..
Bien évidemment, cela fausse totalement la récupération des données et les simulations de tarification..

Comment vous gérez cette problématique de votre côté ?

Merci !

[XeNo]

Yves, tu n'as pas de soucis d'index lors des coupures électriques ?

[Ives]

Non pas de problème mais as-tu utilisé availability comme indiqué ici

[XeNo]

Merci Yves, j'ai jeté un oeil mais ça ne semble pas correspondre à mon fonctionnement.

J'ai des utility meter par exemple :

Code :

######  Total journalier
 energy_total_usage_daily:
   source: sensor.energie_totale
   name: "Energie journaliere Tempo"
   cycle: daily
   tariffs:
    - Bleu HP
    - Bleu HC
    - Blanc HP
    - Blanc HC
    - Rouge HP
    - Rouge HC

Cela me génère ensuite 6 sensors sur lesquels je n'ai pas la main.
Et sur ces sensors, je crée des compteurs de service public dans les "Entrées" HA. Qui n'ont pas de paramètre non plus.
Je n'ai donc pas d'endroits où insérer les availibility des sensors.

Ce que je ne comprends pas, c'est qu'on dirait que c'est le TE332 qui renvoie l'index total (sur le canal de l'utility_meter actif a ce moment là, dans l'exemple en dessous j'étais en Bleu HP donc c'est lui qui a pris) comme on peut le voir ici lors de ma dernière coupure électrique (la source de l'utility_meter : sensor.energie_totale vient d'une GA du TE332)
   
   

[XeNo]

Encore une coupure qui me foire complétement mon suivi d'énergie..

   

La solution de l'ajout de "availibility" ne fonctionne pas, il me dit que l'option n'est pas compatible avec un template sensor


J'ai ajouté dans les utility_meter pour voir :
always_available: true

mais je n'y crois pas franchement. C'est écrit qu'il mémorise la valeur et attend que l'entité redevienne valable (even if the source entity is unavailable or unknown.)
Sauf que si je regarde l'historique au moment de la coupure, j'étais à 9792 Wh puis je prends un pic au rallumage de 29 784 608 Wh puis il continue de recompter comme avant. Donc techniquement, je chope une valeur. Totalement erronée mais j'en chope une (c'est celle de l'index total vu le chiffre de 29 784 kWh..)

J'ai vraiment l'impression que cela vient du TE332 pourtant je vois rien dessus..

Mon dashboard energy HA est basé sur ces utilitymeter :
"Energie journaliere Tempo Bleu HC" par exemple

Mes utilitymeter sont construits sur ce sensor :

Code :

utility_meter:

######  Total journalier
 energy_total_usage_daily:
   source: sensor.energie_totale
   name: "Energie journaliere Tempo"
   always_available: true
   cycle: daily
   tariffs:
    - Bleu HP
    - Bleu HC
    - Blanc HP
    - Blanc HC
    - Rouge HP
    - Rouge HC

qui est un sensor knx :

Code :

 - name: "Energie Totale"
   state_address: "9/6/0"
   type: active_energy
   state_class: total_increasing

Si quelqu'un a une idée, franchement je sèche sur le pourquoi du comment..

Merci d'avance,

[Ives]

Je ne vois pas comment le TE332 pourrait foirer et si tu monitor avec ETS ton registre principal, tu devrais pouvoir le constater en faisant une coupure réseau (avec le PC sur onduleur !)

C'est, AMHA, le principe de créations des 6 sensors qui est fragile. Tu devrais :
- soit faire la lecture des bits de tarification comme indiqué ici par Nitro24  (j'avais testé et c'est une bonne solution mais j'étais satisfait de ma solution Node-Red)
- soit utiliser Node-Red
Avec ces deux solutions les 6 index des tarifications sont créés directement lors de la lecture du TE332.

[XeNo]

Oui je pense que tu as raison, le TE332 n'est pas en cause mais y a quand même quelque chose de bizarre.

J'ai déjà redemarré HA des centaines de fois, cela n'a pas d'impact.
J'ai déjà reprogrammé le TE332 plusieurs fois, après son reboot, aucun impact.
J'en viens à me demander si ce n'est pas le linky qui fait ça du coup. Qui renvoie son index total sur le TIC, le TE l'envoie sur le 9/6/0 et HA enregistre sur la valeur courante (Blanc HP au moment de la coupure d'aujourd'huir).
C'est vraiment étrange.

Je peux eventuellement faire un test avec un onduleur sur KNX + HA puis couper le réseau. Si cela n'a pas d'impact c'est que ca vient bien du linky.
Question bete, comment on peut vérifier qu'on est bien en mode historique sur le linky ? En théorie c'est bon mais bon dans le doute.. (je viens de vérifier, on le voit sur le linky) Par contre la valeur renvoyée sur ma conso après coupure correspond exactement à "Index Mid" après le numéro de série sur le linky (29 776 kWh)

Voici ma capture d'objets du TE332 :
   

[Ives]

Le Linky ne change pas de mode tout seul ; c'est une procédure effectuée par Enedis.

Pour l'index c'est normal il est toujours croissant ; ensuite c'est le compteur qui, pour une période donnée (jour, semaine, mois , année) effectue la différence entre la valeur de l'index en fin de période et celui en début de période. Dans les deux solutions évoquées dans mon message précédent, dans lesquelles on crée six index à partir de la lecture de l'index du TE332 en mode 6 octets, me semble incontournable pour disposer d'une solution robuste.

Pourquoi n'utilises-tu pas l'objet 4 (Comptage entrée télé-info Energie totale) en reliant la sortie TIC du Linky à l'entrée TIC du TE332 ?

[XeNo]

Oui mais je voulais voir s'il était toujours en mode historique et c'est le cas donc tout va bien (on le voit sur le linky).

Pour l'index c'est normal il est toujours croissant ; ensuite c'est le compteur qui, pour une période donnée (jour, semaine, mois , année) effectue la différence entre la valeur de l'index en fin de période et celui en début de période.

Ca oui je comprends bien mais pourquoi il renvoie la valeur index mid lorsqu'il redémarre ?

Pourquoi n'utilises-tu pas l'objet 4 (Comptage entrée télé-info Energie totale) en reliant la sortie TIC du Linky à l'entrée TIC du TE332 ?

Je ne comprends pas ?
La il me renvoie l'index mid au redémarrage ce qui n'est pas logique non ?

Mon TE332 est bien relié en TIC, j'ai mis la capture des objets du TE avec ce que j'utilise. Je n'ai pas d'objet 4 dans la liste

[Ives]

Le compteur Linky enregistre l'index "mid" (celui de 12h00) et le conserve en mémoire. Après une coupure de courant, lorsque le Linky redémarre, il peut retransmettre cet index en même temps que les autres données de téléinfo mais la question c'est comment accèdes-tu à cet index qui n'est pas dans la trame TIC mais sur l'API Enedis ?

[XeNo]

C'est la toute la question, comme j'expliquais :


Mon dashboard energy HA est basé sur ces utilitymeter :
"Energie journaliere Tempo Bleu HC" par exemple

Mes utilitymeter sont construits sur ce sensor : sensor.energie_totale

Code :

utility_meter:

######  Total journalier
energy_total_usage_daily:
  source: sensor.energie_totale
  name: "Energie journaliere Tempo"
  always_available: true
  cycle: daily
  tariffs:
   - Bleu HP
   - Bleu HC
   - Blanc HP
   - Blanc HC
   - Rouge HP
   - Rouge HC

qui est un sensor knx qu'on retrouve ici :

Code :

- name: "Energie Totale"
  state_address: "9/6/0"
  type: active_energy
  state_class: total_increasing

Qui lui vient du TE332 qui est branché sur le TIC :
   

Mon linky est un SAGEMCOM

Je peux voir ta config TE332 ?
Moi je n'ai pas l'objet 4 dont tu parles

[Ives]

Je peux voir ta config TE332 ?
Moi je n'ai pas l'objet 4 dont tu parles

Voici la configuration pour la consommation générale :

Paramètres TE332
   

GA
   

NR (j'ai effacé les noeuds de Debug pour plus de lisibilité)
   

Les 6 index sont ensuite utilisés dans HA pour afficher les consommations

[XeNo]

Merci,
Donc ton objet 4 est en 6 octets du coup ? Ca ne marcherait plus chez moi si je fais ça, il faudrait que j'intègre ta logique nodered et que je refasse tout.
Ou il faut que je trouve le moyen de scinder les 4 octets sans le tarif pour que ça fonctionne tel quel.

Mais tu n'avais pas fait une automation tempo ? A quoi elle te sert vu que tu scindes tes compteurs avec nodered ?

[Ives]

Merci,
Donc ton objet 4 est en 6 octets du coup ? Ca ne marcherait plus chez moi si je fais ça, il faudrait que j'intègre ta logique nodered et que je refasse tout.
Ou il faut que je trouve le moyen de scinder les 4 octets sans le tarif pour que ça fonctionne tel quel.
Mais tu n'avais pas fait une automation tempo ? A quoi elle te sert vu que tu scindes tes compteurs avec nodered ?

Oui l'objet 4 est sur six octets et avec Node-red j'obtiens un index par tarif.
Tu n'es pas obligé d'utiliser Nodered en utilisant la méthode de Nitro24.
L'automatisation Tempo permet d'affecter le tarif en cours pour le calcul des consos jour, semaine mois et année.

[XeNo]

Hello,

Bon donc je suis en train de préparer.
Au final, je n'ai pas grand chose à toucher.
Je crée les 6 input number
J'ajoute le template pour générer l'energie totale
J'ajoute l'automation

Ensuite je n'ai qu'à basculer mon TE332 en 6 octets et relinker les GA.
Modifier l'energie totale utilisée dans mes utilitymeter actuels

Ca c'est la théorie, par contre je ne trouve pas quel type de "template" il utilise. Le formatage qu'il a ne correspond à rien de ce que j'ai. Ce n'est pas un template sensor .
Voila son code, chez moi ca ne fonctionne pas en template sensor, je suis d'ailleurs pas formaté comme ça pour mes template sensor.

Son code :

Code :

# Chauffage
   - name: Compteur Energie Chauffage
     unique_id: ec237bc5-f71b-4b0c-a1c6-523fa6313079
     state: "{{ [ states('input_number.energie_chauffage_hc_bleu'),
                  states('input_number.energie_chauffage_hp_bleu'),
                  states('input_number.energie_chauffage_hc_blanc'),
                  states('input_number.energie_chauffage_hp_blanc'),
                  states('input_number.energie_chauffage_hc_rouge'),
                  states('input_number.energie_chauffage_hp_rouge')] | map('float') | sum | multiply(0.001) }}"
     unit_of_measurement: kWh  
     device_class: energy
     state_class: total_increasing

Voici un exemple de template sensor chez moi :
pas de tiret, friendly_name au lieu de name, value template au lieu de state.

Code :

   cout_energie_partielle:
     friendly_name: "Cout energie partielle"
     unit_of_measurement: "€"
     value_template: "{{ ((states.sensor.energie_partielle.state | float *0.2062/1000)) | round(2) }}"

Vous sauriez me dire ce que c'est comme code qu'il utilise ?

Merci d'avance,

[Ives]

Pas certain de comprendre le problème ; avec state il fait le calcul directement (dans state) et toi tu passes par un template

[XeNo]

Je ne sais pas où mettre ce bout de code, HA n'en veut pas.
Dans un template sensor ca ne fonctionne pas
Dans un sensor pur ca ne fonctionne pas non plus

Du coup je ne sais pas 

[Ives]

C'est celui-ci qui n'est pas accepté ?

Code :

- name: Compteur Energie Chauffage
    unique_id: ec237bc5-f71b-4b0c-a1c6-523fa6313079
    state: "{{ [ states('input_number.energie_chauffage_hc_bleu'),
                 states('input_number.energie_chauffage_hp_bleu'),
                 states('input_number.energie_chauffage_hc_blanc'),
                 states('input_number.energie_chauffage_hp_blanc'),
                 states('input_number.energie_chauffage_hc_rouge'),
                 states('input_number.energie_chauffage_hp_rouge')] | map('float') | sum | multiply(0.001) }}"
    unit_of_measurement: kWh  
    device_class: energy
    state_class: total_increasing

[XeNo]

Tout à fait oui

[Ives]

Je pourrai tester ce code demain mais je préfère remonter une VM HA de test sur mon NUC pour le faire.
Si tu avances aujourd'hui, postes ici pour que je ne passe pas du temps pour rien.

[XeNo]

Je viens de trouver.
En fait il existe 2 formats de template.
Le legacy (que j'utilise) de type

Code :

- platform: template
 sensors:
   vitesse_vent_kmh:
     friendly_name: "Vitesse Vent Km/h"
     unit_of_measurement: "km/h"
     value_template: "{{ ((((states.sensor.vitesse_vent.state) | float *3.6 )) | round(2)) }}"

Injection depuis le configuration.yaml de type 

Code :

sensor: !include sensor.yaml

Et la nouvelle méthode de template de type :

Code :

sensor:
 - name: compteur_energy_totale_kwh
   unique_id: ec237bc5-f71b-4b0c-a1c6-523fa6313079
   state: "{{ [ states('input_number.energie_totale_hc_bleu'),
              states('input_number.energie_totale_hp_bleu'),
              states('input_number.energie_totale_hc_blanc'),
              states('input_number.energie_totale_hp_blanc'),
              states('input_number.energie_totale_hc_rouge'),
              states('input_number.energie_totale_hp_rouge')] | map('float') | sum | multiply(0.001) }}"
   unit_of_measurement: kWh  
   device_class: energy
   state_class: total_increasing

Avec une injection depuis le configuration.yaml de type 

Code :

template: !include template.yaml

La HA ne rale plus, a voir si le template est ok maintenant

[XeNo]

On est d'accord que le format 6 octets, les 4 octets d'energie totale ne change pas en fonction du tarif ? C'est un cumul constant et c'est l'octet tarif qui varie ?