Pilotage selon prévision météo

[Lolo69]

Sur des stats observées sur 2 semaines avec une météo qui a été bien changeante.
Ces seuils sont très empiriques car cela dépend évidemment de son installation ( pwc) de l orientation des panneaux des habitudes de consommation de l eau etc etc
C est donc tout à fait empirique et déterminé par l observation , car il est illusoire ou en tout cas ultra complexe de faire la prévision exacte de wh produit
Avec les seuils donnés cela correspond pour l instant simplement à journée très ensoleillée ou journée peu ensoleillée.
J ai choisi une moyenne sur la journée pour éviter de dire que j ai eu 5 min de grand beau temps et toute la journée grisatre
C est pour ces raisons que je n ai pas encore fait l automatisme car il faut affiner. Par exemple si la temp exterieure est basse je vais consommer plus d elec pour le chauffage, donc avec un seuil fixe ça marchera pas
D où mon scepticisme du début sur le bien fondé de cette fonction « automatisée » bien malin celui qui aura une formule magique pour se passer de tout réglage de ce seuil , ce qui revient au même que de modifier la durée de complément de chauffe

[Sgb31]

Effectivement lolo69, pas simple . Merci pour le partage de ton analyse...
Sous HA , j'utilise "Solcast Solar" qui me donne une prévision de prod en KWh ( pour le jour, la prochaine heure et le lendemaein).
souvent la prévision du lendemain à 24h - 12h est révisée en début de journée ...
Cette prévision de prod est uniquement liée à la météo, localisation des panneaux, caractéristiques ...
Je pense qu'en terme d'exploitation, il faut bien différencier l'estimation de prod de ton usage et de tes priorité en terme de routage ...
Enfin, c'est plutôt comme cela que je l'interprété de mon coté

[Lolo69]

Tout à fait en phase avec toi SGB. J ai choisi open-meteo sur le seul critère de ne pas être obligé de créer un compte

[FastFrench]

Au début, j'avais prévu d'utiliser aussi un service météo pour prévoir l'ensoleillement du lendemain. J'avais même écrit un petit script Python qui récupère les infos sur un serveur gratuit et les stocke en MQTT.
D'ailleurs le script tourne depuis plusieurs mois, ça marche bien (il tourne sur un NAS, qui de toutes façons est déjà là et alimenté 24/24).

Mais à la réflexion, je me suis dit que ça apportait de la complexité au fonctionnement du routeur (avec une dépendance de plus), et qu'au final ça n'apporte pas grand chose.
En effet, ce qui compte vraiment, c'est d'avoir de l'eau chaude, et pas de savoir si les PV pourront chauffer l'eau demain.
Donc je me contente de vérifier la température de l'ECS à 4h du matin, et j'utilise le réseau pendant max 2h (= fin des HC) pour chauffer le ballon si l'eau n'est pas à 45°C.
Sinon le ballon est configuré pour absorber tout le surplus des PV, avec juste la sécurité du ballon réglée autour de 60°C.

Ce système est simple et je n'ai pas le sentiment que l'anticipation de l'ensoleillement du lendemain améliorerait les choses. Ce n'est pas parce qu'il y aura du soleil le lendemain que je veux avoir de l'eau froide le matin !

[Lolo69]

CQFD FastFrench j en arrive à la même conclusion que toi. Si certains sont désireux de tester et d intégrer je peux partager e code de l esp qui fait tout ça et distribue les infos en mqtt au RMS.
Pour l automatisme et la visu j envoie ça au rms comme si c était une température mqtt. Donc pas de modif de conf. du rms
A la base j ai fait cet esp pour fabriquer un petit broker mqtt pour comprendre les mécanismes MQTT sans mosquito ni HA.

[grostoto]

je suis assez d'accord.

avec l'hiver j'utilise simplement le compteur temps équivalent ouverture 100%, pour ajouter le complement de chauffe la nuit.
empiriquement, j'ai déterminé que 1h45 me suffisait à avoir de l'eau chaude.