76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

In allen meinen heutigen Postings rede ich  nicht über die Ladesteuerung im allgemeinen, sondern nur über den (Sonder-)Fall, wenn Battery_ChargeOptTargetPower_XX auf eine Konstante gesetzt wird!

Schon klar, aber dieser Sonderfall wird genau unterschiedlich in optPower und smartPower behandelt.
Wer in diesem Sonderfall die Sicherheit der maximalen Energieausbeute für die Batterie haben will benutzt smartPower. Wem die Anwendung eines entsprechend angepassten Sicherheitaufschlages und gemässigten Leistungsvorschlag unter der Prämisse auch eine eventuelle Einspeisung hinzunehmen für die unbedingte Einhaltung der geringeren Ladeleistung, nimmt optPower. 
Wie ich schon geschrieben habe, führt jedenfalls "max( pinmax, (100 - SOC)*capacity/timeTillSunset)" in der Realität immer zu pinmax.

[Parallix]

In allen meinen heutigen Postings rede ich  nicht über die Ladesteuerung im allgemeinen, sondern nur über den (Sonder-)Fall, wenn Battery_ChargeOptTargetPower_XX auf eine Konstante gesetzt wird!

Schon klar, aber dieser Sonderfall wird genau unterschiedlich in optPower und smartPower behandelt.
Wer in diesem Sonderfall die Sicherheit der maximalen Energieausbeute für die Batterie haben will benutzt smartPower. Wem die Anwendung eines entsprechend angepassten Sicherheitaufschlages und gemässigten Leistungsvorschlag unter der Prämisse auch eine eventuelle Einspeisung hinzunehmen für die unbedingte Einhaltung der geringeren Ladeleistung, nimmt optPower. 
Wie ich schon geschrieben habe, führt jedenfalls "max( pinmax, (100 - SOC)*capacity/timeTillSunset)" in der Realität immer zu pinmax.

Entschuldige! Jetzt erst sehe ich meinen Fehler: In meinen vorherigen Beiträgen hätte es immer min(...) statt max(...) und besser auch gleich targetSOC statt 100 heißen sollen.

In diesem Fall sieht die Situation dann nämlich wie von mir beschrieben aus: Es erfolgt gesichert ein schrittweises und damit sanftes Anfahren von pinmax und wäre dann auch ganz im Sinne der Strategie "optPower".

[klaus.schauer]

Die 100% sind dann vermutlich die maximal mögliche Anlagenleistung, oder?

Im allgemeinen wird das so sein. In diesem Fall ist die Leistung von 6150 W der von der Wärmepumpe an den HomeManager 2.0 über die EEBus-Schnittstelle vorgegebene Richtwertwert. Die 40 % PV-Energie davon entsprechen etwa der aufgenommenen Leistung bei 50 % der maximalen Drehzahl des Kompressors und moderater Außentemperatur. Die maximal aufgenommene Leistung des Kompressors kann aber in Grenzbereichen (sehr niedrige Außentemperatur, Maximaldrehzahl) über 6150 W liegen. Der Minimalwert liegt bei ca. 1000 W. Der 40 % Schwellwert hat sich bei mir bewährt, um bei Sonnenschein die Pufferspeicher für Heizung und Warmwasser über den Stadardwert aufzuladen.

[Parallix]

Die 100% sind dann vermutlich die maximal mögliche Anlagenleistung, oder?

Im allgemeinen wird das so sein. In diesem Fall ist die Leistung von 6150 W der von der Wärmepumpe an den HomeManager 2.0 über die EEBus-Schnittstelle vorgegebene Richtwertwert. Die 40 % PV-Energie davon entsprechen etwa der aufgenommenen Leistung bei 50 % der maximalen Drehzahl des Kompressors und moderater Außentemperatur. Die maximal aufgenommene Leistung des Kompressors kann aber in Grenzbereichen (sehr niedrige Außentemperatur, Maximaldrehzahl) über 6150 W liegen. Der Minimalwert liegt bei ca. 1000 W. Der 40 % Schwellwert hat sich bei mir bewährt, um bei Sonnenschein die Pufferspeicher für Heizung und Warmwasser über den Stadardwert aufzuladen.

Wahrscheinlich kann man vieles über einen generischen "dimmbaren Verbraucher" abwickeln, der ggf. auch einige Daten selber liefern kann.

Edit @klaus: Wie hoch sind eigentlich die Diskretisierungsstufen in Prozent und absolut?

[klaus.schauer]

Die 100% sind dann vermutlich die maximal mögliche Anlagenleistung, oder?

Im allgemeinen wird das so sein. In diesem Fall ist die Leistung von 6150 W der von der Wärmepumpe an den HomeManager 2.0 über die EEBus-Schnittstelle vorgegebene Richtwertwert. Die 40 % PV-Energie davon entsprechen etwa der aufgenommenen Leistung bei 50 % der maximalen Drehzahl des Kompressors und moderater Außentemperatur. Die maximal aufgenommene Leistung des Kompressors kann aber in Grenzbereichen (sehr niedrige Außentemperatur, Maximaldrehzahl) über 6150 W liegen. Der Minimalwert liegt bei ca. 1000 W. Der 40 % Schwellwert hat sich bei mir bewährt, um bei Sonnenschein die Pufferspeicher für Heizung und Warmwasser über den Stadardwert aufzuladen.

Wahrscheinlich kann man vieles über einen generischen "dimmbaren Verbraucher" abwickeln, der ggf. auch einige Daten selber liefern kann.

Edit @klaus: Wie hoch sind eigentlich die Diskretisierungsstufen in Prozent und absolut?

Wärmepumpe: 28 % - 100 % Drehzahl, 1er-Schritte (im Normalbetrieb von Wärmepumpe geregelt), die zugehörige aufgenommene Leistung hängt zudem u. a. von Außentemperatur und der Vorlauftemperatur ab
HM 2.0: 100 % Netzbezug - 100 % PV-Erzeugung - 100 % Abgeregelte PV-Energie, 1er-Schritte
Die absoluten Werte sind verbraucherabhängig und für den konkreten Fall oben angegeben.

[Parallix]

... 1er-Schritte ...

Danke! Also keine höhere Auflösung als 1%. Prima!

War mir nicht sicher, ob das EEBUS-Protokoll ggf. auch feinere Abstufungen möglich sind. Aber selbst wenn, so sollten hier für uns 1-er Schritte völlig ausreichen, wenn man nicht gerade eine DC-Charging-Station mit 100 kW oder mehr betreibt.

[DS_Starter]

@Parallix, @all,

ich habe den Ansatz "(ZielSoC - SOC)*capacity/timeTillSunset)" nochmal angeschaut und verändert für optPower eingebaut:

                 (ZielSoC - SOC) / <Stunden bis Sonnenuntergang> * Margin-Factoring

Die Funktionalität kommt zum Tragen im Fall von Strategie=optPower und Battery_TargetAchievable_XX=0.
Weiterhin muß der ZielSoC > SOC sein (kann kleiner sein wenn der ZielSoC geändert wird).

Die Änderung liegt im Contrib.

Morgen wird bei uns schönes Wetter, d.h. das Ladeziel wird erreicht und ich kann diese Funktionalität erst später wirklich testen. Vllt. habt ihr schon eher die Möglichkeit.

Insgesamt hat somit optPower eine gemäßigtere Ladeleistungsanpassung gegenüber der smartPower-Strategie, welche bei bestimmten Rahmenbedingungen aggressiver anpasst. Das kann dazu führen, dass man mit optPower bei volatilen Wetterlagen tendenziell mehr Energie durch Einspeisung "verlieren" kann als mit smartPower, hat aber in diesen Fällen mit optPower in diesen Fällen die sanfteren Ladungen. Das hatte ich schon beschrieben und hat sich jetzt auch nicht geändert, wird nun evtl. noch etwas ausgeprägter verlaufen.

Ich hoffe, dass nun jeder eine passende Strategie für seinen Einsatz finden wird.

LG,
Heiko

[DS_Starter]

In dem Wiki-Abschnitt habe ich die Beschreibung und das Code-Beispiel zur Batteriesteuerung überarbeitet.
 
Über den Code wird nun die Ladestrategie, welche man zur Steurung der Batterie verwendet und die entsprechenden Werte an die Batterie überträgt, ebenfalls in das SF-Device ctrlBatSocManagementXX->loadStrategy gespiegelt.
Dadurch ergibt sich automatisch eine Anpassung der grafischen Batterie Ladeprognose ohne das Attribut ctrlBatSocManagementXX separat nochmal anfassen zu müssen.

[Parallix]

@Parallix, @all,

ich habe den Ansatz "(ZielSoC - SOC)*capacity/timeTillSunset)" nochmal angeschaut und verändert für optPower eingebaut:

                 (ZielSoC - SOC) / <Stunden bis Sonnenuntergang> * Margin-Factoring

Die Funktionalität kommt zum Tragen im Fall von Strategie=optPower und Battery_TargetAchievable_XX=0.
Weiterhin muß der ZielSoC > SOC sein (kann kleiner sein wenn der ZielSoC geändert wird).

Einen ganz lieben Dank für den Einbau der veränderten Sonderbehandlung für den Fall Battery_TargetAchievable_XX == 0.

Bislang wurde bei SOC < lowSOC ja pinreduced gesetzt. Das war gut. Ist das auch so geblieben?

Erfolgt auch weiterhin ein Anheben der Leistung auf Basis des Verlustfaktors?

Ist auch die absolut sinnvolle Begrenzung auf pinmax geblieben?

PS: Ggf. kann es sinnvoll sein, statt timeTillSunset eine etwas früher liegende Zeit anzusetzen, bei der überhaupt noch ein nennenswerter Überschuss gegenüber der Grundlast vorhanden sein kann. Der Einfachheit halber reicht aber sicher auch ein Abzug von 0:30h.

[DS_Starter]

Guten Morgen,

Bislang wurde bei SOC < lowSOC ja pinreduced gesetzt. Das war gut. Ist das auch so geblieben?
Erfolgt auch weiterhin ein Anheben der Leistung auf Basis des Verlustfaktors?
Ist auch die absolut sinnvolle Begrenzung auf pinmax geblieben?

Alles. Ich habe nicht die ganze Logik gepostet, sondern nur den relevanten Teil als Pseudocode.

Ob der Unterschied jetzt zur Vorversion mit optPower so groß sein wird, kann ich noch gar nicht beurteilen, da auch vorher schon bei dieser Strategie und Battery_TargetAchievable_XX == 0 eine schrittweise Anhebung + Margin vollzogen wurde im Gegensatz zu smartPower mit pinmax in diesem Fall.
Aber wir werden sehen.

Die Zeit bis zum Sonnenuntergang habe ich rechnerisch um eine Stunde verkürzt. Dadurch verkleinert sich der Divisor und die Ladeleistung wird jeweils etwas höher.
Update liegt im Contrib.

[Parallix]

...

Super!

Nun werden bei mir wohl auch die morgendlichen 3500 W (=pinmax), die ich teilweise auch bei Battery_TargetAchievable_XX == 1 bekomme, hoffentlich nicht mehr erscheinen.

[Hadl]

Hallo zusammen,
heute war mal wieder ein interessanter Tag für die smartPower Strategie
Target achievable ist heute ein paarmal weg gewesen, und am Ende wurde der Akku gerade so voll. Ich hab die default safety margin eingestellt.

Interessant finde ich das er am Ende der Stunde immer noch die Kapazität der aktuellen Stunde einrechnet

2025.10.22 16:58:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? yes
2025.10.22 16:58:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7243 Wh, Surplus: 2673 Wh, OTP: 906 W

2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? yes
2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7204 Wh, Surplus: 2673 Wh, OTP: 2000 W
2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 1/1, SoC S/E: 7204 / 7232 Wh, Surplus: 32 Wh, OTP: 1764 W

kurz danach ist er dann nichtmehr achievable, weil die Stunde 16 rum ist:

2025.10.22 17:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? no
2025.10.22 17:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7193 Wh, Surplus: 32 Wh, OTP: 2000 W

Hier sieht man auch schön den Sägezahn Form wieder. Und obwohl ich ab 16:15 die empfohlene Ladeleistung nichtmehr erfüllen kann, sinkt die empfohlene Leistung trotzdem. Bis er sie dann um 17:00 achievable=0 hat.
Um 14:00 und 15:00 war achievable auch kurz weg. Könnte man nicht hier die aktuelle Stunde nur mit dem Anteil der verbleibenden Zeit bis Stundenende mit einrechnen? Dann hätte man nicht diesen "Stunden-Sägezahn"

Insbesondere wäre es sinnvoller gewesen nachdem er um 15:00 schon nichtmehr "achievable" prognostiziert hatte, die hohe Leistung zwischen 15:40 und 16:10 besser zu nutzen.
Insbesondere zwischen 15:40 und 16:00 ist er aber noch von deutlich zu viel Überschuss ausgegangen, da er scheinbar noch vom gesammten Überschuss ab 15:00 Uhr ausgegangen ist. Ich hab mal die Debug Logs von dem Tag mit angehängt


Woher kommen diese unterschiedlichen OTP's innerhalb kurzer Zeit, bei gleichen Überschuss und Ladebedarf?

2025.10.22 16:58:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? yes
2025.10.22 16:58:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7243 Wh, Surplus: 2673 Wh, OTP: 906 W
2025.10.22 16:58:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 1/1, SoC S/E: 7243 / 7271 Wh, Surplus: 32 Wh, OTP: 600 W

2025.10.22 16:59:44 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? yes
2025.10.22 16:59:44 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7204 Wh, Surplus: 2673 Wh, OTP: 1613 W
2025.10.22 16:59:44 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 1/1, SoC S/E: 7204 / 7232 Wh, Surplus: 32 Wh, OTP: 944 W

2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 515 Wh -> target likely achievable? yes
2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/16 - hod: 17 / 00, lr/lc: 1/1, SoC S/E: 7165 / 7204 Wh, Surplus: 2673 Wh, OTP: 2000 W
2025.10.22 16:59:50 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 22/17 - hod: 18 / 01, lr/lc: 1/1, SoC S/E: 7204 / 7232 Wh, Surplus: 32 Wh, OTP: 1764 W

Viele Grüße

Hadl

[DS_Starter]

Target achievable ist heute ein paarmal weg gewesen, und am Ende wurde der Akku gerade so voll. Ich hab die default safety margin eingestellt.

Gerade so voll ... dann hat das Verfahren gut funktioniert. Wäre die Bat deutlich zeitiger voll gewesen, wäre die Ladeleistung im Prinzip zu hoch gewesen. Im anderen Fall wäre sie nicht voll geworden.
Das ist ein Tanz auf der Rasierklinge, aber das soll ja das Ziel sein.
Ansonsten den Standard 'loadRelease' nutzen, was ich zu dieser Jahreszeit bevorzugen würde -> siehe Wiki.

Interessant finde ich das er am Ende der Stunde immer noch die Kapazität der aktuellen Stunde einrechnet

Diese Größe ist wichtig für die iterative Festlegung der Ladeleistung. Es gibt nur das Raster von 1h. Der Überschuß ist eine Rechengröße. Selbst wenn man den Aufwand treiben würde den Überschuß rein rechnerisch z.B. in 5 Minuten-Raster aufzuteilen sagt es nichts aus, denn 90% des kalkulierten Überschuß können sich je nach Situation in den ersten 15 Minuten niederschlagen, die restliche 10% in den 45 Minuten danach. Nur als Beispiel, kann man beliebig ändern.

Und obwohl ich ab 16:15 die empfohlene Ladeleistung nichtmehr erfüllen kann, sinkt die empfohlene Leistung trotzdem. Bis er sie dann um 17:00 achievable=0 hat.

Weil sich die Iteration an den kalkulierten Überschüssen orientiert und gleichzeitig die Ladeleistung hinreichend gering hält um das Spannungsfeld "möglichst niedrige Ladeleistung" <-> "Ladezielerreichung" optimal ausregeln. Diese beiden Ziele verhalten sich prinzipiell gegensätzlich.
Zur Feineinstellung kann man safetyMargin erhöhen wenn einem die 20% Puffer zu knapp sind.

Insbesondere wäre es sinnvoller gewesen nachdem er um 15:00 schon nichtmehr "achievable" prognostiziert hatte, die hohe Leistung zwischen 15:40 und 16:10 besser zu nutzen.

Das wurde gemacht. Ab 15:00 hast du pinmax (2000W) als Ladeleistung im Diagramm. Und zwar solange, bis wieder achievable=1 eingeschätzt wurde. Das ist ein dynamischer Prozess der sich ständig neu berechnet je nach Ladung der Bat, PV und Verbrauch, einberechnete Effizenz usw...

Um 14:00 und 15:00 war achievable auch kurz weg. Könnte man nicht hier die aktuelle Stunde nur mit dem Anteil der verbleibenden Zeit bis Stundenende mit einrechnen? Dann hätte man nicht diesen "Stunden-Sägezahn"

Das hatte ich oben schon erläutert. Und was ist denn an dem Kurvenverlauf nur so störend? Zumal sicher jeder einen anderen Plot sieht. Sieh dir meinen von heute zum Beispiel im Anhang an.

Woher kommen diese unterschiedlichen OTP's innerhalb kurzer Zeit, bei gleichen Überschuss und Ladebedarf?

Die Zielleistung wird abfallend proportional zum linearen Rest-Überschuss des Tages berechnet.
In #4259 hatte ich schonmal die sich ergebende Kennlinie der Logik gezeigt.
Den dafür verwendeten Berechnungsvorschlag hast du übrigens selbst eingebracht. 

LG,
Heiko

[grappa24]

Bei uns sah das heute bei 12 kWh Ausbeute mit smartPower wie folgt aus (Speicher war gegen 17 Uhr ca. 70 % voll):

[DS_Starter]

Passt, die verfügbare PV-Leistung wurde zu 99-100% soweit ich im Diagramm sehe für die Batterie genutzt.
Die Wechsel zu pinmax und vice versa kommen von der wechselnden Einschätzung achievable=1/0.