Salut @StephaneB, merci pour les logs !
Verdict : c’est bien la phase 2 (le recalcul des coûts), et ton log le prouve tout seul.
Le déroulé exact de ta fenêtre 11:30 → 11:48
Il y a deux tâches différentes dans ton log, et c’est leur comparaison qui est éclairante :
| Heure |
Ce qui tourne |
Durée |
| 11:30:00 → 11:30:07 |
Calcul de la conso depuis les index (31 paires index/30-min) |
7 s |
| 11:30:07 |
Calcul de la production depuis les index (0 appareil) |
instantané |
| 11:30:07 → 11:30:15 |
Recalcul des coûts, 25 appareils, fenêtre = 30 minutes |
8 s  |
| 11:36:26 → 11:36:27 |
Enedis, conso quotidienne, depuis le 14/08 (8 points) |
1 s |
| 11:36:27 → 11:37:02 |
Enedis, courbe de charge, depuis le 15/08 (384 points) |
35 s |
| 11:37:02 → 11:48:03 |
Recalcul des coûts, 25 appareils, fenêtre = 8 jours |
11 min  |
Le même code, les mêmes 25 appareils, exécuté deux fois à 7 minutes d’intervalle : 8 secondes dans un cas, 11 minutes dans l’autre. La seule variable, c’est la largeur de la fenêtre recalculée : 30 minutes contre 8 jours.
Et 11:36:26 → 11:48:03 = 11 min 40, ce qui colle avec les ~12 min affichées sur la tâche.
Au passage, les 36 s de la phase 1 sont normales et volontaires : Gladys insère les points de courbe de charge avec un délai de 50 ms entre chacun pour ne pas saturer le CPU pendant l’import. 384 points × 50 ms ≈ 35 s. C’est exactement ce qu’on voit. Rien à corriger de ce côté.
Tes 4 questions
1. « Ma synchro ne repart pas de zéro » — Exact, RAS de ce côté. after 2026-08-14, c’est bien la dernière date synchronisée moins 7 jours. Le bug que je redoutais n’est pas là.
Petite précision au passage : si tu vois deux dates différentes (14/08 puis 15/08), ce n’est pas une anomalie — ce sont tes deux fonctionnalités Enedis (conso quotidienne et courbe de charge) qui tiennent chacune leur propre date de dernière synchro.
2. « Est-ce que les Inserting chunk 0 sont le signe ? » — Oui, c’est exactement le bon marqueur, mais attention à ne pas mélanger les deux blocs :
- 31 lignes entre 11:30:07 et 11:30:15 → la tâche de routine. ~0,25 s par fonctionnalité.
- 32 lignes entre 11:37:20 et 11:48:03 → le recalcul déclenché par Enedis. ~20 s par fonctionnalité.
Rapporté au nombre de points traités (384 points de courbe de charge sur 8 jours contre 1 seul sur 30 minutes), ça fait environ 55 ms par point recalculé. C’est beaucoup trop, et c’est chez moi maintenant.
3. Les « Found N » différents (79 / 31 / 0 / 0 / 25…) — Tout est normal, ce sont des compteurs qui ne comptent pas la même chose :
- 79 = appareils portant une fonctionnalité de catégorie
energy_sensor, switch ou teleinformation (le vivier large où on cherche des index).
- 31 = parmi eux, le nombre de couples « index ↔ 30-minutes » reliés entre eux. Attention, le message dit « devices » mais compte en réalité des couples de fonctionnalités — c’est pour ça que « Compteur Zlinky » revient 7 fois d’affilée juste après : ton Zlinky expose plusieurs index (EASF01…EASF10 pour Tempo).
- 0 / 0 = la même chose côté production. Tu n’as pas d’index de production déclaré (tes panneaux sont suivis via une prise, donc côté conso), donc 0. Normal.
- 25 = le filtre du recalcul de coût, qui est plus restrictif (uniquement la catégorie
energy_sensor). Cette ligne apparaît une fois par recalcul de coût — d’où sa répétition.
4. « Deux cycles qui se chevauchent ? » — Non, rassure-toi, et c’est même impossible : tout passe par une file d’attente qui sérialise les traitements. Ce que tu vois, ce sont deux tâches distinctes :
- celle de 11:30, planifiée toutes les 30 minutes (à HH:00 et HH:30) ;
- celle de 11:36, la synchro Enedis horaire, qui appelle le recalcul des coûts en fin de course.
Les deux appellent la même fonction, d’où les lignes en double.
Pourquoi 11 minutes chez toi et 5 secondes chez @PhilippeMA
Parce que le recalcul post-synchro ne tient compte ni de ce qui a réellement changé, ni de la taille de l’installation :
- il repart de la date la plus ancienne resynchronisée, soit toujours ~J-8 (à cause du filet de sécurité de 7 jours) ;
- et il rejoue tous tes appareils énergie, pas seulement Enedis.
Chez toi, ça fait ~33 fonctionnalités de coût × 8 jours × 48 points, soit de l’ordre de 12 000 points supprimés, recalculés et réinsérés chaque heure — alors que seule la fonctionnalité Enedis a reçu de nouvelles données. Chez Philippe, avec un ou deux appareils, le même traitement passe inaperçu.
Tu ne fais rien de travers : tu es juste le premier à avoir une installation assez grosse pour rendre le problème visible.
Ce que je vais corriger
C’est un vrai défaut de conception, pas un problème de ton installation.
J’ai proposé une PR avec :
- Ne recalculer que ce qui a bougé : après une synchro Enedis, seules les fonctionnalités réellement impactées doivent être reprises, pas la totalité du parc.
- Ne recalculer que les jours réellement modifiés, au lieu d’une fenêtre fixe de 8 jours à chaque cycle.
- Optimiser la boucle interne (les 55 ms par point) : les périodes de validité des tarifs sont reconstruites avec conversion de fuseau horaire pour chaque point, alors qu’elles pourraient l’être une seule fois.
- Faire remonter la phase 2 dans la barre de progression : aujourd’hui elle ne suit que le téléchargement, d’où la tâche qui reste « en cours » à 100 % pendant 10 minutes.
