Compteur énergie selon état d'une entité

Bonjour,

J’ai besoin de votre aide pour créer un compteur d’énergie, mais qui ne compte que lorsqu’une autre entité est dans un certain état.
J’ai un compteur en Wh sensor.msunpv_enrball qui me remonte l’énergie envoyée par mon routeur solaire au ballon d’eau chaude. Il est remis à 0 par le routeur tous les jours à 00:00. Il m’arrive de faire des marche forcées (uniquement en HC, hors période de production solaire) via le routeur et ce compteur ne distingue pas l’énergie forcée de l’énergie solaire routée.
J’ai un sensor sensor.ecu_inverters_online qui m’indique si mon onduleur solaire est ON ou OFF (etat 0 ou 1).
Comment pourrais-je créer un compteur qui reprend les infos de sensor.msunpv_enrball mais seulement si sensor.ecu_inverters_online est à 1 et éventuellement pouvoir en garder des statistiques d’énergie routée par jour / mois / année ?
Ca ne me semble pas gérable via l’UI et les compteurs de services publics. Je sèche.

Ma configuration


System Information

version core-2025.1.4
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.13.1
os_name Linux
os_version 6.6.73-haos
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 4994
Installed Version 2.0.5
Stage running
Available Repositories 1578
Downloaded Repositories 31
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 14.2
update_channel stable
supervisor_version supervisor-2024.12.3
agent_version 1.6.0
docker_version 27.2.0
disk_total 30.8 GB
disk_used 6.9 GB
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization kvm
board ova
supervisor_api ok
version_api ok
installed_addons Terminal & SSH (9.16.0), Samba share (12.4.0), Mosquitto broker (6.5.0), Samba Backup (5.2.0), teleinfo2mqtt (9.0.4), ZeroTier One (0.19.0), Studio Code Server (5.18.1)
Dashboards
dashboards 3
resources 24
views 22
mode storage
Recorder
oldest_recorder_run 24 janvier 2025 à 16:43
current_recorder_run 4 février 2025 à 17:15
estimated_db_size 115.02 MiB
database_engine sqlite
database_version 3.47.1
___

Salut

Peux tu tester ça dans les outils de dev/modèle et me dire le résultat.

{% if states('sensor.ecu_inverters_online') == "0" %}
Compteur : {{ states('sensor.msunpv_enrball') }}
{% endif %}

Si je me suis pas planté tu devrais avoir une ligne
Compteur : xxxxx
avec xxxxx correspondant à ton compteur msunpv_enrball

Rappelles moi si tu utilise le msunpv_2_2.yaml ou 4_4.yaml

ps: j’ai bien mis 0 car a cette heure ci je suppose que tes onduleur sont off

:wave: Je me doutais que je te verrais sur un sujet msunpv.
Résultat
Compteur : 3579.7
J’au un 2x2 mais avec une config modifiée pour détection de fin de chauffe et ça obligeait à utiliser les script du 4x4 (mon CE est sur la sortie 1 et je joue sur les différents modes (manu/auto/off)avec les scripts de S3.
J’ai quelques pistes avec chatgpt.

input number

input_number:
  msunpv_enrball_filtered_value:
    name: MSUNPV Energy Ball Filtered Value
    min: 0
    max: 100000  # Adjust to your expected max value
    step: 0.01
    unit_of_measurement: 'kWh'
    icon: mdi:solar-power

template.yaml (que j’ai déjà)

sensor:
  - name: "Filtered MSUNPV Energy Ball"
    unique_id: "msunpv_enrball_filtered"
    state: >
      {% if is_state('sensor.ecu_inverters_online', '1') %}
        {{ states('sensor.msunpv_enrball') }}
      {% else %}
        {{ states('input_number.msunpv_enrball_filtered_value') }}
      {% endif %}
    unit_of_measurement: 'Wh'

et 2 automations, l’une pour stocker sensor.msunpv_enrball dans input_number.msunpv_enrball_filtered_value quand l’onduleur est ON
et une autre pour RAZ input_number.msunpv_enrball_filtered_value à minuit.

Mais je doute de pouvoir en faire des stats.

Donc si le chiffre correspond c’est que je me suis pas planté déjà :slight_smile:

Je tenterai ça.
Tu crées deux sensors

template:
  - sensor:
      - name: msunpv_enrball_forcee #Cumul routage cumulus
        unique_id: "msunpv_enrball_forcee"
        icon: mdi:water_boiler
        state: >-
          {% if states('sensor.ecu_inverters_online') == "0" %}
            {{ states('sensor.msunpv_enrball')|float }}
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy
        
      - name: msunpv_enrball_routee #Cumul routage cumulus
        unique_id: "msunpv_enrball_routee"
        icon: mdi:water_boiler
        state: >-
          {% if states('sensor.ecu_inverters_online') == "1" AND states('sensor.msunpv_enrball_forcee')|float(0) == 0 %}
            {{ states('sensor.msunpv_enrball') }}
          {% else %}
            {{ (states('sensor.msunpv_enrball')|float) - (states('sensor.msunpv_enrball_forcee')|float(0)) }}
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy

Et ensuite par l’ui tu crées un compteur de service public avec en source msunpv_enrball_routee et les bons paramètres.

Par contre si le matin ça route sur le cumulus à midi tu forces et que l’après midi ça re-route ton compteur ne sera plus juste

Code corrigé j’avais oublié de remettre la condition

template:
  - sensor:
      - name: msunpv_enrball_forcee #Cumul forçage cumulus avant routage
        unique_id: "msunpv_enrball_forcee"
        icon: mdi:water_boiler
        state: >-
          {% if states('sensor.ecu_inverters_online') == "0" %}
            {{ states('sensor.msunpv_enrball')|float }}
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy
        
      - name: msunpv_enrball_routee #Cumul routage cumulus
        unique_id: "msunpv_enrball_routee"
        icon: mdi:water_boiler
        state: >-
          {% if states('sensor.ecu_inverters_online') == "1" and states('sensor.msunpv_enrball_forcee')|float(0) == 0 %}
            {{ states('sensor.msunpv_enrball') }}
          {% elif states('sensor.ecu_inverters_online') == "1" and states('sensor.msunpv_enrball_forcee')|float(0) > 0%}
            {{ (states('sensor.msunpv_enrball')|float) - (states('sensor.msunpv_enrball_forcee')|float(0)) }}
          {% else %}
            0
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy

Edit: Et un else 0 pour faire bonne mesure si il n’y avait pas du tout de routage pour que le compteur de service public ne soit pas perdu.

Ps: Avant de faire ton compteur de service vérifie quand même que les données soient cohérentes ça t’évitera de devoir corriger les statistiques si ça déconne.

Ça a l’air tellement plus clean que la solution IA. C’est en place. Reste à attendre le soleil demain pour voir ce que ça rend et je reviendrai donner des news. Merci.

Je suis en train de faire quelques ajustements

Il faudra probablement que j’ajuste également à cause de l’énergie permanente consommée par la carte électronique du CE (2W).

Oui mais es tu à 2 W près pour ton suivi :grin:

Version revue et corrigée en espérant ne pas avoir laissé de coquille comme dans la première.

template:
  - sensor:
      - name: msunpv_enrball_forcee #Cumul forçage cumulus avant routage
        unique_id: "msunpv_enrball_forcee"
        icon: mdi:water-boiler
        state: >-
          {% if is_state('sensor.ecu_inverters_online', '0') %}
            {{ states('sensor.msunpv_enrball')|float }}
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy
        
      - name: msunpv_enrball_routee #Cumul routage cumulus avec remise à zéro à minuit
        unique_id: "msunpv_enrball_routee"
        icon: mdi:water-boiler
        state: >-
          {% if is_state('sensor.ecu_inverters_online', '0') and states('sensor.time') == '00:00' %}
            0
          {% elif is_state('sensor.ecu_inverters_online', '1') and states('sensor.msunpv_enrball_forcee')|float(0) == 0 %}
            {{ states('sensor.msunpv_enrball') }}
          {% elif is_state('sensor.ecu_inverters_online', '1') and states('sensor.msunpv_enrball_forcee')|float(0) > 0 %}
            {{ (states('sensor.msunpv_enrball')|float) - (states('sensor.msunpv_enrball_forcee')|float(0)) }}
          {% endif %}
        unit_of_measurement: "Wh"
        device_class: energy

Donc logiquement:

Le sensor.msunpv_enrball_routee devrait faire le cumul et se remettre à 0 a minuit.

Le sensor.msunpv_enrball_forcee se remettra à 0 tout seul à 00:02 en même temps que sensor.msunpv_enrball (choix de Patrick les compteurs du msunpv se remettent à 0 à 00:02 en tout cas chez moi).

Quand tu vas recharger ta config le sensor.msunpv_enrball_routee devrait être à unavailable et passé tout seul à 0 à minuit.
Tu peux le forcer directement à 0 dans les outils de dev/états et définir son état.

Je mets du conditionnel car je n’ai pas de msunpv_enrball chez moi mais j’ai simulé avec d’autre sensors et ça devrait être bon.

Bien sur ensuite il te faudra le compteur de services.

Ps: si jamais il y’a des erreurs dans le code dis le moi car je le mettrai peut être à dispo sur le github.

Peut-être un (0)

et de l’ordre du détail : icon: mdi:water-boiler

Je sais pas pourquoi mais je le sentais pas le (0) je me suis dis que si on en arrivé à ce calcul c’est que forcement enrball existait déjà, mais oui.
Bien vu l’icone, j’ai tapé histoire d’en mettre une sans verifier.

Enrball routee n’est pas passée à 0 à minuit. À la réflexion, il doit me manquer le sensor.time que je dois créer. Je pensais que c’était un sensor système mais ce n’est peut être pas le cas.

Edit : je dois quand même avoir un souci.

Oui il faut le sensor time
Je me souvenais plus qu’il n’était pas là par défaut.
Dans mon sensor.yaml j’ai ça :

- platform: time_date
  display_options:
    - time

Du coup il n’est pas passé à zéro a minuit et comme aucune des conditions n’est satisfaite au moment où tu as regardé il doit être en unavailable d’où le message que tu montres.
Si tu laisse comme ça il devrait revenir dès que tu auras du routage.

Effectivement, plus d’alerte depuis le démarrage de l’onduleur.

En repensant un peu à tout ça, il faut être conscient de quelques détails.

Pour que cela fonctionne en l’état :

Il faut que le forçage ne soit pas réalisé à cheval sur 2 jours (de 23h00 à 6h00 par ex) et uniquement entre 0h03 et 23h59.

Il ne faut pas qu’il y ai d’arrêt des onduleurs dans la journée puis remise en route de ceux-ci puisque quoi qu’il en soit si arrêt des onduleurs, enrball_forcee prendra la valeur de enrball et du coup si reprise du routage après arret des onduleurs enrball_routee repartira 0.

Le sensor enrball_forcee ne correspondra plus à la réalité une que fois les onduleurs à passent de 1 à 0.

Si un forcage est fait en cours de journée et onduleur à 1, il sera comptabilisé en routage quand même.

Y’a des moyens d’améliorer en étant sur que quand tu fais du forçage manubal soit bien actif. Si tu passe par autobal c’st pas possible du moins à mon stade de réflexion actuel.

Le code actuel peut être un poil réduit mais on va attendre de voir un peu le comportement.

Il se trouve justement que suite à des ratés coté autobal (je soupconne un souci de connexion entre le MSun et mon nouveau routeur wifi), j’ai rapatrié la gestion auto et la détection de fin de chauffe dans HA en m’appuyant sur les remontées de ton intégration.
Résultat, je ne me sers plus que des scripts msunpv_s3_manuel et msunpv_s3_off. Je pourrais m’appuyer sur l’état de sensor.msunpv_cmd_s3.

Edit : Par contre c’est vrai que parfois le forçage est à cheval sur 2 jours.

J’ai eu une idée entre temps qui pourrait pas mal simplifié tout ça si en plus tu te sert de manubal ça sera parfait.
Mais il faut que je teste.
Je suis en train de l’ecrire là.

C’est validé en simu.
J’ai détourné le principe des tarifs heures creuses heures pleines sur les utility meters.
Me reste plus qu’a mettre tout ça au propre avec les bons sensors du msunpv.
Ce ne sera peut être pas pour ce soir.
enrball

1 « J'aime »

Contrairement à hier, j’ai eu un peu de soleil et de routage aujourd’hui.
En mettant de coté les env. 1800 Wh de la marche forcée nocturne, on voit que msunpv_enrball_forcee (en rouge) a augmenté à la place de msunpv_enrball_routee (en orange), en prenant la valeur de msunpv_enrball (en dessous).


Du coup, curieux de voir la suite.