Je pense avoir une piste : le capteur ayant moins de 24h (moyenne zlinky), il est trop haut vs puissance moyenne maison (j’ai un talon à 250 w), la moyenne zlinky doit converger vers cette valeur dans quelques jours j’imagine.
J’ai un détails qui me saute au yeux à l’instant dans ton image c’est que 6.7(soutiré du réseau) -2.2(production) = 4.5 ? étrange coincidence.
Oui, si le code est récent il faut qu’il calcule durant les prochaine 24h pour d’affiné.
Cependant, j’ai trouver une faille dans le code.
Dans mon cas j’ai installé 2400Watt crette de panneau meme si je consomme ~500w en moyenne du coup le calcul :
diff_puissance : 2400 - 546 = 1854
ratio_production : 500 / 1854 ≈ 0.2698 #ICI coef faible du installation imprtante watt crête
ajustement_ratio : 1 + 0.2698 * 0.3 ≈ 1.0809
consommation_corrigee : 546 * 1.0809 ≈ 590.697 Wh
{% set moyenne_consommation_horssolaire = 546 %}
{% set production_solaire = 500 %}
{% set puissance_solaire_installee = 2400 %}
{% set consommation_corrigee = moyenne_consommation_horssolaire * (1 + (production_solaire / (puissance_solaire_installee - moyenne_consommation_horssolaire))*0.3) %}
Dans ton cas tu as :
{% set moyenne_consommation_horssolaire = 546 %}
{% set production_solaire = 500 %}
{% set puissance_solaire_installee = 800 %}
diff_puissance : 800 - 546 = 254
ratio_production : 500 / 254 ≈ 1.9685 #ICI coef important du installation +faible watt crête
ajustement_ratio : 1 + 1.9685 * 0.3 ≈ 1.5905
consommation_corrigee : 546 * 1.5905 ≈ 869.197 Wh
{% set consommation_corrigee = moyenne_consommation_horssolaire * (1 + (production_solaire / (puissance_solaire_installee - moyenne_consommation_horssolaire))*0.3) %}
Je me répond à moi même :
Je partirais sur ce mode de calcul qui n’impliquerai pas l’installation en watt crête soit :
{% set moyenne_consommation_horssolaire = 546 %}
{% set production_solaire = 500 %}
{% set consommation_corrigee = moyenne_consommation_horssolaire * (1 + (production_solaire / (moyenne_consommation_horssolaire))*0.15) %}
ratio_production : 500 / 546 ≈ 0.9156
ajustement_ratio : 1 + 0.9156 * 0.15 ≈ 1.1373
consommation_corrigee : 546 * 1.1373 ≈ 620.6768 Wh
Avec un ratio a 15% a la place de 30%
Pour la fonction max :
La fonction max
prend deux valeurs en entrée et renvoie la plus grande des deux. Dans ce cas, elle compare la différence entre les deux capteurs. Si cette différence est négative, cela signifie que la consommation est plus élevée que la production, et la valeur est ajustée à 0 pour éviter d’avoir une valeur négative.
PS: pour le tableau de bord energy export (retourné au reseau) utilise ce capteur :
capteur statistics energy « daily_energy_export »
- name: daily_energy_exported
state: "{{ states.input_number.daily_export.state |float(0) |round(2) }}"
unit_of_measurement: 'kWh'
device_class: energy
state_class: total_increasing
icon: 'mdi:flash'
Merci pour le détail et la proposition de correction dans la formule. La condition production_solaire > 0 et consommation_reseau= 0 est la condition la plus dure pour estimer l’énergie réellement consommée et / ou injectée sur le réseau. Pour moi, il est impossible de l’estimer : on imagine produire 1400 W en trop, si je lance mon grille pain à 1200 W pendant 1h, et que la condition production_solaire >0 et consommation_reseau = 0 est toujours valide, personne ne pourra prédire que j’aurais allumé mon grille pain : c’est pareil pour l’énergie injectée dans le réseau ou consommée par les équipements, on ne sait pas trop ou elle va.
Pour cette condition, j’ai remis consommation_corrigee = 0, mais par contre, on a plus aucune indication de ce qu’on renvoie sur le réseau (mais impossible par nature sans monitorer par une pince ampéremétrique le retour réseau élec, type : shelly EM ou alors d’avoir accès à l’indice d’injection du compteur linky -ie seulement disponible pour les linky ‹ producteur ›).
Sans cet équipement, optimiser sa consommation vs production solaire, c’est avoir les ‹ barres jaunes › et une barre ‹ bleue › très petite, voir screenshot ci-dessous.
Je continue les investigations mais j’ai peur que prédire une valeur injectée soit illusoire.
Oui, tu as partiellement raison sauf si on prend a la lettre l’histoire du grille pain puisqu’il consomme 1200watt environ la condition consommation = 0 risque de se transformer en >0 donc changera de conditions.
Oui, cette solution est imparfaite pas besoin de faire d’avantage de rélféction.
Le but c’est de définir la partie flou quand conso réseau =0 mais dès que tu vas allumer un four, grille pain, ou chauffage électrique tu changes de condition production solaire + consommation reseau.
Dans ton cas c’est encore plus précis vue ton installation produit au max 800watt crête. c’est ta marge d’erreur maximum.
Bonjour,
Je suis novice sur HA j’ai essayé de mettre en place votre solution mais je bute encore sur quelques problème notamment au nom des variables… Mais de mon côté je n’ai pas les calculs de la neutralité qui apparaissent et le pourcentage de production autoconsommée, je ne sais pas pourquoi ?
Bonjour merci pour cette info, ca fonctionne parfaitement chez moi !
Je peux donc desormais piloter le rendement de mon install (6panneaux JA Solar 430W et 3 MO DS3-L + APS ECU-C) !
Par ailleurs, je vois déjà pas mal de kwh retourné sur le réseau ENEDIS et il faut donc pouvoir les réorienter ! En l’occurrence, vers mon ballon Thermodynamique Atlantic Odyssée 2. Je sais que l’ECU-C permet le delestage mais savez vous comment celà fonctionne concrètement ?
Bonjour, je bloque dans cette partie étape 2 : je n’arrive pas a comprendre ou copier ces 4 fichiers. J’ai essayer dans mon sensors.yaml et automatisation.yaml et a chaque fois HA me sort plein d’erreurs.
Par défaut dans configuration.yaml
Sinon tu tapes dans configuration.yaml →
template: !include_dir_merge_list template/
Et dans ton dossier config tu créer un dossier template dans lequel tu glisse tout tes template
Ton integration est super, seulement j’ai un comportement qui me derange. Par exemple aujourd’hui ou j’avais du soleil et beaucoup de nuage j’avais non-stop des notifications avec différents niveaux de productions. Est ce que j’ai louper un paramétrage ou alors puis je rajouter a un endroit d’avoir qu’une notification par heure ?
Merci pour ton énorme travail,
@cbo51130
Le tuto est a adapter a ta configuration et ton installation solaire.
Pour éviter les spam tu peux changer les barème « 200 » de condition pour envoyer la notification.
condition: or
conditions:
- condition: template
value_template: >-
{{ states('sensor.energy_exporting_wh')|float >
states('input_number.ecu_r')|float + 200}}
- condition: template
value_template: >-
{{ states('sensor.energy_exporting_wh')|float <
states('input_number.ecu_r')|float - 200}}
Autres alternative si tu veut régler par heure
Tu peux indiquer l’intervalle en heure entre deux déclenchement de l’automatisation.
{{ now() - state_attr('automation.change_current_theme', 'last_triggered') > timedelta(hours=12) }}# A remplacer hours par minute et le 12 par le nombre de votre choix.
Oui, toute a fait
Après tu peux aussi ajouter si tel ou tel personne sont a la maison alors la condition est remplie donc on envoie la notification.
Pour cela j’ai fait 2 automatisations. Une pour moi et une pour ma femme. J’étais pas sur d’arriver a gérer 2 personnes sur la meme automatisation.
Si tu veut les réunir il faut dans action mettre:
Action en parallèle suivit de la condition"si alors" présence de Monsieur alors notification.
Oui mais je veux que les notifications ne soient envoyées qu’a celui qui est present a la maison. Je suis pas sur de moi donc je reste sur 2 automatisations
Mise jour le 26/02/2024 du tutoriel et du code du capteur « consommation corrigée »
- suppression de la variable : installation solaire qui pouvait causé des anomalie selon l’installation réalisé et la consommation moyenne.
- Ajustement du calcul dans le cas ou la production solaire est faible et consommation faible pouvant induire des erreurs de surestimation ou sous estimation qui sont désormais réduite au possible.
J’invite à mettre a jour vos codes afin d’en bénéficier.
Je me répond a moi meme.
En enlevant le code
{{ now() - state_attr('automation.change_current_theme', 'last_triggered') > timedelta(hours=12) }}# A remplacer hours par minute et le 12 par le nombre de votre choix.
Tout revient a la normale.
Maj: 26/06/24
Ajout d’une condition anti spam dans l’automatisation: régler sur 30 minutes entre deux notification par défaut
Ajustement du code consommation corrigée pour affiner les résultat lorsque consommation zlinky et production solaire sont très proches