Ok, das ist offensichtlich nicht korrekt. Mal sehen, woran es liegen könnte.

Welche Version des Power-Splitters hast du im Einsatz, develop oder latest (= 0.5.0)? In develop hatte ich vor zwei Tagen etwas verändert, was möglicherweise wieder ein Zeitzonenproblem versuchen könnte. Das müsste ich noch genauer untersuchen.

Falls develop: Tritt das Problem auch mit latest auf? Zur Erinnerung: Um nach einem Wechsel der Version einen Rebuild zu forcieren, geht das mit diesem Statement:

docker compose kill --signal USR1 power-splitter

Der Powersplitter war develop. Ich hab gerade mal auf latest zurückgewechselt und die Berechnung neu laufen lassen. Für die beiden Tage kommt dasselbe Ergebnis 'raus, 635% Netz bzw. 13% PV, also scheint's an der Änderung schonmal nicht zu liegen.

Danke für deine Mühe, ich werde da jetzt mal tiefer nachforschen. Wenn du mir noch einen InfluxDB-Dump der betroffenen Woche geben könntest, wäre das hilfreich.

Gerne, hier die komplette Woche: kw39.csv.gz

Sehr gut, danke, damit habe ich eine perfekte Grundlage. Sieht nach einem interessanten Edge-Case aus. Melde mich wieder.

Mittlerweile habe ich eine Ursache ausfindig machen können:

Der Power-Splitter kann ja nur eine Näherung durchführen. Der Tag wird in 1-Minuten-Abschnitte aufgeteilt und jeder Abschnitt dann separat betrachtet. Für jede Minute wird gemittelt und der Netzbezug auf die Verbraucher aufgeteilt. Dies wird wiederum für 5-Minuten-Abschnitt hochgerechnet, um möglichst wenig Datenpunkte zu erzeugen. Dabei kann es passieren, dass ein Verbraucher etwas zu wenig Netzbezug zugeteilt bekommt - insbesondere dann, wenn ein hoher Verbrauch (wie z.B. Wallbox) innerhalb eines 5-Minuten-Abschnitts startet. Das gleicht sich dann üblicherweise aus, wenn der Verbraucher wieder ausgeschaltet wird.

Wenn aber der Verbrauch vor Mitternacht beginnt, aber nach Mitternacht (als am nächsten Tag) endet, kann sich das für diesen Tag nicht ausgleichen, sodass in der Summe etwas Netzbezug fehlt und fälschlicherweise etwas PV (als Differenz) ausgewiesen wird (bei dir: Mittwoch 13 %).

Soweit die Erklärung dafür, aber glücklich bin ich mit der Situation auch nicht. Ich habe probeweise mal die Berechnung auf 5-Sekunden-Abschnitte heruntergebrochen. Der Fehler tritt dann zwar nicht mehr auf, aber der Preis dafür ist mir zu hoch: Es wären wesentlich mehr Datenpunkte und die Berechnung des Power-Splitters wäre erheblich zeitaufwändiger. Das möchte ich daher nicht machen. Einen Kompromiss habe ich auch versucht: 1-Minuten-Abschnitte. Der Fehler wird hier kleiner, aber verschwindet nicht. Das Lohnt nicht.

Fazit: die 13 % PV-Anteil aus deinem Beispiel vom Mittwoch kann ich derzeitig nicht korrigieren. Ich werde mir aber weiter Gedanken dazu machen, ob sich eine bessere Berechnungsmethode finden lässt.

Das andere Problem übrigens, die 635 % Netzanteil vom Freitag, ließen sich hingegen einfach korrigieren. Hier stimmte etwas bei der Berechnung der Balken-Anteile nicht. develop ist aktualisiert. Der Power-Splitter wurde nicht verändert.

Danke! Der Freitag mit den 635% ist damit auch bei mir korrigiert.

Fazit: die 13 % PV-Anteil aus deinem Beispiel vom Mittwoch kann ich derzeitig nicht korrigieren. Ich werde mir aber weiter Gedanken dazu machen, ob sich eine bessere Berechnungsmethode finden lässt.

Könnte evtl folgendes funktionieren: Der Power-Splitter kann ja sowohl Netzbezug als auch PV-Erzeugung zu einem bestimmten Zeitpunkt sehen. Wenn dabei klar ist, dass PV nichts geliefert hat kann er doch sämtliche Berechnungen direkt skippen und den Verbrauch zu 100% dem Netz zuschlagen, oder? (Umgekehrt ginge das natürlich genauso)

Falls diese Idee Murks ist, kann ich aber auch prima damit leben wenn das so bleibt und in solchen Randfällen eben eine gewisse Ungenaugkeit besteht.

Ganz so einfach ist es nicht: Es wäre nicht nur die PV-Erzeugung zu prüfen, sondern auch die Akku-Entnahme. Denn der Akku kann auch die Beladung des E-Autos unterstützen (zumindest bei der SENEC-Wallbox ist das so). Bei der Wärmepumpe ja ist das sowieso üblich, dass der Strom aus dem Akku genommen wird. Das heißt: Nächtlicher Stromverbrauch bedeutet nicht, dass der PV-Anteil 0% ist.

Insofern wäre der Algorithmus ein ganz anderer: Es müsste alle drei Quellen (Netz, Akku, Erzeugung) auf die Verbraucher verteilt werden. Da fehlen mir momentan die Idee, wie das aussehen könnte.

Ich würde daher eher einen anderen Ansatz verfolgen: Kleinere Zeitfenster unter Einkaufnahme höherer Berechnungszeit, aber die Speicherung der Netzanteile nicht mehr in InfluxDB, sondern als Tagessumme in PostgreSQL.

Es gibt diverse Bereiche in SOLECTRUS, die von einer separaten Ablage aggregierter Werte profitieren würden. Da werde ich weiter drüber nachdenken.

OK, verstehe. Da mein konkretes Issue gelöst wurde mach in dann hier mal zu...