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)
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
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.
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.
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.
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.
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.
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.
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).