Hallo @StephaneB, danke für die Logs!
Urteil: Es ist tatsächlich Phase 2 (die Neuberechnung der Kosten), und dein Log beweist es allein.
Der genaue Ablauf deines Fensters 11:30 → 11:48
In deinem Log gibt es zwei verschiedene Aufgaben, und ihr Vergleich ist aufschlussreich:
| Zeit |
Was läuft |
Dauer |
| 11:30:00 → 11:30:07 |
Berechnung des Verbrauchs aus den Indizes (31 Indexpaare/30-Minuten) |
7 s |
| 11:30:07 |
Berechnung der Produktion aus den Indizes (0 Gerät) |
sofort |
| 11:30:07 → 11:30:15 |
Neuberechnung der Kosten, 25 Geräte, Fenster = 30 Minuten |
8 s  |
| 11:36:26 → 11:36:27 |
Enedis, täglicher Verbrauch, seit dem 14/08 (8 Punkte) |
1 s |
| 11:36:27 → 11:37:02 |
Enedis, Lastkurve, seit dem 15/08 (384 Punkte) |
35 s |
| 11:37:02 → 11:48:03 |
Neuberechnung der Kosten, 25 Geräte, Fenster = 8 Tage |
11 min  |
Der gleiche Code, die gleichen 25 Geräte, zweimal in einem Abstand von 7 Minuten ausgeführt: 8 Sekunden in einem Fall, 11 Minuten im anderen. Die einzige Variable ist die Breite des neu berechneten Fensters: 30 Minuten gegen 8 Tage.
Und 11:36:26 → 11:48:03 = 11 min 40, was mit den angezeigten ~12 min der Aufgabe übereinstimmt.
Übrigens sind die 36 s der Phase 1 normal und beabsichtigt: Gladys fügt die Lastkurvenpunkte mit einer Verzögerung von 50 ms zwischen jedem hinzu, um den CPU nicht während des Imports zu überlasten. 384 Punkte × 50 ms ≈ 35 s. Genau das sehen wir. Nichts zu korrigieren auf dieser Seite.
Deine 4 Fragen
1. « Meine Synchronisation startet nicht bei Null » — Richtig, alles in Ordnung auf dieser Seite. after 2026-08-14, das ist das letzte synchronisierte Datum minus 7 Tage. Der Bug, den ich befürchtet habe, ist nicht da.
Kleine Präzisierung am Rande: Wenn du zwei verschiedene Daten siehst (14/08 dann 15/08), ist das keine Anomalie — das sind deine beiden Enedis-Funktionalitäten (täglicher Verbrauch und Lastkurve), die jeweils ihr eigenes Datum der letzten Synchronisation haben.
2. « Sind die Inserting chunk 0 das Zeichen? » — Ja, das ist genau der richtige Marker, aber Achtung, nicht die beiden Blöcke vermischen:
- 31 Zeilen zwischen 11:30:07 und 11:30:15 → die Routineaufgabe. ~0,25 s pro Funktionalität.
- 32 Zeilen zwischen 11:37:20 und 11:48:03 → die Neuberechnung, die von Enedis ausgelöst wurde. ~20 s pro Funktionalität.
Bezogen auf die Anzahl der verarbeiteten Punkte (384 Lastkurvenpunkte über 8 Tage gegen 1 in 30 Minuten), das sind etwa 55 ms pro neu berechnetem Punkt. Das ist viel zu viel, und jetzt liegt es bei mir.
3. Die verschiedenen « Found N » (79 / 31 / 0 / 0 / 25…) — Alles ist normal, das sind Zähler, die nicht dasselbe zählen:
- 79 = Geräte, die eine Funktionalität der Kategorie
energy_sensor, switch oder teleinformation tragen (der breite Pool, in dem nach Indizes gesucht wird).
- 31 = darunter die Anzahl der Paare « Index ↔ 30-Minuten », die miteinander verbunden sind. Achtung, die Nachricht sagt « Geräte », zählt aber tatsächlich Funktionalitätspaare — deshalb erscheint « Zähler Zlinky » siebenmal hintereinander direkt danach: Dein Zlinky zeigt mehrere Indizes (EASF01…EASF10 für Tempo).
- 0 / 0 = dasselbe auf der Produktionsseite. Du hast keinen Produktionsindex deklariert (deine Panels werden über eine Steckdose verfolgt, also auf der Verbrauchsseite), also 0. Normal.
- 25 = der Filter der Kostenneuberechnung, der restriktiver ist (nur die Kategorie
energy_sensor). Diese Zeile erscheint einmal pro Kostenneuberechnung — daher ihre Wiederholung.
4. « Zwei sich überlappende Zyklen? » — Nein, beruhige dich, und es ist sogar unmöglich: Alles läuft über eine Warteschlange, die die Verarbeitungen serialisiert. Was du siehst, sind zwei separate Aufgaben:
- die von 11:30, die alle 30 Minuten geplant ist (um HH:00 und HH:30);
- die von 11:36, die stündliche Enedis-Synchronisation, die die Kostenneuberechnung am Ende aufruft.
Beide rufen dieselbe Funktion auf, daher die doppelten Zeilen.
Warum 11 Minuten bei dir und 5 Sekunden bei @PhilippeMA
Weil die Neuberechnung nach der Synchronisation weder berücksichtigt, was sich tatsächlich geändert hat, noch die Größe der Installation:
- Sie beginnt mit dem ältesten neu synchronisierten Datum, also immer ~J-8 (aufgrund der 7-Tage-Sicherheitsnetz);
- und sie spielt alle deine Energiegeräte ab, nicht nur Enedis.
Bei dir sind das ~33 Kostenfunktionalitäten × 8 Tage × 48 Punkte, also in der Größenordnung von 12.000 Punkten, die jede Stunde gelöscht, neu berechnet und wieder eingefügt werden — obwohl nur die Enedis-Funktionalität neue Daten erhalten hat. Bei Philippe, mit einem oder zwei Geräten, bleibt dieselbe Verarbeitung unbemerkt.
Du machst nichts falsch: Du bist nur der Erste, der eine große enough Installation hast, um das Problem sichtbar zu machen.
Was ich korrigieren werde
Es ist ein echtes Design-Defizit, kein Problem deiner Installation.
Ich habe einen PR mit vorgeschlagen:
- Nur das neu berechnen, was sich bewegt hat: Nach einer Enedis-Synchronisation sollten nur die tatsächlich betroffenen Funktionalitäten neu aufgenommen werden, nicht der gesamte Park.
- Nur die tatsächlich geänderten Tage neu berechnen, statt eines festen 8-Tage-Fensters bei jedem Zyklus.
- Die interne Schleife optimieren (die 55 ms pro Punkt): Die Gültigkeitsperioden der Tarife werden mit Zeitzonenumrechnung für jeden Punkt neu aufgebaut, obwohl sie einmal aufgebaut werden könnten.
- Phase 2 in der Fortschrittsleiste anzeigen: Heute folgt sie nur dem Herunterladen, daher bleibt die Aufgabe bei 100 % für 10 Minuten „in Bearbeitung“.
