Linky - Suivi cout energie

Mon problème

Je suis équipé d’un Lixee connecté à Zigbee2MQTT sur mon HA.
Je réccupère correctement les informations de consommation Heures Creuses (HC) et Heures Pleines (HP).
En lisant plusieurs pages sur les forums, j’ai également réussi à créer des input_number permettant d’ajuster le prix du KwH.

Malheureusement, je ne comprends pas comment il faut faire pour effectuer le calcul en €. Je me perds complètement dans les différents articles que j’ai pu consulter. Une fois que j’aurais compris, je ferai un Tuto sur ce forum car je suis certain de ne pas être le seul à ne pas comprendre :frowning:

Ainsi, est-ce que quelqu’un peut m’aider s’il vous plait avec la liste des variables ci-dessous :

  • Consommation HC en kWh : sensor.lixee_hchc
  • Consommation HP en kWh : sensor.lixee_hchp
  • Prix du kWh en HC : input_number.hc_energy_cost
  • Prix journalier de l’abonnement EDF en HP : input_number.hp_daily_cost
  • Prix journalier de l’abonnement EDF en HP : input_number.hc_daily_cost
  • Prix du kWh en HP : input_number.hp_energy_cost

Mon principal problème est de repartir à 0 tous les jours. Je pense qu’il faut faire avec des utility_meter mais je n’y arrive pas.

Merci de votre aide

Ma configuration


System Information

version core-2022.8.3
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.5
os_name Linux
os_version 5.15.61-v8
arch aarch64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 5000
Installed Version 1.27.2
Stage running
Available Repositories 1131
Downloaded Repositories 27
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 9.0
update_channel stable
supervisor_version supervisor-2022.09.1
agent_version 1.3.0
docker_version 20.10.17
disk_total 457.7 GB
disk_used 18.6 GB
healthy true
supported true
board rpi4-64
supervisor_api ok
version_api ok
installed_addons File editor (5.4.1), Samba share (10.0.0), Duck DNS (1.15.0), Grafana (8.0.2), InfluxDB (4.5.0), Node-RED (13.4.0), Mosquitto broker (6.1.3), SSH & Web Terminal (12.0.2), Z-Wave JS (0.1.74), Studio Code Server (5.4.0), Zigbee2MQTT (1.28.0-1)
Dashboards
dashboards 5
resources 21
views 38
mode storage
Recorder
oldest_recorder_run October 3, 2022 at 4:48 PM
current_recorder_run October 4, 2022 at 5:19 PM
estimated_db_size 2291.29 MiB
database_engine sqlite
database_version 3.38.5
___

Hello

Pense a dire bonjour :wink:

Tu as étais voir le modèle que @Clemalex donne et de l’adapter pour toi

Et sur le blog de @mycanaletto

Oups désolé.:scream:

Bonjour à tous bien sûr. Merci pour ta réponse rapide.
Je n’avais pas vu ce post, je vais le lire immédiatement.

Il y a un point clé que je ne comprends pas dans ce post : le champ sensor.compteur_general_energy correspond à quoi dans un contexte HP et HC ?

Re,

J’ai pas regarder en détaille
Mais comme je te l’ai dit tu dois adapté le code pour toi.

Certaine parti du code te servira a rien , car il c’est pour un shelly

Si ca ce trouve le sensor que tu cites ne te concerne pas pour faire ce que tu souhaites

Le problème avec la manière dont c’est implémenté c’est qu’il faut faire une rotation de HP à HC avec une automation. C’est tout de même génant car avec le Linxee, j’ai accès directement au changement de status.
Ce n’est pas possible d’effectuer un changement avec ce changement de valeur au lieu de le faire à une heure fixe ?

Bonjour ,

J’ai également in Lixee.
J’ai simplement ajouté les deux sensors HC et HP dans l’energy Dashboard puis ajouté le coût du kw/h en statique.

Néanmoins il y a quelques bugs… sur l’affichage et le coût cumulé.


Bonjour je déterre ce topic.
J’ai de mon coté une install assez poussez qui me remonte pas mal d’info. Mon pannel energy fonctionne bien.
J’ai suivi la méthode Canello mais pour moi ce n’est pas viable car les infos de couts (€) doivent être stockées dans des utility meter plutôt que de sensors basiques.
En effet si on change la tarification actuelle en €/kwH des différents tarrifs HC, HP, TEMPO,… ça ajuste l’ensemble des couts alors que l’on veut que les nouveaux tarifs soient prix en compte à partir de maintenant… D’ou l’utilisation de statistiques longs termes calculées en temps réel à partir du tarif actuel.

Là on est d’accord, je pense.
Ce que je n’arrive pas à faire… pour méviter de créer n Utility meter (x groupe de device, 6 tarifs TEMPO,…), j’ai utilisé des Utility meter avec les tariffs.
Je bascule bien l’utility meter sur le bon tarif en bascule HP/HC.
En revanche je coince sur ma ou mes sources d’entrée…
Pour l’instant elles sont un sensor template de type total_increasing €.
Le template est la multiplication du sensor energy total * le tarif de la période en cours.
Ca fonctionne bien même si l’état de ce sensor ne veut rien dire (c’est qu’un montant basé sur un index) en terme de cout. L’important est la variation d’un état sur l’autre uniquement. La je suis bon.

mon principal problème est quand je bascule sur une période tarifaire plus chère par exemple HC à HP, je prend en compte mon autre tarif mais le delta de calcul me génère une variation importante juste à ce moment là qui sont répliquées dans les utility meter…

Voici mon code source du template sensor. meme principe pour chaque groupe d’équipements.
J’ai essayé de jouter avec le last_reset mais ça ne fait rien…

> name: price_energy_total
>       unique_id: price_energy_total
>       state: >
>         {% if is_state('sensor.rt2_teleinfo_ptec', 'HPJW') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hpjw') | float ) | round(2) }}
>         {% elif is_state('sensor.rt2_teleinfo_ptec', 'HCJW') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hcjw') | float ) | round(2) }}
>         {% elif is_state('sensor.rt2_teleinfo_ptec', 'HPJB') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hpjb') | float ) | round(2) }}
>         {% elif is_state('sensor.rt2_teleinfo_ptec', 'HCJB') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hcjb') | float ) | round(2) }}
>         {% elif is_state('sensor.rt2_teleinfo_ptec', 'HCJR') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hcjr') | float ) | round(2) }}
>         {% elif is_state('sensor.rt2_teleinfo_ptec', 'HPJR') %}
>           {{ ( states('sensor.linky_energy_global') | float * states('input_number.cout_kwh_hpjr') | float ) | round(2) }}
>         {% else %}
>         {% endif %}
>       unit_of_measurement: "€"
>       #icon_template: mdi:currency-eur
>       #device_class: monetary
>       state_class: total_increasing   # pas besoin car le cout n'est pas représentatif
>       availability: "{{ states('sensor.linky_energy_global') | is_number and 
>                         not 'unavailable' in  states('sensor.rt2_teleinfo_ptec') }}"
>       # pas sur que ca soit nécessaire
>       attributes:
>         last_reset: "{{ '2024-01-30 12:17:00+01:00' }}"

En fait je pense qu’il me faudrait au final un sensor, remis à 0 à chaque changement de période tarifaire et réincrémenter progressivement le cout qui partirait de 0€ avec le bon tarif.
Pour ça plutot que de calculer le cout dans ce sensor directement, il faudrait que je puisse extraire juste la différence entre la valeur de maintenant et cette précédente.
Et que j’ajoute ça à mon utility meter.
Ou alors autre solution, calculer le cout par rapport aux utilimeter energy qui fonctionne bien ete qui sont utililsé pour le pannel energy

Pas sur d’être clair merci.
PS : en fait j’essaye de refaire le principe du même module CONSO ELEC dans jeedom

EDIT : je me demande si faut pas que je passe par un utility meter spécifique basé sur un reset à chaque changement de période. Comme ça je suis sur que je reprends de 0 et cette données sert à alimenter mes utilimeter par cycle classique (Journalier,n Hebdo,…) reseté à minuit