Bonjour à tous,
Je voulais partager le scenario que j’ai écrit pour gérer l’allumage/extinction de ma PAC (clim) en fonction de ma production solaire (via panneaux solaires).
Ce topic est un partage, et je ne me revendique pas avoir la science infuse. C’est en premier lieu pour partager et en faire profiter les autres, et ensuite pour l’améliorer suite aux différentes critiques constructives qui pourront découler de ce fil.
Ce scenario fonctionne dans le sens où je l’ai testé quelques jours, et le comportement a l’air cohérent par rapport à ce que je voulais en faire, mais il n’est clairement pas parfait. Je donne le scenario en toute fin du post.
Il est bien sûr utilisable pour n’importe quel équipement autre qu’une PAC que l’on souhaiterait gérer en fonction d’une production solaire (filtration d’une piscine par exemple).
Le but du scenario est donc de monitorer la production solaire vs la consommation d’une PAC pour couper celle-ci si elle venait à trop consommer vs la prod solaire disponible.
Ce scenario nécessite (notamment via des tags à renseigner au début du scenario) :
- une commande info historisée permettant de connaître la puissance instantannée injectée chez EDF (qu’on peut aussi appeler « surplus solaire instantané »). Peut être positive ou négative. Idéalement lissée sur la minute.
=> tag «avg_injection_last_Xmin» à modifier - une commande info historisée permettant de connaître la puissance intantannée importée depuis EDF par le foyer (ce qu’on achète). Idéalement lissée sur la minute.
=> tag «avg_import_last_Xmin» à modifier - la consommation moyenne de la PAC à monitorer
=> tag «conso_equipement» à modifier - le talon moyen du foyer
=> tag «talon» à modifier - une commande action permettant d’allumer l’équipement
=> action « State ON » à modifier dans le scenario - une commande action permettant d’éteindre l’équipement
=> action « State OFF » à modifier dans le scenario - le plugin « Solcast » bien configuré (qui permet notamment de donner la production solaire estimée de l’heure suivante)
=> A noter que toutes les unités de puissance utilisées doivent correspondre : toutes en kW ou toutes en W, mais pas de mix.
Le scenario permet de jouer sur les paramètres suivant (renseigné par l’utilisateur) en entrée :
- le pourcentage de la conso de l’équipement qu’on veut au moins couvrir par le solaire. Si on positionne 90 par exemple, on éteindra une PAC qui consomme 1000W uniquement si on commence à importer plus de 100W (900W/90% sont convert par le solaire, 100W/10% par EDF). Paramètre à positionner sur 100 si on veut couvrir sa consommation exclusivement par du solaire (et donc ne rien importer du tout).
=> tag «pourcent_equipement_couvert» à modifier - la fréquence (en minute) de recalcul : c’est la fréquence qui permet de reprendre une décision sur le (re)démarrage/extinction de la PAC, et éviter ainsi de faire du start/stop toutes les 15sec.
=> tag «frequence_check_min» à modifier - la durée (en minute) pendant laquelle on tente de rallumer la pac. J’y reviens plus tard sur le fonctionnement.
=> tag «duree_tentatives_min»
Principe de fonctionnement du scenario :
On lance le scénario à la main (sans devoir lancer l’équipement d’abord). Le scenario vérifie ensuite
sur les X dernières minutes (en fonction du tag « frequence_check_min ») si la production solaire permet de couvrir la consommation de l’équipement.
Pour cela :
- Il vérifie si la moyenne de l’injection chez EDF sur les X dernières minutes est supérieure au pourcentage de l’équipement qu’on veut couvrir. Si c’est le cas, on considère qu’on a assez de prod solaire, on allume l’équipement et on relance le scenario dans X minutes.
- Dans le cas ou l’équipement était allumé (lancé par le scenario lui même dans une itération précédante, voir plus bas), il considère que la prod n’est plus suffisante si l’injection moyenne des X dernières minutes est nulle (=aucun surplus) et si l’import EDF (=acheté) n’est pas supérieur au pourcentage de la conso de l’équipement qu’on veut couvrir.
- (Pour ces deux cas, on sait si l’équipement est allumé en fonction du paramètre qu’on fourni au scenario (tag « allumé »), renseigné via l’itération du scenario précédente.)
Si on vient de calculer que la prod solaire n’est pas suffisante, on commence par éteindre l’équipement.
On vérifie ensuite si la production solaire estimée de la prochaine heure (calculée par le plugin solcast) permet de couvrir notre PAC + le talon. Si c’est pas le cas, cela veut dire qu’on est soit en fin de journée, soit qu’une grosse couverture nuageuse va durer plus d’1H. A ce moment on éteint définitivement notre équipement et on arrête le monitoring.
Par contre si l’estimation de prod solaire de l’heure suivante permet toujours de couvrir notre besoin (donc on est dans le cas où on se trouve probablement sur un passage nuageux temporaire et en milieu de journée), on commence à monitorer toutes les X minutes si la prod solaire est de nouveau suffisante. Si c’est le cas, on rallume l’équipement et on relance le scenario dans X minutes pour retomber sur un cas « nominal ». Ce check est donc fait toutes les X minutes mais pendant une durée donnée (le fameux tag « duree_tentatives_min »).
Si pendant toute cette durée, on a pas été en mesure de relancer l’équipement à cause d’une production solaire insuffisante (ou une consommation du foyer trop importante), on arrête définitivement l’équipement et le monitoring. Ce mécanisme est là pour couvrir principalement deux cas : une couverture nuageuse qui perdure (malgré une estimation solcast positive) ou bien une consommation du foyer trop importante (on a allumé le four pendant 3h par exemple).
Le scenario comporte des logs à toutes les étapes pour avoir de la visibilité sur ce qui se passe.
Un million de possibilités d’améliorer le scenario, notamment :
- au lieu de donner une consommation de la PAC fixe, peut être moduler la consommation en fonction de la température ext vs intérieure (car la PAC ne consommera pas pareil si elle n’a que 2° à rattraper et s’il fait 28° dehors, ou bien si elle doit rattraper 10° et qu’il fait 37° dehors), plutôt que de positionner une conso fixe. On peut imaginer établir une fonction qui prends la temp ext, la temp int, la temp de la consigne et la conso de base annoncée par le constructeur, pour calculer une conso variable de la PAC. Commentaire valable pour une clim mais pas pour une filtration piscine ou chargement de batterie par exemple, qui elle est constante en toutes circonstances.
- faire un calcul dynamique du talon sur les (par exemple) 60 dernières minutes plutôt que de donner une valeur fixe du talon pas forcément représentative sur 5min.
- pas de possibilité « d’étager » plusieurs équipements avec priorité. Par exemple, allumer plusieurs équipements si la prod le permet, et les éteindre/allumer au fur et à mesure que l’évolution de la prod solaire tout en restant proche d’une injection à 0. Ici on ne peut gérer qu’un seul équipement. Et multiplier ce scenario par autant d’équipement ne fonctionnera pas non plus, car ils vont tous s’éteindre et tous se rallumer en même temps…
- améliorer la réactivité du scenario si on venait à allumer un gros consommateur (genre aspirateur ou plaques induction) juste après un recalcul (en imaginant par exemple un autre scenario qui se déclenche et intervient si la dérivée de la conso solaire par rapport au temps est très forte sur la dernière minute). Le but étant de reconsidérer les variables si elles venaient à changer drastiquement d’un coup, au lieu de perdre du temps (et de l’argent) en attendant X minutes avant un recalcul.
- améliorer le calcul de la moyenne d’injection et d’import sur les X dernières minutes en se basant sur les index plutôt que sur une moyenne de puissances instantanées.
- impossibilité de passer l’équipement en paramètre qu’on veut monitorer dans un tag. Il faut modifier chaque ligne du scenario à la main où intervient les commandes de l’équipement si on veut changer (contrainte jeedom). Seul le bloc code d’un scenario permet de le faire.
- si une couverture nuageuse dure 1 ou 2h (entre midi et 14h par exemple), on va arrêter l’équipement même si la prod solaire pourrait repartir au bout de 2h (à partir de 15h).
- ajouter par-ci par là des notifications (type Telegram) pour avertir l’utilisateur du comportement du scenario.
- possibilité de récupérer une estimation solaire à venir plus fine que simplement sur l’heure en totalité (via le plugin solcast) pour améliorer le comportement du scenario.
Voilà le code du scenario, à modifier pour les tags et l’équipement. J’essaierai de re-éditer ce poste avec les modifs/améliorations donnée au fil de la discussion, pour mettre à jour le comportement décrit et le code du scenario.
A noter aussi que les tags « avg_injection_last_Xmin » et « avg_import_last_Xmin » sont aussi recalculés dans la boucle en fin de scenario, ne pas oublier de les modifier aussi :
- Nom du scénario : Monitor equip conso solaire
- Mode du scénario : provoke
- Evènement :
ACTION
tag - Options : {"enable":"1","background":"0","name":"conso_equipement","value":"600"}
tag - Options : {"enable":"1","background":"0","name":"pourcent_equipement_couvert","value":"70"}
tag - Options : {"enable":"1","background":"0","name":"talon","value":"300"}
tag - Options : {"enable":"1","background":"0","name":"frequence_check_min","value":"5"}
tag - Options : {"enable":"1","background":"0","name":"duree_tentatives_min","value":"60"}
tag - Options : {"enable":"1","background":"0","name":"avg_injection_last_Xmin","value":"average(#[Maison][R\u00e9sum\u00e9 \u00e9lec][Injection]#, 5 minute)"}
tag - Options : {"enable":"1","background":"0","name":"avg_import_last_Xmin","value":"average(#[Maison][R\u00e9sum\u00e9 \u00e9lec][Import edf]#, 5 minute)"}
tag - Options : {"enable":"1","background":"0","name":"estim_prod_1h","value":"#[Maison][Solcast][Pr\u00e9vision heure suivante]#"}
tag - Options : {"enable":"1","background":"0","name":"nb_tentatives","value":"round(tag(duree_tentatives_min)\/tag(frequence_check_min))"}
SI tag(allumé,"false") == "true"
ALORS
SI abs(#avg_injection_last_Xmin#) == 0 ET #avg_import_last_Xmin# > (#conso_equipement#*(1-(#pourcent_equipement_couvert#/100)))
ALORS
tag - Options : {"enable":"1","background":"0","name":"pas_assez_de_prod","value":"true"}
SINON
tag - Options : {"enable":"1","background":"0","name":"pas_assez_de_prod","value":"false"}
SINON
SI abs(#avg_injection_last_Xmin#) < (#conso_equipement#*(#pourcent_equipement_couvert#/100))
ALORS
tag - Options : {"enable":"1","background":"0","name":"pas_assez_de_prod","value":"true"}
SINON
tag - Options : {"enable":"1","background":"0","name":"pas_assez_de_prod","value":"false"}
SI #pas_assez_de_prod# == "true"
ALORS
log - Options : {"enable":"1","background":"0","message":"Pas assez de prod solaire sur les #frequence_check_min# derni\u00e8res minutes pour couvrir les besoins en conso de notre \u00e9quipement. On le coupe pour le moment."}
#[Chambre][Split étage onecta][State OFF]# - Options : {"enable":"1","background":"0"}
SI #estim_prod_1h# < ((#conso_equipement#*#pourcent_equipement_couvert#/100) + #talon#)
ALORS
log - Options : {"enable":"1","background":"0","message":"Estimation de prod solaire de l'heure suivante pas suffisante pour couvrir notre \u00e9quipement + talon, on arr\u00eate le monitoring d\u00e9finitivement"}
(stop) Arret du scenario
SINON
log - Options : {"enable":"1","background":"0","message":"On a encore potentiellement toujours de la capacit\u00e9 de production solaire sur l'heure d'apr\u00e8s"}
POUR #nb_tentatives#
FAIRE
log - Options : {"enable":"1","background":"0","message":"On re v\u00e9rifie dans #frequence_check_min# min si on a de nouveau suffisamment de prod solaire pour couvrir la conso de notre \u00e9quipement"}
(sleep) Pause de : #frequence_check_min# * 60
ACTION
tag - Options : {"enable":"1","background":"0","name":"avg_injection_last_Xmin","value":"average(#[Maison][R\u00e9sum\u00e9 \u00e9lec][Injection]#, 5 minute)"}
tag - Options : {"enable":"1","background":"0","name":"avg_import_last_Xmin","value":"average(#[Maison][R\u00e9sum\u00e9 \u00e9lec][Import edf]#, 5 minute)"}
SI abs(#avg_injection_last_Xmin#) > (#conso_equipement#*0.7)
ALORS
log - Options : {"enable":"1","background":"0","message":"On a de nouveau assez de prod. On red\u00e9marre l'\u00e9quipement et on relance le sc\u00e9nario dans #frequence_check_min# min"}
#[Chambre][Split étage onecta][State ON]# - Options : {"enable":"1","background":"0"}
DANS #frequence_check_min#
FAIRE
(scenario) start de [Aucun][Aucun][Monitor equip conso solaire]
(stop) Arret du scenario
SINON
log - Options : {"enable":"1","background":"0","message":"Sur les #duree_tentatives_min# derni\u00e8res minutes, la prod solaire n'est pas suffisante. on stop l'\u00e9quipement et le monitoring d\u00e9finitivement."}
#[Chambre][Split étage onecta][State OFF]# - Options : {"enable":"1","background":"0"}
(stop) Arret du scenario
SINON
log - Options : {"enable":"1","background":"0","message":"Prod solaire suffisante, on continue et on re v\u00e9rifie dans #frequence_check_min# min."}
#[Chambre][Split étage onecta][State ON]# - Options : {"enable":"1","background":"0"}
DANS #frequence_check_min#
FAIRE
(scenario) start de [Aucun][Aucun][Monitor equip conso solaire]
