Effectivement, j’ai utilisé l’unité Wh à tord car à un instant T, c’est uniquement la puissance en W qui est nécessaire et non son énergie en Wh.
Ainsi, dans mon message précédent, toutes les valeurs sont en W comme l’affiche l’outil Enlighten en statut en direct.
Pour exemple, un équipement consommant 1200W a besoin de 1200W en permanence pour fonctionner (pas 408,5Wh).
S’il fonctionne 1 heure, il aura effectivement consommé 1200Wh.
Mais 1200Wh pourrait aussi bien être l’énergie consommée par un équipement de 2400W sur 30mn Par contre, il faudra bien une production réelle de 2400W en permanence sur ces 30mn si je souhaite être en full autoconsommation.
C’est peut être cela la source de nos interrogations sur le calcul
_ PS: Pour le créneau 14h-15h de la journée d’hier, j’ai les estimations de 2451W à 14h et 2484W à 15h
Ce sont les valeurs indiquées à ces heures sur la courbe ‹ Aujourd’hui › (2451W à 14h et 2484W à 15h).
Peut-être qu’on parle de la même chose mais je suis pas sûr. Quand on regarde le point de la courbe (à 16h), on voit la prévision de production entre 15h et 16h
Oui bien sûr. Mais comme ce que fourni l’API de SolCast correspond à des Wh, l’ensemble du plugin est basé sur ça, des Wh.
C’est pourquoi je suis partit sur un découpage de Wh en tranche de 10mn pour trouver la plage horaire pendant laquelle il y a le plus de Wh de disponibles
Suite à ton post je me suis rendu compte que je n’avais pas retiré de l’équation les moments où la demande était supérieur à la prévision et ceci a été corrigé mais toujours en utilisant des Wh au bout du compte.
Faudrait voir si mon algorithme fonctionne toujours en faisant comme si c’était des W instantanés. Parce que l’enjeu à la base il est là, trouver le moment à partir duquel la quantité de production est la plus grande sur l’ensemble d’une page horaire demandée.
Effectivement @Bison, ce n’est pas la prévision 6h qui est dans le tableau, mais bien la prévision évolutive Du coup, çà modifie ma vision sur comment planifier la recherche des 84 puissances qui ne pourraient plus être calculé qu’une seule fois sur la prévision de 6h mais à chaque demande…
Je pense que Solcast fait un abus de langage. Si on clique sur ENERGIE de Enlighten et que l’on place un doigt sur la courbe, on lit une PUISSANCE dans la fenêtre qui s’ouvre et une ENERGIE Produit en kWh sur cette période de 15mn en haut à gauche de l’écran. Pour cette dernière, je ne vois pas l’intérêt si ce n’est se comparer aux données Enedis.
Cette puissance est celle que l’on indique et retrouve - quasiment suivant le réglages des variables définis dans Solcast - dans la courbe et tableau de ton plugin.
Ce sont donc bien des puissances en W et pas de l’énergie en Wh.
Pour faire 2451Wh il faudrait une courbe avec une ligne horizontale de production à 2451W sur toute l’heure concernée ( une production par plateau).
Hors, la valeur est forcément différente d’une heure à l’autre du fait que le terre tourne en permanence et que le soleil n’irradie pas les panneaux par pas de 1 heure ! Ce sont des courbes de puissance instantanée
Mais çà ne change en rien que ton plugin est super
Pour moi, il suffit d’utiliser ces valeurs Solcast en puissance comme je le présentais ci-dessus ou comme tu le fais actuellement. J’attends ton correctif indiqué ci-dessus pour faire des tests
Mais je peux me tromper sur ces notions Puissance/Energie et toutes les ‹ bonnes âmes › sont les bienvenus
Alors là je n’arrive pas à suivre ton raisonnement. C’est justement parce que la production instantané (en W) ne peut pas être exactement la même pendant 1h (terre qui tourne, passage nuageux, temps qui passe, …) que solcast (API, pas le plugin qui ne reflète pas une réalité puisque c’est moi qui l’ai codé) ou n’importe quelle application n’indiquera pas une valeur instantanée sur une heure de production mais une valeur en Wh (l’équivalent de la consommation).
En 1h si tu fait tourner 1 appareil de 1000W il aura bien consommé 1000 Wh, de la même façon que 4 appareils de 250W qui tourne pendent 1h.
Solcast (l’API) ne peux logiquement que prédire une quantité d’énergie en 1h. Si tu as de la chance et que le ciel est très dégagé et que le soleil est relativement haut dans le ciel, il se peut que la production instantanée soit proche de l’energie produite durant l’heure complète mais la plupart du temps ce n’est pas le cas et les 2451 Wh de production en 1h peuvent très bien être composé de 20s à 2001W, 8mn à 1600W, 55s à 2605W, etc …
Dès lors que l’on évalue une consommation ou une production sur une durée il doit être question de Wh et non de W.
Bref je tenterais de voir en adaptant comme tu pensais et en considérant que pendant 10mn la puissance produite sera linéaire à xxx W
Bonjour @Bison,
Je comprends ton raisonnement et la complexité du challenge qui ne peux évidemment pas tenir compte des aléas des moments propres à chacun (nuages, usages instantanés…).
Il n’y a qu’à voir la véracité des prévisions météorologiques à certains moments
Du coup, j’ai essayé de comprendre le log où il y a pas mal de données.
L’objectif étant de capitaliser sur ce que tu as déjà bien fait
Afin qu’il n’y ait pas de rupture entre chacune des tranches horaires, je te propose de rendre progressive l’actuelle répartition par 1/6eme sur chacun des pas dans array_pv_10mn_temp.
Voici le principe où chacune des valeurs ci-dessous est mise ‹ à sa place › dans array_pv_10mn_temp:
Heure pleine
A chaque ‹ pas 0 › de chaque heure (8h00, 9h00…), on calcule sa valeur en divisant l’énergie de cette tranche par 6 (par ex. 2451 / 6 à 14h, 2484 / 6 pour 15h)
Calcul des variations entre l’heure X et l’heure suivante
Pour chaque créneau horaire, on fait une simple soustraction entre les valeurs au pas 0. Par ex. pour la tranche 14h-15h: valeur 15h00 - valeur 14h00, soit 414-408,5 = 5,5, etc.
Calcul des autres pas
Pour faire, il y a 3 formules suivant l’évolution d’hue heure à l’autre: 1/ La valeur de l’heure X = celle de l’heure suivante
Chacune des valeurs intermédiaires (par ex. 8h10, 8h20… 8h50) = la valeur du pas 0 de cette heure. Les 6 valeurs sont donc identiques comme tu le fais aujourd’hui. 2/ La variation de l’heure X est positive
Valeur ‹ heure X 10mn › = valeur ‹ heure X › + (variation ‹ heure X › * 1 / 6)
Valeur ‹ heure X 20mn › = valeur ‹ heure X › + (variation ‹ heure X › * 2 / 6)
Valeur ‹ heure X 30mn › = valeur ‹ heure X › + (variation ‹ heure X › * 3 / 6)
Valeur ‹ heure X 40mn › = valeur ‹ heure X › + (variation ‹ heure X › * 4 / 6)
Valeur ‹ heure X 50mn › = valeur ‹ heure X › + (variation ‹ heure X › * 5 / 6) 3/ La variation de l’heure X est négative
Valeur ‹ heure X 10mn › = valeur ‹ heure X › + (valeur ‹ heure X+1 › - valeur ‹ heure X ›)* 1 / 6
Valeur ‹ heure X 20mn › = valeur ‹ heure X › + (valeur ‹ heure X+1 › - valeur ‹ heure X ›)* 2 / 6
Valeur ‹ heure X 30mn › = valeur ‹ heure X › + (valeur ‹ heure X+1 › - valeur ‹ heure X ›)* 3 / 6
Valeur ‹ heure X 40mn › = valeur ‹ heure X › + (valeur ‹ heure X+1 › - valeur ‹ heure X ›)* 4 / 6
Valeur ‹ heure X 50mn › = valeur ‹ heure X › + (valeur ‹ heure X+1 › - valeur ‹ heure X ›)* 5 / 6
Ainsi, les progressions positives et négatives se rapprochent de la courbe et effacent les paliers.
PS: Pour mon précédent exemple, je retrouve ainsi une heure de fin à 17h20 pour 167Wh (1000W/6).
Merci pour la nouvelle proposition mais pour le moment je suis partis sur la façon de calculer avec les W comme je l’avais indiqué dans le précédent post.
Me semble que ça fonctionne comme il faut mais du coup ça change totalement l’idée de sortir la meilleure PROD au plus tôt ou au plus tard.
Du coup je suis en train (normalement fini) de recoder la fonction pour sortir une proposition différente de ce que j’avais fait à l’origine suite à nos échanges … mais ça me perturbe.
Au départ avec la méthode de calcul je pouvais avoir régulièrement plusieurs valeurs identiques pour totaliser la meilleure PROD et c’est pourquoi j’avais prévu le paramètre pour sortir l’heure au plus tôt ou au plus tard (parmi cette valeur de meilleure prod)
Ce que je redéveloppe ne tient finalement plus compte de LA MEILLEURE PROD (le maximum possible) mais de l’heure le plus tôt ou le plus tard pour que la demande soit réalisable.
Je pense que je fais une bêtise puisque dans mon esprit il était intéressant de sortir le moment où la PROD était la plus haute possible mais maintenant que (avec la pondération), il n’y a plus vraiment de valeurs identiques … ça n’a plus de sens de ne considérer que la valeur maximum.
Que faut-il mieux d’après toi ?
Est-ce que c’est OK d’avoir l’heure la plus tôt parmi les possibles ou la plus tard parmi les possibles même si ce n’est pas le maximum de la prod possible ?
Pour moi, l’intérêt est de pouvoir avoir la puissance souhaitée sur le temps donnée dès lors que le niveau de production est ‹ théoriquement › supérieur à la demande.
Le fait d’attendre que la production soit au plus haut sécurise un peu mieux l’autoconsommation.
Mais elle va réduire / interdire la faisabilité des demandes sur des périodes longues.
Le risque est ainsi d’avoir un ‹ no proposal › alors que quelques minutes avant, la production l’aurait permis.
Me concernant, je cherche à avoir la période la plus longue de la journée pour porter une puissance. Avec la ‹ meilleure production ›, j’aurais une proposition (si possible) mais sur une période plus courte.
Et comme écrit plus haut, si la production de la dernière heure est quasi en-dessous de la puissance souhaitée (990Wh pour 1000W souhaitée), le résultat est de s’arrêter avant cette tranche horaire alors qu’on pourrait encore avoir cette puissance sur plusieurs dizaines de minutes.
En terme de sécurité, les utilisateurs peuvent (devraient) aussi se donner une marge de fonctionnement en demandant un peu plus de puissance que nécessaire (par ex. 1300W demandés pour 1200W nécessaires).
La réponse devrait se rapprocher des meilleures productions
Sinon, tu as raison de garder le principe d’avoir le choix entre ‹ le plus tôt › et ‹ le plus tard ›. Ça répond normalement à tous nos besoins.
Les utilisateurs de cette commande pourraient donner leur avis. Avis qui sera peut être différent du mien
Comme tu as déjà quasi finalisé une nouvelle variante, je veux bien être un des testeurs
Bonjour à vous !
Je suis votre discussion avec intérêt car au-delà de comment découper les prévisions de manière linéaire ou en interpolant, vous parler de cas d’utilisation.
J’avais déjà partagé il me semble une suggestion : Ca part du principe que lorsqu’on lance un équipement type machine à laver ou lave vaisselle, la puissance instantanée varie bcp au cours du cycle.
Par exemple ma machine à laver présente un pic à 2000W pendant 10 minutes, puis reste à quelques centaines de W pendant 1h30. Pour un lave vaisselle on aura des pics au début et à la fin pour le séchage.
Mon idée serait de pouvoir fabriquer des json de puissance consommée de nos équipements en se basant sur une commande info existante (par exemple celle d’une prise commandée). Le JSON pourrait par exemple indiquer la puissance de l’équipement toutes les 10 minutes.
Et donc on donnerait ce json à manger à une commande du plugin solcast pour savoir quand lancer le cycle, et optionnellement sortir de combien de Wh on dépasserait la prévision : En gros que ça ne sorte pas forcément : « No Proposal » mais plutôt "Heure de lancer optimale = hhmm avec dépassement de xxkWh.
Ainsi on peut décider si on lance l’équipement en journée ou si on attend la nuit pour avoir de l’heure creuse.
Si vous voulez je lance un autre sujet, je ne voudrais pas paraitre hors sujet.
Merci à vous !
Merci @TonioBDS de ton retour en terme d’usage qui va au-delà de la question posée
En terme de développement, j’imagine qu’il faudrait créer des équipements dans le plugin (des équipements ‹ fils ›) à paramétrer avec les courbes de consommation de chaque équipement physique.
Ces équipements ‹ fils › permettraient ainsi de composer le Json de chaque équipement.
En terme de conso irrégulière ,c’est un peu pareil avec une PAC qui consommera 2 ou 3 fois plus au démarrage et 2 ou 3 fois plus de temps en temps à un rythme dépendant des températures, donc non prévisible.
Et je sais qu’il y aura des moments où je ne serai plus en autoconsommation (sans compter la météo changeante et les consos imprévisibles (congélateur, réfrigérateur…)).
Maintenant, si je peux éviter de payer 6kW pendant 3h (4,5€) et ne régler que 30mn sur cette période à 1kW (<> 8cts €), il n’y a pas photo
@TonioBDS, ton message est une optimisation complémentaire où seul @Bison peut y répondre
On va déjà essayer d’avancer gentiment sur ce qu’avait repéré @micheld et qui se transforme en une nouvelle façon de gérer le truc et puis on verra après.
Maintenant faut quand même pas oublier une chose, et c’est aussi LA raison pour laquelle je n’avais pas non plus été très loin dans cette fonctionnalité : La base repose sur des prévisions !
Si on « s’excite » à faire quelque chose avec des extrapolations, des calculs bien lourd avec des retours à 2W prêt pour gagner 1mn38 sur l’allumage d’un appareil et qu’en fin de compte la prévision n’était juste qu’à 500W prêt … ça ne sert absolument à rien
Alors honnêtement je veux bien écouter prendre des idées et modifier, c’est intellectuellement intéressant, mais je pense pas qu’il soit bien utile de faire du Tetris en essayant de faire rentrer dans une prévision 1 machine qui consomme 2000 W pendant 78s puis 38 W pendant 75mn en même temps qu’une autre qui consomment 450 W pendant 23mn puis 120W pendant 16mn …
Hello,
Je comprends bien entendu les réactions, d’une part pour ce qui est d’avancer progressivement, et d’autre part parce qu’en effet, faire une usine à gaz de précision en utilisant une donnée qui selon les jours est parfois absolument imprécise.
Je vous mets ci-dessous avec un peu de recul le besoin utilisateur plutôt qu’une proposition de solution, puis on ferme la parenthèse le temps que les modifs en cours soient achevées.
Donc, mon besoin utilisateur est que je pense passer très prochainement sur l’offre EDF TEMPO. J’ai simulé que globalement l’offre TEMPO était financièrement plus intéressante pour moi, mais je sens que je vais me rajouter une charge mentale, je m’explique : Je suis habitué à lancer tous mes équipements en journée pour prendre le soleil, et quand y en n’a pas bah tant pis, je tire sur le réseau.
Demain avec Tempo j’aurais 6 tarifications avec des heures pleines et creuses, je sens que je vais sans arrêt me demander s’il vaut mieux lancer un équipement en journée ou attendre 22h pour passer en heure creuse.
Et donc parfois, même si on n’a pas assez de soleil pour entièrement couvrir la consommation d’un équipement, il se pourrait que ce soit quand même intéressant de le lancer en journée parce que le delta de kWh qui dépasse de la production, x tarif kWh, donc le coût, resterait plus intéressant que l’énergie totale consommée la nuit à un tarif moindre. Le taux de confiance serait alors utile pour donner une plage de coût par ex…
Bref, tout ça tout ça.
Merci de m’avoir écouté
Comme tu l’as indiqué, ce beau projet en perspective nécessiterait un sujet qui lui serait propre
En fait, un seul plugin ne fera pas tout ce que tu as besoin.
Il existe plusieurs plugins EDF TEMPO qui permettent de connaître la couleur des jours avec d’autres informations utiles.
Le plugin Solcast sera celui qui te permet d’avoir ta production estimée sur la journée et définira ou pas un créneau pour un usage donné.
Pour moi, ton projet s’appuierait sur plusieurs scénarios utilisant tous ces outils (voire d’autres !).
Et suivant tes propres critères de fonctionnement, ils déclencheraient ou pas certaines consommations commandables en parallèle de ton talon de consommation ingérable.
Si tu as déjà planché sur comment le mettre en œuvre (par ex. que ferais-tu s’il n’y avais aucun créneau proposé sur plusieurs jours consécutifs ‹ verts › alors que le lave-vaisselle est plein ?), je te conseille de créer un sujet
Des avis d’utilisateurs ayant une configuration TEMPO pourraient aussi t’aider dans la réflexion. Et suivant l’intérêt porté, il pourrait aboutir à une adaptation du plugin de @Bison
Je ne connais pas personnellement @Bison, mais je ne me trompe pas en disant que c’est une personne à l’écoute de toutes bonnes idées
PS: Il y a des années, j’étais en contrat EDF EJP.
A savoir qu’il y aura forcément plusieurs jours d’affiler sur un/des tarifs ‹ fort ›.
et à certains moments, il faudra quand même consommer (lessives, sèche cheveux, plaques…). Ou alors ramener des consos sur des périodes ‹ plus vertes › qui seraient alors chargés en conso même s’il n’y a quasi pas de production…
En tout cas, je te souhaite une bonne réflexion pour la suite et surtout que ton projet aboutisse
J’ai laissé un peu de log pour mieux voir la raison de telle ou telle proposition mais si c’est tout bon je retirerais ça, il y a déjà bien assez de logs dans ce plugin
J’ai modifié aussi le menu concernant le calcul de cette heure de démarrage.
Je pense que les 2 premiers sont assez clair, le 3eme vérifie donc si c’est possible uniquement avec le moment ou il y a le plus de PROD sur la tranche horaire choisie.
On voit que la condition #[XX][YY][Heure de démarrage en fonction de la durée demandée]# != 0 répond 2359 au lieu de no proposal. solcast.txt (19,4 Ko)
Des quelques watts d’estimation j’essaye de faire quelques tests. Mais ce ne sera surement pas très concluant
Dans le 3eme choix ajouté dans le calcul de la meilleure heure de démarrage de l’équipement, il manque un ‹ t › pour ‹ quantité ›.
Un encadré affiche le démarrage d’un appareil à 23h59 pour 200mn. Je ne souviens plus si (l’âge peut être) c’était le cas avant… Mais dans la pratique, ce ne serait pas possible à cette heure
Pour moi les valeurs de array_pv_10mn_temp seraient correctes (linéaires).
Un petit problème qui limite les recherches d’un créneau sur quelques dizaines de minutes. solcast.txt (22,5 Ko)
Dans array_pv_10mn, quand tu ‹ reprends › les valeurs de array_pv_10mn_temp à partir de l’heure actuelle, on ne retrouve que les premiers pas de 10mn et toutes les valeurs suivantes sont à zéro.
J’imagine que les ‹ 2359 › proviendraient de là…
Analyse des logs, pas du code d’où les parenthèses
Par contre, il faudra bien une production réelle de 2400W en permanence sur ces 30mn si je souhaite être en full autoconsommation.
et les consos imprévisibles (congélateur, réfrigérateur…)).
