Hi @StephaneB, thanks for the logs!
Verdict: it is indeed phase 2 (the cost recalculation), and your log proves it alone.
The exact sequence of your window 11:30 → 11:48
There are two different tasks in your log, and their comparison is enlightening:
| Time |
What’s running |
Duration |
| 11:30:00 → 11:30:07 |
Consumption calculation from indexes (31 index/30-min pairs) |
7 s |
| 11:30:07 |
Production calculation from indexes (0 device) |
Instantaneous |
| 11:30:07 → 11:30:15 |
Cost recalculation, 25 devices, window = 30 minutes |
8 s  |
| 11:36:26 → 11:36:27 |
Enedis, daily consumption, since 14/08 (8 points) |
1 s |
| 11:36:27 → 11:37:02 |
Enedis, load curve, since 15/08 (384 points) |
35 s |
| 11:37:02 → 11:48:03 |
Cost recalculation, 25 devices, window = 8 days |
11 min  |
The same code, the same 25 devices, executed twice with a 7-minute interval: 8 seconds in one case, 11 minutes in the other. The only variable is the width of the recalculated window: 30 minutes against 8 days.
And 11:36:26 → 11:48:03 = 11 min 40, which matches the ~12 min displayed on the task.
By the way, the 36 s of phase 1 are normal and intentional: Gladys inserts the load curve points with a 50 ms delay between each to avoid overloading the CPU during import. 384 points × 50 ms ≈ 35 s. That’s exactly what we see. Nothing to correct on this side.
Your 4 questions
1. « My sync does not restart from zero » — Correct, no issues here. after 2026-08-14, it is indeed the last synchronized date minus 7 days. The bug I feared is not there.
Small clarification: if you see two different dates (14/08 then 15/08), it is not an anomaly — these are your two Enedis features (daily consumption and load curve) each keeping their own last sync date.
2. « Are the Inserting chunk 0 signs? » — Yes, it is exactly the right marker, but be careful not to mix the two blocks:
- 31 lines between 11:30:07 and 11:30:15 → the routine task. ~0.25 s per feature.
- 32 lines between 11:37:20 and 11:48:03 → the recalculation triggered by Enedis. ~20 s per feature.
Relative to the number of points processed (384 load curve points over 8 days against 1 over 30 minutes), that’s about 55 ms per recalculated point. That’s too much, and it’s on my end now.
3. The different « Found N » (79 / 31 / 0 / 0 / 25…) — Everything is normal, these are counters that do not count the same thing:
- 79 = devices with a feature of category
energy_sensor, switch or teleinformation (the broad pool where we look for indexes).
- 31 = among them, the number of pairs « index ↔ 30-minutes » connected to each other. Note that the message says « devices » but actually counts pairs of features — that’s why « Compteur Zlinky » appears 7 times in a row right after: your Zlinky exposes several indexes (EASF01…EASF10 for Tempo).
- 0 / 0 = the same on the production side. You don’t have a production index declared (your panels are tracked via a plug, so on the consumption side), so 0. Normal.
- 25 = the cost recalculation filter, which is more restrictive (only the
energy_sensor category). This line appears once per cost recalculation — hence its repetition.
4. « Two overlapping cycles? » — No, rest assured, and it’s even impossible: everything goes through a queue that serializes the processes. What you see are two distinct tasks:
- the one at 11:30, scheduled every 30 minutes (at HH:00 and HH:30);
- the one at 11:36, the hourly Enedis sync, which calls the cost recalculation at the end.
Both call the same function, hence the duplicate lines.
Why 11 minutes for you and 5 seconds for @PhilippeMA
Because the post-sync recalculation does not take into account what has actually changed, nor the size of the installation:
- it starts from the oldest date resynchronized, so always ~D-8 (due to the 7-day safety net);
- and it replays all your energy devices, not just Enedis.
For you, that’s ~33 cost features × 8 days × 48 points, so about 12,000 points deleted, recalculated, and reinserted every hour — while only the Enedis feature has received new data. For Philippe, with one or two devices, the same process goes unnoticed.
You are not doing anything wrong: you are just the first to have a large enough installation to make the problem visible.
What I will fix
This is a real design flaw, not a problem with your installation.
I proposed a PR with:
- Only recalculate what has moved: after an Enedis sync, only the features actually impacted should be retaken, not the entire fleet.
- Only recalculate the days actually modified, instead of a fixed 8-day window for each cycle.
- Optimize the internal loop (the 55 ms per point): the validity periods of the rates are rebuilt with time zone conversion for each point, when they could be done only once.
- Bring phase 2 up in the progress bar: today it only follows the download, hence the task that remains « in progress » at 100% for 10 minutes.
