76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...

Wenn nur nach aufsteigendem Überschuss sortiert wird, dann kann es in der Tat bei zwei gleichen Überschüssen zu einem Problem kommen, wenn Du Dir zur Berechnung der Ladeempfehlung immer den ersten Eintrag schnappst. Wenn Du Dir aber den Eintrag mit größter (Rest-)Stundenzahl wählst, dann sollte vorgenanntes Problem nicht mehr existieren, richtig?

Ja, allerdings ist das ein unnötiger Performancefresser, weil ich immer! den Nachfolger mit dem Vorgänger vergleichen müßte.
...

Welchen Sortieralgorithmus nimmst Du denn?

[DS_Starter]

sort { $hsurp->{$a}{spswh} <=> $hsurp->{$b}{spswh} } keys %{$hsurp};   

[Parallix]

sort { $hsurp->{$a}{spswh} <=> $hsurp->{$b}{spswh} } keys %{$hsurp};   

Dann könntest Du doch die zweistellig dargestellte Stundenzahl, z.B. als Nachkommastelle, an das zu sortierende Element anhängen und könntest in einem Aufwasch diese beim Sortieren mitberücksichtigen.

[DS_Starter]

Probier ich aus. Muß man dann halt wieder auseinandersplitten.

[DS_Starter]

In meinem contrib liegt die V 1.58.2.
Die besprochene Problematik sollte gelöst sein. Die Sortierung habe ich auch erweitert.


Jetzt ist im Debug nicht mehr viel zu sehen, aber bei Surplus ist die Anzahl der noch folgenden Stunden mit diesem Überschuß angedruckt:

Code Auswählen Erweitern

2025.09.10 15:29:39.078 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 25723 Wh, Surplus: 481 Wh (0 hours), OptTargetPower: 481 W, safety: 20 %
2025.09.10 15:29:39.078 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.079 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
2025.09.10 15:29:39.080 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OptTargetPower: 1000 W, safety: 20 %
LG,
Heiko

[Parallix]

Ein Sache ist mir heute Abend noch (mit dem alten Code) aufgefallen: Obgleich bei mir ja loadAbort=99:686:95 ist und der nächste "care cycle" erst in einigen Tagen ansteht (Konfiguration siehe weiter oben), empfiehlt SF auch nach Erreichen eines SOC von 95 % eine nicht verschwindende Ladeleistung. Dies ist mir nur deshalb aufgefallen, weil ich zu Testzwecken derzeit keine Auswertung von Battery_ChargeAbort_XX vornehme. Sichtbar wird das ganze aber auch dadurch, dass die Ladekurve nicht asymptotisch gegen 95 % geht, sondern einen Knick hat und das natürlich leider nach Erreichen eines SOC von ungewollten 100%.

[DS_Starter]

Obgleich bei mir ja loadAbort=99:686:95 ist und der nächste "care cycle" erst in einigen Tagen ansteht (Konfiguration siehe weiter oben), empfiehlt SF auch nach Erreichen eines SOC von 95 % eine nicht verschwindende Ladeleistung.

Ja, es werden lediglich die Abbruchbedingungen geprüft und davon abhängig das Reading Battery_ChargeAbort_XX gesetzt. Was der User mit dieser Info macht, liegt in seiner Hand.
Aber abgesehen davon wäre bei loadAbort=99:686:95 der SoC 99% eine der Abbruchbdingungen und <95% wieder die Freigabe. Davon abhängig wäre Battery_ChargeAbort_XX=0|1.

[Hadl]

Man kann sich auch nur auf die Werte des einen oder des anderen Readings bei der Steuerung des Akkus stützen

Heute hatte ich damit nen Tag an dem das Akku laden basierend auf Battery_ChargeOptTargetPower_01 schief gegangen ist und ich tagsüber eingespeist habe und Abends schon zukaufen musste. Zugegeben war der Verbrauch Nachmittags ungewöhnlich hoch.

Wie man sieht wurde der Akku ab 14:30 leerer, aber die Battery_ChargeOptTargetPower_01 (lila Punkte) Leistung stieg nur leicht an.
Ab 16:00 Uhr als der Akku nur noch 60% (grüne Linie) hatte stand er auf 1000W
Von 18:00 -19:00 Uhr als der Akku nor noch ca. 20% hatte stand Battery_ChargeOptTargetPower_01 dann auf 79-105W. In der Zeit war der Hausverbrauch aber gering und ich habe den ganzen Rest (ca. 1,5kW) eingespeist. Spätestens hier hätte ich mit allem Überschuss den Akku laden müssen.

Auffällig ist, das immer als Battery_ChargeUnrestricted_01 == 0 war (nicht grau schraffiert), war die Battery_ChargeOptTargetPower_01 deutlich höher. Das macht doch mit deiner Erklärung erst recht keinen Sinn, sollten diese unabhängig voneinander sein.
Das dritte Bild zeigt das nochmal im Detail



Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Moin,

Zugegeben war der Verbrauch Nachmittags ungewöhnlich hoch.

Das Risko besteht und auch dass Prognosen (PV oder Verbrauch) nicht so eintreffen wie vorhergesagt.

Ein genereller Aspekt ist, dass die Empfehlung in Battery_ChargeOptTargetPower_XX prognosebasiert ist. Wobei hier der Fokus auf minimaler Ladungsenergie liegt, wie es die ursprüngliche Anforderung von Parallix für diese Implementierung war. Möglicherweise gelingt es mir noch einen Bezug zu der real existierenden Situation mit einfließen zu lassen.

Die Bilder sind ja ganz nett, nützen aber nichts. Um wirklich Zusammenhänge zu erkennen braucht man einen Logauszug mit ctrlDebug=batteryManagement, am Besten gleich mit der V 1.58.2 aus dem contrib.

Vielleicht ist aber diese Art der Steuerung für dich bzw. deine Anlage auch nicht der richtige Weg und du wärst besser beraten, nur über die Battery_ChargeUnrestricted_XX in Verbindung mit plantControl->feedinPowerLimit (welches auf jeden Fall gesetzt sein sollte für alle Steuerungsvarianten) zu steuern. Ist plantControl->feedinPowerLimit bei dir gesetzt?

[Gisbert]

Hallo Heiko,

ich hätte eine kleine Bitte bei der Darstellung des Energy flow graphs im Attribut:

Code Auswählen Erweitern

shiftx    Horizontal shift of the energy flow graph.
Value: -80 ... 80, default: 0Da ich Fhem überwiegend auf dem Handy mit dem flex Style nutze, reichen diese Werte oft nicht aus, um ein schönes Ergebnis hinzubekommen. Mein Vorschlag wäre mindestens -100 ... 100 vorzugeben - oder ganz darauf zu verzichten, wie bei shifty.

Viele Grüße Gisbert