Salut,
ça devrait êtr faisable facilement, il faut que tu réintègres la puissance consommée par ton ballon (ou au moins ce que ton dimmer lui demande de consommer) en l’additionnant à ton surplus.
Attention car si les mesures ne sont pas sychrones ou a des rythmes différents tu aura aussi des pics.
Bonjour AlexHass, pourrais-tu m’expliquer comment l’intégrer ?
Je sais j’abuses, mais là, je sature personnellement…
Je ne connais pas Andre, mais le professeur solaire, lui utilisait un routeur sur la base de Robin, donc fait pour ça…
Ou il a fait autre chose depuis mais je ne suis pas l’actualité… 
Pour moi rien ne vaut un truc d’externe et fait pour ça, type jetblack31/max PV
J’ai utilisé l’ancienne version Eco PV, super efficace pas de question à se poser…
Si effectivement tu n’as pas beaucoup de temps, il vaut mieux passer par une solution déjà existante… Créer un truc de zéro, c’est chronophage, extremement chronophage, surtout si au final le résultat obtenu n’est pas celui que l’on souhaitait…
Xtofe,
Le seul truc, c’est que cela fait plus d’un mois que je suis dessus, tout est installé et tout fonctionne à un ligne de code près… Ce serait dommage de tout planter, de repartir à zéro et/ou d’investir dans du matériel autre qui fera le même job que ce que j’ai aujourd’hui…
Pas de soucis Eric!
Mais je me demande si la ligne de code manquante ne va pas faire toute la différence ?!!
Pour les journées ensoleillées, pas de soucis tu devrais aboutir a quelque chose qui tienne la route, par contre avec les nuages… Hum, ça va vite faire yoyo, en quelques secondes la puissance peut varier plusieurs centaines de fois…
A refaire, baah je reprendrais la solution externe… Avec du temps réel, pas approximatif… 
Je te souhaite quand même d’y arriver, c’était que mon avis!
Peux tu repasser ton automatisation complète actuelle pour gérer ça?
Bonjour voici mon automatisation basée sur un blueprint que j’ai modifié:
- id: '1679502710066'
alias: Modulation ballon ECS
description: ''
use_blueprint:
path: Twanne/smart_dimmer_day_time_condition.yaml
input:
schedule_start: 06:00:00
schedule_stop: '22:00:00'
sensor_entity: sensor.commande_dimmer
target_light:
device_id: 75ba3d2e9eb368941b1a978f34c9f9ba
Et voici mon blueprint:
blueprint:
name: Smart Light Dimmer V1.3
description: 'Version 1.3
Dim or turn off light based on the value of a light sensor
'
source_url: https://gist.github.com/Twanne/28efafb95e4e85ca154ebac62b4b3148
domain: automation
input:
schedule_start:
name: Schedule start time
description: Automation only runs after this time.
selector:
time: {}
schedule_stop:
name: Schedule stop time
description: Automation does not run after this time.
selector:
time: {}
sensor_entity:
name: Sensor
selector:
entity:
domain: sensor
multiple: false
target_light:
name: Target lights
selector:
target:
entity:
domain: light
mode: single
variables:
sensor: !input sensor_entity
trigger:
platform: state
entity_id: !input sensor_entity
condition:
- condition: numeric_state
entity_id: !input sensor_entity
above: 25
- condition: time
after: !input schedule_start
before: !input schedule_stop
action:
- service: light.turn_on
data:
brightness_pct: '{{ states(''sensor.commande_dimmer'') | int }}'
target: !input target_light
Et pour finir, mon config.yaml:
template:
- sensor:
name: "commande_dimmer"
state: >
{{ min((states('sensor.solarman_feed_in_out_power') | int ) * 100 / 2000 , 100) | round (0) }}
Merci pour votre aide
Autre idée peut être simple à faire c’est le lisser les courbes pour éviter le yoyo.
Tu moyennes chaque point de ta courbe avec la moyenne précédente:
C(n) = (Mesure(n) + C(n-1)) / 2
et tu utilises C(n) au lieu de Mesure(n). T’auras des valeurs lissées dans le temps bien plus exploitables que des valeurs brutes.
Tu peux ensuite aller un peu plus pour virer les valeurs abérrantes (qui s’écartent trop de la valeur précédente) si ça fait sens dans ton cas.
Je m’en sers pour calculer des pentes de température.
Du coup aurait juste à modifier ta formule.
Salut,
Mais là son souci de yoyo ce n’est pas lié aux changements de production.
C’est que le calcul manque d’une composante qui est la puissance déjà demandée au gradateur.
@bmbleu
Comme je pense que la seule info que tu ait c’est le « brightness_pct » que tu as appliqué juste avant.
Tu peux donc réappliquer le calcul inverse et l’ajouter au surplus actuel.
Seul truc à aucune moment tu n’as donné le nom de l’entité light utilisée donc faudra remplacer les xxxxx ci dessous.
Autre soucis je ne sais pas si brigthness_pct est gardé dans les attributs de ton entité…
Donc le calcul de ton « commande_dimmer » serait un truc comme ça:
{{ min(((states('sensor.solarman_feed_in_out_power') | int) + ((state_attr("light.xxxxxxxx", "brightness_pct") | int) / 100 * 2000) ) * 100 / 2000 , 100) | round (0) }}
Oui ca manque on est d’accord.
Je parlais plus de :
et de :
Pour éviter les pics et lisser tout ça.
Oui effectivement, j’avais mal compris 
AlexHass,
Voilà ce que cela me dit dans config.yaml pour ma déclaration de template dans modèle / outils de développement:
ValueError: Template error: int got invalid input 'None' when rendering template 'template:
- sensor:
name: "commande_dimmer"
state: >
{{ min(((states('sensor.solarman_feed_in_out_power') | int) + ((state_attr("light.modulation_ecs_dimmerized_light_2", "brightness_pct") | int) / 100 * 2000) ) * 100 / 2000 , 100) | round (0) }}' but no default was specified
Et sinon, que veux-tu dire par là:
« Autre soucis je ne sais pas si brigthness_pct est gardé dans les attributs de ton entité… »
Désolé, je ne comprends pas ce que tu veux dire par là…
La seul chose que j’ai vu , c’est que c’est en lecture seule sur l’entité, il n’a pas d’id unique.
Vraiment désolé…
Bonjour,
Je vois que tu sais copier/coller du code Yaml. C’est peut-être stupide de ma part mais je n’arrive pas le faire et cela me pose des problèmes lors d’échange de posts. Je suis sur MAC Book Pro. Bien sûr je sais copier/coller du texte « normal » mais pas duYaml.
Peux-tu m’aider ?
Bonjour,
Merci beaucoup pour ces infos. As-tu finalement réussi à avoir quelque chose de stable ?
Pour ma part, ça « fonctionne » avec le code suivant :
template:
- sensor:
name: "commande_dimmer"
state: >
{{
((max(
min(
(states('sensor.puissance_compteur') | int(0) ) * -100 / 1300 +
((state_attr("light.esp_sdb_palier_chauffe_eau", "brightness") | int(0))/2.55)
,100)
,0)
+ (states('sensor.commande_dimmer') | int(0))
) / 2) | round (0)
}}
sensor.puissance_compteur Donne une valeur négative quand j’ai du surplus.
Le brightness va de 0 à 255 d’où la division par 2.55. brightness_pct ne semble pas être disponible.
Mais le problème est que ça ne règle pas le Yoyo, je suppose que c’est car les différents systèmes ne réagissent pas à la même vitesse.
Je relance le sujet car je suis entrain de paramétrer mon routeur à base de Dimmer.
Pour l’instant j’ai simplement regardé tous les 5% combien le chauffe-eau consomme et j’ai fais une automatisation avec des fourchettes de valeur pour définir quel palier est le plus adapté mais je me suis rendu compte qu’à un même %, la consommation variait.
J’aurai donc souhaité trouver un moyen d’utiliser le retour de conso en fonction du % choisi pour rendre la variation du Dimmer plus intelligente mais je ne vois pas comment m’y prendre…
Salut
regarde chez F1ATB,
il a developpé et il continue a le faire evoluer un routeur solaire
avec plusieurs methodologies de point d’entrée.
je te laisse regarder
sinon tu as la solution de https://domo.rem81.com/