76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 28 September 2025, 10:09:43

Das Wetter ist heute nicht so gut weswegen der Tag mit einer Tasse Kaffee und Forum lesen startet.

@Parallix,

ZitatU.a. vor dem o.g. Hintergrund schlage ich vor, in SF ein Attribut zu definieren, mit denen angegeben werden kann zu welchem prozentualen Anteil SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" berücksichtigen sollen.
....

Meines Erachtens ist es ungünstig, dass SF für den Fall, dass nicht genügend "Überschuss" vorhanden ist, Battery_ChargeOptTargetPower_XX auf pinreduced setzt, insb. dann, wenn Battery_ChargeOptTargetPower_XX dem WR als maximale Leistung genannt wird, mit dem er einen Speicher laden soll.
.... schlage ich vor, Battery_ChargeOptTargetPower_XX auf pinreduced nur für denn Fall, dass eine Speicher unter lowSoc fällt, zu setzen (also wenn Battery_ChargeRequest_XX == 1).

Kann ich machen, gebe aber zu bedenken, dass OTP dann auf pinmax bzw. 'unendlich' zurück fällt.
Würde ich einen Schlüssel für den prozentualen Anteil der SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" einbauen, würde auch dies Auswirkung auf den prognostizierten PV-Überschuß und somit den Rückfall haben. So würde z.B. bei 0% Anteil Verbrauch immer ein PV-Überschuß prognostiziert sofern überhaupt PV-Leistung erwartet wird.

Andererseits wird pinreduced auch dann (erhöhend) genutzt wenn die berechnete Ladeleistung auf Grundlage der Prognose unterhalb dieses Wertes ist. Wenn ich also pinreduced durch pinmax ersetze, fehlt dieser Vergleichswert bei der Bestimmung der Ladeleistung (ich kann nicht sinnvoll gegen pinmax vergleichen) und es würden sich u.U. sehr kleine Ladeleistungen ergeben. Nur dann wenn überhaupt kein PV-Überschuß prognostiziert wird, käme pinmax zum Tragen.

Wegen dieser Zusmmenhänge ist die Auswahl einer von den zwei möglichen Stategien zur Bat Ladung m.M. nach von der Jahreszeit abhängig. Im Wiki habe ich dazu meine Haltung geschrieben so wie ich die Auswahl der Strategie vornehmen würde.

LG und einen schönen Sonntag ...

Parallix · 28 September 2025, 13:24:44

Zitat von: DS_Starter am 28 September 2025, 10:09:43Das Wetter ist heute nicht so gut weswegen der Tag mit einer Tasse Kaffee und Forum lesen startet.
...

Schade, dass Du im Urlaub derzeit schlechtes Wetter hast! Da wird es Dich auch nicht trösten, wenn wir hier bei uns ist derzeit bestes solares Wetter haben.

Was den Rückfallwert angeht, so wäre es wahrscheinlich sinnvoll, einen weiteren zu haben, der aber nur dann angenommen wird, wenn der SOC so niedrig ist, dass bald eine Zwangsladung aus dem Netz droht.

Was Du da hinsichtlich der gegenseitigen Abhängigkeiten geschrieben hast, das muss ich mir erst mal in Ruhe ansehen.

DS_Starter · 01 Oktober 2025, 23:00:37

Hallo @all,

während meines Urlaubs (es gab immer mal wieder etwas Zeit

) habe ich die Funktion zur optimalen Ladeleistung komplett überarbeitet.
Die Leistungen werden nun über eine binäre Iteration bis zur Zielgenauigkeit von 1 Watt ermittelt und mit dem gewählten safety-Prozent aufgewertet. Der Rückfallwert ist bei fehlendem Surplus auf pinmax (oder undendlich) realisiert was ein Laden der Batterie ermöglicht falls doch unerwartet Surplus entsteht. Es wird mindestens mit pinreduced geladen. Wird <=lowSoC erkannt, wird pinreduced im Reading Battery_ChargeOptTargetPower_XX eingetragen. Damit wird die Bat schonend aus den Grid geladen falls nötig.

Weiterhin gibt es einen neuen Key ctrlBatSocManagementXX->loadStrategy um die Auswirkungen der gewählten Strategie in der Batterie Balkengrafik zu sehen:

loadStrategy Bei der Anzeige der Batterie in der Balkengrafik wird die gewählte Ladestrategie berücksichtigt.
Die Generierung der Steuerreadings wird nicht beeinflusst. Die Angabe ist optional.
Weitere Informationen siehe Wiki.
Wert: loadRelease oder optPower, default: loadRelease

Ein Link zum Wikibeitrag für weitere Erläuterungen ist eingefügt.

Der Debuglog sieht auch ganz anders aus:

Code Auswählen

2025.10.01 13:28:42.484 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.01 13:28:42.484 1: SolCast DEBUG> Bat 01 ChargeOTP - used safety margin: 20 %
2025.10.01 13:28:42.484 1: SolCast DEBUG> Bat 01 ChargeOTP - is the charging goal likely to be achieved? - goal: 5967 Wh -> no
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/13 - hod: 14 / 00, lc: 1, SoC S/E: 22449 / 23423 Wh, Surplus: 677 Wh, OTP: 974 W
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/14 - hod: 15 / 01, lc: 1, SoC S/E: 23423 / 24199 Wh, Surplus: 647 Wh, OTP: 776 W
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/15 - hod: 16 / 02, lc: 1, SoC S/E: 24199 / 24799 Wh, Surplus: 371 Wh, OTP: 600 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/16 - hod: 17 / 03, lc: 1, SoC S/E: 24799 / 26245 Wh, Surplus: 1205 Wh, OTP: 1446 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/17 - hod: 18 / 04, lc: 1, SoC S/E: 26245 / 26845 Wh, Surplus: 368 Wh, OTP: 600 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/18 - hod: 19 / 05, lc: 1, SoC S/E: 26845 / 26845 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/19 - hod: 20 / 06, lc: 1, SoC S/E: 24801 / 24801 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/20 - hod: 21 / 07, lc: 1, SoC S/E: 24114 / 24114 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/21 - hod: 22 / 08, lc: 1, SoC S/E: 23376 / 23376 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.488 1: SolCast DEBUG> Bat 01 ChargeOTP 01/22 - hod: 23 / 09, lc: 1, SoC S/E: 22613 / 22613 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.488 1: SolCast DEBUG> Bat 01 ChargeOTP 01/23 - hod: 24 / 10, lc: 1, SoC S/E: 21844 / 21844 Wh, Surplus: 0 Wh, OTP: 5040 W

Man sieht auch ob das Ladeziel, die benötigte Ladeenergie, (is the charging goal likely to be achieved?) am laufenden Tag überhaupt erreicht werden kann.
Jetzt ist die Lösung auch so flexibel, dass ich auf individuelle Ladeziele bzw. Ziel-SoCs erweitern kann. Oder auch die prozentuale Berücksichtigung des Verbrauchs was noch zu machen ist.

Das update liegt im contrib.

LG,
Heiko

DS_Starter · 03 Oktober 2025, 11:21:32

Hallo zusammen,

für die OTP-Steuerung habe ich noch ein gewünschtes Puzzleteil ctrlBatSocManagementXX->weightOwnUse hinzugefügt.
Die V 1.58.6 im contrib ist upgedated und enthält nun folgenden Arbeitstand:

- das Reading Battery_ChargeRecommended_XX ist entfernt
- Bugfix ctrlNextDayForecastReadings zur Anzeige der Werte des morgigen Tages anstatt von Übermorgen
- ein komplettes Rework der Batterie OTP-Steuerung

- den Schlüssel ctrlBatSocManagementXX->loadStrategy:
loadStrategy
Bei der Anzeige der Batterie in der Balkengrafik wird die gewählte Ladestrategie berücksichtigt.
Die Generierung der Steuerreadings wird nicht beeinflusst. Die Angabe ist optional.
Weitere Informationen siehe Wiki.
Wert: loadRelease oder optPower, default: loadRelease

- den Schlüssel ctrlBatSocManagementXX->weightOwnUse:
weightOwnUse
Optionale Gewichtung der stündlichen Verbrauchsprognose als zusätzlich verwendbaren Anteil zur
Batterieladung in %. Technisch wird der verfügbare PV-Überschuß zur Berechnung der optimierten
Ladeleistung erhöht indem der kalkulierte Verbrauch um den angegebenen Prozentsatz gesenkt wird.
Wert: 0..100 default: 0

- Einstellung des Batteriewirkungsgrades in setupBatteryDevXX:
efficiency
Optionale Angabe des Wirkungsgrades der Energiespeicherung in %. Dieser Wirkungsgrad beschreibt nicht
nur die Batterie selbst, sondern die Wirkkette inkl. der betroffenen Wechselrichter.
Je nach Koppelart und anderen Faktoren liegt der typische Wirkungsgrad zwischen 75 - 90 %.
Wert: 0..100 default: 87

@Parallix, könntest du mir evtl. einen Textbaustein zur Erläuterung des Modus "Eigennutzung" bei Hybrid-Wechselrichtern zuarbeiten?
Zur Unterstützung dieses Modus gibt es im Modul nun ctrlBatSocManagementXX->weightOwnUse. Diese Beziehung würde ich gern im Wiki in einem erläuternden Absatz beschreiben.

Einen schönen und sonnigen Feiertag!

LG,
Heiko

DS_Starter · 03 Oktober 2025, 22:17:59

In setupBatteryDevXX kann man nun auch den individuellen Batterie Wirkungsgrad angeben. Siehe vorigen Beitrag.

Nach den ganzen Überarbeitungen ist nun der Moment gekommen die Version einzuchecken. Sie wird morgen früh im Update enthalten sein. Denkt an das Reading Battery_ChargeRecommended_XX.

LG,
Heiko

Parallix · 04 Oktober 2025, 07:58:57

Zitat von: DS_Starter am 03 Oktober 2025, 11:21:32...
@Parallix, könntest du mir evtl. einen Textbaustein zur Erläuterung des Modus "Eigennutzung" bei Hybrid-Wechselrichtern zuarbeiten?
Zur Unterstützung dieses Modus gibt es im Modul nun ctrlBatSocManagementXX->weightOwnUse. Diese Beziehung würde ich gern im Wiki in einem erläuternden Absatz beschreiben.
...

Mache ich gerne. Werde heute erst einmal alles neue testen und mich dann direkt an das Schreiben der Passage setzen.

Danke übrigens für die neuen Features.

Edit: Soeben (ca. 8:00 MESZ) stelle ich fest, dass bei mir bei derzeit noch verschwindernder PV-Leistunng Battery_ChargeOptTargetPower_0[12] auf pinmax gesetzt ist. Auch im Wiki finde ich jetzt (oder war das immer schon so ?) den Hinweise, dass bei zu geringem Überschuss auf pinmax zurückgefallen wird. In der direkt darunter stehenden Textpassage wir die Sinnhaftigkeit des Setztens von pinreduced erläutert. Aber nach meiner o.g. Beobachtung hat pinreduced scheinbar keine Bedeutung mehr im Fall einer aktuell zu geringen PV-Leistung.

DS_Starter · 04 Oktober 2025, 08:42:06

Moin,

ZitatEdit: Soeben (ca. 8:00 MESZ) stelle ich fest, dass bei mir bei derzeit noch verschwindernder PV-Leistunng Battery_ChargeOptTargetPower_0[12] auf pinmax gesetzt ist. Auch im Wiki finde ich jetzt (oder war das immer schon so ?) den Hinweise, dass bei zu geringem Überschuss auf pinmax zurückgefallen wird. In der direkt darunter stehenden Textpassage wir die Sinnhaftigkeit des Setztens von pinreduced erläutert. Aber nach meiner o.g. Beobachtung hat pinreduced scheinbar keine Bedeutung mehr im Fall einer aktuell zu geringen PV-Leistung.

pinmax bei kein PV-Überschuß bzw. Ziel erreicht ist richtig. pinreduced kommt nur noch bei SoC <= lowSoC bzw. wenn berechnete Ladeleistung < pinreduced (Einhaltung einer Mindestladeleistung) zum Einsatz.
Wiki gehe ich gleich nochmal durch und passe den Text an die aktuelle Version an.

Parallix · 04 Oktober 2025, 09:27:16

Zitat von: DS_Starter am 04 Oktober 2025, 08:42:06...
pinmax bei kein PV-Überschuß bzw. Ziel erreicht ist richtig. pinreduced kommt nur noch bei SoC <= lowSoC bzw. wenn berechnete Ladeleistung < pinreduced (Einhaltung einer Mindestladeleistung) zum Einsatz.

Dann ist ja alles so, wie es sein soll(te)! Danke für die schnelle Aufklärung!

DS_Starter · 04 Oktober 2025, 09:36:53

Hier nochmal ein Beispiel wie der aktuelle DebugLog bei gesetztem Parameter loadStrategy=optPower aussieht:

Code Auswählen

2025.10.04 09:27:47.255 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.04 09:27:47.255 1: SolCast DEBUG> Bat 01 ChargeOTP - used safety margin: 20 %
2025.10.04 09:27:47.255 1: SolCast DEBUG> Bat 01 ChargeOTP - weighted self-consumption: 0 %
2025.10.04 09:27:47.256 1: SolCast DEBUG> Bat 01 ChargeOTP - is the charging goal likely to be achieved? - undetermined, calculation is starting with next hour with surplus
2025.10.04 09:27:47.256 1: SolCast DEBUG> Bat 01 ChargeOTP 04/09 - hod: 10 / 00, lc: 1, SoC S/E: 19607 / 19153 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.256 1: SolCast DEBUG> Bat 01 ChargeOTP 04/10 - hod: 11 / 01, lc: 1, SoC S/E: 19153 / 18822 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/11 - hod: 12 / 02, lc: 1, SoC S/E: 18822 / 18141 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/12 - hod: 13 / 03, lc: 1, SoC S/E: 18141 / 18711 Wh, Surplus: 190 Wh, OTP: 600 W
2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/13 - hod: 14 / 04, lc: 1, SoC S/E: 18711 / 19281 Wh, Surplus: 481 Wh, OTP: 600 W
2025.10.04 09:27:47.258 1: SolCast DEBUG> Bat 01 ChargeOTP 04/14 - hod: 15 / 05, lc: 1, SoC S/E: 19281 / 18983 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.258 1: SolCast DEBUG> Bat 01 ChargeOTP 04/15 - hod: 16 / 06, lc: 1, SoC S/E: 18481 / 17985 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.258 1: SolCast DEBUG> Bat 01 ChargeOTP 04/16 - hod: 17 / 07, lc: 1, SoC S/E: 17985 / 17613 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.259 1: SolCast DEBUG> Bat 01 ChargeOTP 04/17 - hod: 18 / 08, lc: 1, SoC S/E: 17613 / 17150 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.259 1: SolCast DEBUG> Bat 01 ChargeOTP 04/18 - hod: 19 / 09, lc: 1, SoC S/E: 17150 / 16558 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.259 1: SolCast DEBUG> Bat 01 ChargeOTP 04/19 - hod: 20 / 10, lc: 1, SoC S/E: 16558 / 15864 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.260 1: SolCast DEBUG> Bat 01 ChargeOTP 04/20 - hod: 21 / 11, lc: 1, SoC S/E: 15864 / 15172 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.260 1: SolCast DEBUG> Bat 01 ChargeOTP 04/21 - hod: 22 / 12, lc: 1, SoC S/E: 15172 / 14505 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.260 1: SolCast DEBUG> Bat 01 ChargeOTP 04/22 - hod: 23 / 13, lc: 1, SoC S/E: 14505 / 13825 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.261 1: SolCast DEBUG> Bat 01 ChargeOTP 04/23 - hod: 24 / 14, lc: 1, SoC S/E: 13825 / 13137 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.261 1: SolCast DEBUG> Bat 01 ChargeOTP 05/00 - hod: 01 / 15, lc: 1, SoC S/E: 13137 / 12483 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.262 1: SolCast DEBUG> Bat 01 ChargeOTP 05/01 - hod: 02 / 16, lc: 1, SoC S/E: 12483 / 11927 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.262 1: SolCast DEBUG> Bat 01 ChargeOTP 05/02 - hod: 03 / 17, lc: 1, SoC S/E: 11927 / 11433 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.262 1: SolCast DEBUG> Bat 01 ChargeOTP 05/03 - hod: 04 / 18, lc: 1, SoC S/E: 11433 / 10921 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.263 1: SolCast DEBUG> Bat 01 ChargeOTP 05/04 - hod: 05 / 19, lc: 1, SoC S/E: 10921 / 10385 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.263 1: SolCast DEBUG> Bat 01 ChargeOTP 05/05 - hod: 06 / 20, lc: 1, SoC S/E: 10385 / 9874 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.263 1: SolCast DEBUG> Bat 01 ChargeOTP 05/06 - hod: 07 / 21, lc: 1, SoC S/E: 9874 / 9297 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.264 1: SolCast DEBUG> Bat 01 ChargeOTP 05/07 - hod: 08 / 22, lc: 1, SoC S/E: 9297 / 8718 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.264 1: SolCast DEBUG> Bat 01 ChargeOTP 05/08 - hod: 09 / 23, lc: 1, SoC S/E: 8718 / 8344 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.264 1: SolCast DEBUG> Bat 01 ChargeOTP 05/09 - hod: 10 / 24, lc: 1, SoC S/E: 8344 / 10333 Wh, Surplus: 1745 Wh, OTP: 2094 W
2025.10.04 09:27:47.265 1: SolCast DEBUG> Bat 01 ChargeOTP 05/10 - hod: 11 / 25, lc: 1, SoC S/E: 10333 / 11376 Wh, Surplus: 915 Wh, OTP: 1098 W
2025.10.04 09:27:47.265 1: SolCast DEBUG> Bat 01 ChargeOTP 05/11 - hod: 12 / 26, lc: 1, SoC S/E: 11376 / 13047 Wh, Surplus: 1466 Wh, OTP: 1759 W
2025.10.04 09:27:47.265 1: SolCast DEBUG> Bat 01 ChargeOTP 05/12 - hod: 13 / 27, lc: 1, SoC S/E: 13047 / 16472 Wh, Surplus: 3004 Wh, OTP: 3605 W
2025.10.04 09:27:47.266 1: SolCast DEBUG> Bat 01 ChargeOTP 05/13 - hod: 14 / 28, lc: 1, SoC S/E: 16472 / 20145 Wh, Surplus: 3222 Wh, OTP: 3866 W
2025.10.04 09:27:47.266 1: SolCast DEBUG> Bat 01 ChargeOTP 05/14 - hod: 15 / 29, lc: 1, SoC S/E: 20145 / 22255 Wh, Surplus: 1851 Wh, OTP: 2221 W
2025.10.04 09:27:47.266 1: SolCast DEBUG> Bat 01 ChargeOTP 05/15 - hod: 16 / 30, lc: 1, SoC S/E: 22255 / 23199 Wh, Surplus: 828 Wh, OTP: 994 W
2025.10.04 09:27:47.266 1: SolCast DEBUG> Bat 01 ChargeOTP 05/16 - hod: 17 / 31, lc: 1, SoC S/E: 23199 / 24013 Wh, Surplus: 714 Wh, OTP: 857 W
2025.10.04 09:27:47.267 1: SolCast DEBUG> Bat 01 ChargeOTP 05/17 - hod: 18 / 32, lc: 1, SoC S/E: 24013 / 23795 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.267 1: SolCast DEBUG> Bat 01 ChargeOTP 05/18 - hod: 19 / 33, lc: 1, SoC S/E: 21184 / 20628 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.267 1: SolCast DEBUG> Bat 01 ChargeOTP 05/19 - hod: 20 / 34, lc: 1, SoC S/E: 20628 / 19934 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.268 1: SolCast DEBUG> Bat 01 ChargeOTP 05/20 - hod: 21 / 35, lc: 1, SoC S/E: 19934 / 19242 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.268 1: SolCast DEBUG> Bat 01 ChargeOTP 05/21 - hod: 22 / 36, lc: 1, SoC S/E: 19242 / 18575 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.268 1: SolCast DEBUG> Bat 01 ChargeOTP 05/22 - hod: 23 / 37, lc: 1, SoC S/E: 18575 / 17895 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.269 1: SolCast DEBUG> Bat 01 ChargeOTP 05/23 - hod: 24 / 38, lc: 1, SoC S/E: 17895 / 17207 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.269 1: SolCast DEBUG> Bat 01 ChargeOTP 06/00 - hod: 01 / 39, lc: 1, SoC S/E: 17207 / 16553 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.270 1: SolCast DEBUG> Bat 01 ChargeOTP 06/01 - hod: 02 / 40, lc: 1, SoC S/E: 16553 / 15997 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.270 1: SolCast DEBUG> Bat 01 ChargeOTP 06/02 - hod: 03 / 41, lc: 1, SoC S/E: 15997 / 15503 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.270 1: SolCast DEBUG> Bat 01 ChargeOTP 06/03 - hod: 04 / 42, lc: 1, SoC S/E: 15503 / 14991 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.271 1: SolCast DEBUG> Bat 01 ChargeOTP 06/04 - hod: 05 / 43, lc: 1, SoC S/E: 14991 / 14455 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.271 1: SolCast DEBUG> Bat 01 ChargeOTP 06/05 - hod: 06 / 44, lc: 1, SoC S/E: 14455 / 13944 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.271 1: SolCast DEBUG> Bat 01 ChargeOTP 06/06 - hod: 07 / 45, lc: 1, SoC S/E: 13944 / 13367 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.272 1: SolCast DEBUG> Bat 01 ChargeOTP 06/07 - hod: 08 / 46, lc: 1, SoC S/E: 13367 / 12773 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.272 1: SolCast DEBUG> Bat 01 ChargeOTP 06/08 - hod: 09 / 47, lc: 1, SoC S/E: 12773 / 12365 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.272 1: SolCast DEBUG> Bat 01 ChargeOTP 06/09 - hod: 10 / 48, lc: 1, SoC S/E: 12365 / 12986 Wh, Surplus: 545 Wh, OTP: 654 W
2025.10.04 09:27:47.273 1: SolCast DEBUG> Bat 01 ChargeOTP 06/10 - hod: 11 / 49, lc: 1, SoC S/E: 12986 / 13728 Wh, Surplus: 651 Wh, OTP: 781 W
2025.10.04 09:27:47.273 1: SolCast DEBUG> Bat 01 ChargeOTP 06/11 - hod: 12 / 50, lc: 1, SoC S/E: 13728 / 14760 Wh, Surplus: 905 Wh, OTP: 1086 W
2025.10.04 09:27:47.273 1: SolCast DEBUG> Bat 01 ChargeOTP 06/12 - hod: 13 / 51, lc: 1, SoC S/E: 14760 / 17079 Wh, Surplus: 2034 Wh, OTP: 2441 W
2025.10.04 09:27:47.274 1: SolCast DEBUG> Bat 01 ChargeOTP 06/13 - hod: 14 / 52, lc: 1, SoC S/E: 17079 / 18475 Wh, Surplus: 1224 Wh, OTP: 1469 W
2025.10.04 09:27:47.274 1: SolCast DEBUG> Bat 01 ChargeOTP 06/14 - hod: 15 / 53, lc: 1, SoC S/E: 18475 / 19066 Wh, Surplus: 518 Wh, OTP: 622 W
2025.10.04 09:27:47.274 1: SolCast DEBUG> Bat 01 ChargeOTP 06/15 - hod: 16 / 54, lc: 1, SoC S/E: 19066 / 19636 Wh, Surplus: 93 Wh, OTP: 600 W
2025.10.04 09:27:47.275 1: SolCast DEBUG> Bat 01 ChargeOTP 06/16 - hod: 17 / 55, lc: 1, SoC S/E: 19636 / 19580 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.275 1: SolCast DEBUG> Bat 01 ChargeOTP 06/17 - hod: 18 / 56, lc: 1, SoC S/E: 17980 / 17481 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.275 1: SolCast DEBUG> Bat 01 ChargeOTP 06/18 - hod: 19 / 57, lc: 1, SoC S/E: 17481 / 16882 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.276 1: SolCast DEBUG> Bat 01 ChargeOTP 06/19 - hod: 20 / 58, lc: 1, SoC S/E: 16882 / 16188 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.276 1: SolCast DEBUG> Bat 01 ChargeOTP 06/20 - hod: 21 / 59, lc: 1, SoC S/E: 16188 / 15496 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.276 1: SolCast DEBUG> Bat 01 ChargeOTP 06/21 - hod: 22 / 60, lc: 1, SoC S/E: 15496 / 14829 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.277 1: SolCast DEBUG> Bat 01 ChargeOTP 06/22 - hod: 23 / 61, lc: 1, SoC S/E: 14829 / 14149 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.277 1: SolCast DEBUG> Bat 01 ChargeOTP 06/23 - hod: 24 / 62, lc: 1, SoC S/E: 14149 / 13461 Wh, Surplus: 0 Wh, OTP: 5040 W

Hier sieht man sehr gut wie beim Wechsel von kein PV Überschuß nach wenig PV-Überschuß mit zu geringer Ladeleistung der Wechsel von pinmax (5040 W) zu pinreduced (600 W) und vice versa erfolgt:

Code Auswählen

2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/11 - hod: 12 / 02, lc: 1, SoC S/E: 18822 / 18141 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/12 - hod: 13 / 03, lc: 1, SoC S/E: 18141 / 18711 Wh, Surplus: 190 Wh, OTP: 600 W
2025.10.04 09:27:47.257 1: SolCast DEBUG> Bat 01 ChargeOTP 04/13 - hod: 14 / 04, lc: 1, SoC S/E: 18711 / 19281 Wh, Surplus: 481 Wh, OTP: 600 W
2025.10.04 09:27:47.258 1: SolCast DEBUG> Bat 01 ChargeOTP 04/14 - hod: 15 / 05, lc: 1, SoC S/E: 19281 / 18983 Wh, Surplus: 0 Wh, OTP: 5040 W

Schlechtes Wetter die nächsten Tage.

Parallix · 04 Oktober 2025, 09:53:38

Zitat von: DS_Starter am 04 Oktober 2025, 09:36:53Hier nochmal ein Beispiel wie der aktuelle DebugLog bei gesetztem Parameter loadStrategy=optPower aussieht:
...
Hier sieht man sehr gut wie beim Wechsel von kein PV Überschuß nach wenig PV-Überschuß mit zu geringer Ladeleistung der Wechsel von pinmax (5040 W) zu pinreduced (600 W) und vice versa erfolgt:

Nun frage ich mich, ob dieses Pendeln sinnvoll ist, da so ja zum einen unnötige Events erzeugt werden und zum anderen statt pinmax ja auch die erforderliche Leistung gesetzt werden könnte, mit denen der/die Speicher bis zum Tagesende - gleichmäßige Ladung angenommen - auf einem Ziel-SOC (derzeit in SF noch fest auf 100% eingestellt) gebracht werden könnte/n.

PS: Es ist doch richtig, dass das weightOwnUse == 100 dazu führt, dass Battery_ChargeOptTargetPower_XX ohne Berücksichtigung prognostizierter Verbräuche bestimmt wird, oder?

DS_Starter · 04 Oktober 2025, 10:12:49

ZitatNun frage ich mich, ob dieses Pendeln sinnvoll ist, da so ja zum einen unnötige Events erzeugt werden

Werden nicht. Das Log ist ja nur ein Blick in die Zukunft wie sich die Dinge wahrscheinlich entwickeln. Events werden nur für die aktuelle Stunde erzeugt.

Zitatund zum anderen statt pinmax ja auch die erforderliche Leistung gesetzt werden könnte, mit denen der/die Speicher bis zum Tagesende - gleichmäßige Ladung angenommen - auf einem Ziel-SOC (derzeit in SF noch fest auf 100% eingestellt) gebracht werden könnte/n.

Um Rechenleistung zu sparen, werden die aufwendigen Iterationen nur bei Vorliegen eines PV-Überschusses durchgezogen und ansonsten der Rückfall vorgenommen.
Ein anderes Verfahren kann man machen, würde dann aber mehr Events erzeugen und Rechenleistung binden.

DS_Starter · 04 Oktober 2025, 10:22:31

ZitatPS: Es ist doch richtig, dass das weightOwnUse == 100 dazu führt, dass Battery_ChargeOptTargetPower_XX ohne Berücksichtigung prognostizierter Verbräuche bestimmt wird, oder?

Ja, das ist richtig. D.h. der vom Modul prognostizierte Verbrauch wird bei der prognostizierten PV-Erzeugung nicht angerechnet. Was auch bedeutet, dass die Power-Routinen mit der vollen PV Prognose rechnen. In allem steckt natürlich die Unsicherhheit der Prognose(n).

Parallix · 04 Oktober 2025, 10:30:05

Zitat von: DS_Starter am 04 Oktober 2025, 10:12:49...
Zitatund zum anderen statt pinmax ja auch die erforderliche Leistung gesetzt werden könnte, mit denen der/die Speicher bis zum Tagesende - gleichmäßige Ladung angenommen - auf einem Ziel-SOC (derzeit in SF noch fest auf 100% eingestellt) gebracht werden könnte/n.
Um Rechenleistung zu sparen, werden die aufwendigen Iterationen nur bei Vorliegen eines PV-Überschusses durchgezogen und ansonsten der Rückfall vorgenommen.
Ein anderes Verfahren kann man machen, würde dann aber mehr Events erzeugen und Rechenleistung binden.

Wenn in der Zeit, in dem solare Leistung (nicht unbedingt Überschuss) erzielt wird, in jede Stunde oder halte Stunde einmal gerechnet würde, dann wäre das völlig ausreichend. Sinnvoller wäre es natürlich, wenn die Rechnung immer dann angeworfen wird, wenn sich der SOC seit der letzten Rechnung um mehr als DeltaSOC4Recalc verändert hat oder DeltaTime4Recalc verstrichen ist.

DS_Starter · 04 Oktober 2025, 10:41:34

ZitatWenn in der Zeit, in dem solare Leistung (nicht unbedingt Überschuss) erzielt wird, in jede Stunde oder halte Stunde einmal gerechnet würde, dann wäre das völlig ausreichend. Sinnvoller wäre es natürlich, wenn die Rechnung immer dann angeworfen wird, wenn sich der SOC seit der letzten Rechnung um mehr als DeltaSOC4Recalc verändert hat oder DeltaTime4Recalc verstrichen ist.

Das Modul arbeitet in Zyklen bzw. wenn bestimmte Devices asynchron eingestellt sind sodass auf deren Events reagiert wird. Außerdem verhalten sich alle Input-Parameter sehr dynamisch und führen zu ständigen Änderungen und Anpassungen der Prognose bzw. der davon abgeleiteten (Steuerungs)Parameter.
Die Einführung weiterer Regel-Bedingungen würde ich nur vornehmen wenn eine unbedingte Erforderniss dazu besteht die ich nicht sehe.

Anders gefragt ... was spricht denn dagegen in Zeiten in denen voraussichtlich ohnehin kein Überschuß besteht auf pinmax zurückzufallen, sodass die Bat dennoch geladen wird wenn unerwartet PV Überschuß vorliegt?

Parallix · 04 Oktober 2025, 10:47:10

Zitat von: DS_Starter am 04 Oktober 2025, 10:41:34...
Das Modul arbeitet in Zyklen bzw. wenn bestimmte Devices asynchron eingestellt sind sodass auf deren Events reagiert wird. Außerdem verhalten sich alle Input-Parameter sehr dynamisch und führen zu ständigen Änderungen und Anpassungen der Prognose bzw. der davon abgeleiteten (Steuerungs)Parameter.

Gehe ich denn Recht in der Annahme, dass wenigstens 1 SF-Lauf / h erfolgt?

Zu Deinem Edit:

Auf Basis von SF erfolgt zwar konzeptionell keine Regelung, sondern eine Steuerung. Da Battery_ChargeOptTargetPower_XX durch ein Feedback bestimmt wird, kommt SF zumindest in die Nähe einer Regelung, ist hierfür aufgrund seiner Komplexität aber praktisch zu träge.

Bei loadStrategy == optPower wird das Ziel verfolgt, einen Speicher schonend zu laden. Wenn nun aber bei unzureichendem PV-Überschuss mit pinmax die maximale Leistung als optimale Ladeleistung empfohlen wird und eine Bewölkung vorliegt, bei der es abwechselnd zu a) keinem und b) hohem ggf. auch sehr hohem Überschuss kommt kommt, wird - aufgrund der Trägheit von SF - das Ziel der schonenden Ladung konterkariert. Daher sollte der Rückfallwert stets einer Leistung entsprechen, die im Sinne des Ladestrategie ist. Ideal wäre hier die Leistung, mit denen der Speicher - gleichmäßige Ladung angenommen - bis zum Tagesende auf den (irgendwann mal anzugebenden) Ziel-SOC gebracht werden kann.