Dans le log ci-dessus, je demandais à 15h35 ‹ 100W sur 90mn ›.
Dans array_pv_10mn_temp, il y a 123W à 17h40, soit 2 heures après.
Et la réponse est 2359
Ma requête est avec l’option de calcul de la meilleure heure de démarrage : first
A priori, tu commences l’étude de faisabilité à 15h40 avec la valeur 268 qui est celle de 16h50.
Comme il manque 1h10 de valeurs, je pense que c’est pour çà qu’il ne trouve pas de créneau.
Demandant avec le choix ‹ plus tôt ›, je pense que l’ordre des recherches par pas de 10mn est particulier. Toute la journée est couverte mais dans un ordre étrange
Peut être une optimisation de charge Jeedom possible en sortant de cette boucle de test par pas de 10mn dès que la 1ere valeur testée est à 0 et/ou réduire la fourchette de test (pas beaucoup de prod passé 22h par ex.)
Il ne me semble pas avoir touché à un truc coté index
Ta première valeur (38 W) est déterminé à 11h alors que dans le retour de l’API la première valeur non nulle est entre 12h et 13h à 225 Wh, il y a donc bien un truc qui ne va pas là
L’ordre est bizarre par ce qu’il parcours dans l’ordre de la plus grande quantité d’énergie à la plus faible.
Les optimisations se sera pour la fin, pour le moment comme on peut le voir il y a des problèmes basiques et qui n’existaient pas avant.
Bon … je vais revoir tout ça désolé, je vais trop vite là.
Non il y avait bien un truc qui n’allait pas, les valeurs de array_pv_10mn_temp étaient, en gros, décalées d’une heure.
J’ai corrigé aussi le découpage, c’est pareil il y a un truc qui n’allait pas selon moi et on se retrouvait avec des 'heures piles" qui étaient différentes après découpage de la tranche horaire.
J’ai également optimisé pour stopper le traitement dès la rencontre d’un 0. J’avais un peu peur de rater des cas (dans le cas de la recherche au plus tard) mais comme je trie par ordre de plus grande quantité d’énergie je pense pas que ça se produise pas.
Nouvelle bêta publiée, à voir si c’est bon de ton coté mais on devrait être bon cette fois.
Zut j’ai oublié de corriger l’erreur, ça sera pour la prochaine version
Bonjour @Bison,
Je suis rentré trop tard pour faire des tests mais j’ai pu en faire pour '50:10" au vu de la production qui se termine.
J’ai eu 2 créneaux proposés :
heure de début identique pour le ‹ plus tôt › et ‹ la meilleure quantité ›;
décalé pour le ‹ plus tard ›.
Ce n’est pas représentatif, mais les résultats paraissent justes
Demain, je devrais pouvoir en faire sur des périodes avec estimations de production montantes et descendantes.
S’il y avait d’autres testeurs de ce beta, ce serait encore mieux comme validation
J’ai fait quelques essais et par exemple, cette demande de 900W sur 250mn.
La réponse est OK à partir de 11h alors que çà devrait être ‹ No proposal ›.
Cette réponse aurait été juste pour 240mn.
A la ligne 229 des logs, on voit bien les 25 valeurs trouvées supérieures à 900 commençant à 11h jusqu’à 15h.
Sauf que 25 valeurs font 24 intervalles de 10mn (soit 240mn)
Avec la modification 'ligne 282 du fichier plugins/solcast/core/class/solcast.class.php’, pour moi, c’est impeccable pour les tests ‹ plus tôt › et ‹ plus tard ›
J’imagine que ce sera identique pour le choix ‹ meilleure quantité… ›.
Mais comme je suis (comme tout le monde !) en phase décroissante des estimations de production, les résultats sont identiques à ‹ plus tôt ›.
Je ferai des tests demain matin, afin d’avoir des prévisions plus hautes après mes requêtes.
J’ai donc fait des tests avec les 3 choix ‹ Calcul de la meilleure heure de démarrage ›.
Il me restais celui ‹ réalisable pour la meilleure quantité de production uniquement ›, qui permet d’avoir le début de créneau quand les prévisions sont au plus haut. PS: cette nouvelle possibilité sera plus sécurisant pour les personnes recherchant une autoconsommation « plus assurée » dans la journée (si la météo ne change évidemment pas entre temps !).
Et tous mes tests montrent que ton plugin répond bien à ce dernier choix.
Voici pour exemples:
A moins que tu ne souhaites apporter d’autres modifications (on ne sait jamais !), tu pourras réduire les logs comme tu le précisais avant de nous proposer une nouvelle version stable.
Sans oublier le petit t de quantité et d’appliquer la dernière modification en ligne 282
J’attends ton retour pour clôturer ou pas ce sujet
Nouvelle bêta publiée, à voir si c’est bon de ton coté mais on devrait être bon cette fois.
