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.