76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Moin zusammen,

@Parallix,
Motivation ist schon da.  Die Umsetzung braucht ein bisschen Vorbereitung.

Bloß kein Stress! Aktuell mache ich es noch händisch und komme mit max. zwei bis drei Anpassungen der Ladeleistung aus.

Was die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.

Mein Aussage war so zu verstehen, dass ich um einen Vergleich mit der Anzahl der PV-Überschußstunden rechnen zu können, die Minimalleistung auf eine Stunde normieren muß um ebenfalls Wh zu bekommen. Anders gesagt, wenn die Bat mit der Minimalleistung von 50W eine Stunde lange geladen wird, sind das 50Wh. 
Wenn wir z.B. an einem Tag 10 Stunden ermitteln, in denen jeweils ein Überschüß >= 50Wh prognostiziert wird, hätten wir im Sinne der Anforderung einen Wert für Battery_ChargingHoursRemain_XX=10.

Das wäre m.M. nach die umzusetzende Logik zur Erstellung des Readings.

Dann bekäme man den Wert "nur" mit einer 1h-Auflösung am  PV-Produktionsende, oder?

Besser wäre es vermutlich, sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen anzusehen und daraus den zeitlichen Punkt abzuleiten, an dem die geforderte Mindestleistung unterschritten wird.

Am PV-Produktionsstart (morgens) ist übrigens keine Sonderberechnung erforderlich, da man dort ja noch weit von SOC=100% entfernt ist.

[DS_Starter]

Besser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?

Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.

[Wolle02]

ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.

Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.

Ok, danke. Irgendwie führt das bei mir immer wieder zu Missverständnissen. Dann fahre ich mal zweigleisig und regele die Batterie mit dem Skript und teile SF den Wert informatorisch mit.

Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

LG Wolle

[Parallix]

Besser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?

Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.

Dann würde man wohl die mittlere Leistung (Berechnung wie von Dir weiter oben angeben), zeitlich lokalisiert in der Mitte des 1h-Intervalls, heranziehen. Der Rest (linearer Ansatz) bliebe gleich.

[Parallix]

...
Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

Die Steuerung, ggf. auch Regelung, soll außerhalb von SF erfolgen, kann - in Teilen - natürlich von SF angestoßen und/oder mit Daten versorgt werden.  So jedenfalls hatte ich Heiko immer verstanden.. Darüber hinaus wird es ja auch künftig weitere, die Steuerung/Regelung steuernde Elemente geben, wie z.B. die Steuerbox.

[DS_Starter]

@Parallix,

mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.

Dann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.

Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.

@Wolle

Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

Momentan ist eine Regelung dieser Geräte nicht geplant. Dabei sind mehrere Aspekte zu berücksichtigen:

- die Varianten zur Steuerung bestimmter Eigenschaften in Invertern oder Batteriesystemen sind äußerst vielfältig und erfordern ein hohes
  Maß an im Modul zu hinterlegende Informationen die verwaltet und geprüft werden müssen

- unabhängig von den technisch/organisatorischen Herausforderungen gibt es auch die Frage nach einer Verantwortlichkeit wenn durch bestimmte Steuerungen,
  z.B. über Modbus, die Geräte in einen sagen wir mal "unerwünschten Zustand" versetzt werden.
  Ich möchte ungern eine derartige Zentralisierung im Modul herbeiführen. Allerdings sind solche Steuerungsmöglichkeiten immer optional, sodaß der
  User sie verwenden kann oder aber nicht wenn er eigene Logiken einsetzen möchte. Das ist ein Grundprinzip im Modul.

LG,
Heiko

[Parallix]

@Parallix,

mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.

Klar! Gerne!

Dann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.

Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.

Prima! Danke!

[DS_Starter]

@Parallix,

ich habe deinen Content in einen neuen Abschnitt ins Wiki eingebaut. Eventuell magst du noch weitere Aspekte ergänzen.

In dem Zusammenhang ist mir aufgefallen, dass es evtl. günstig wäre den Schlüssel ctrlBatSocManagementXX->loadAbort um einen Fallback-Wert zu ergänzen.
Also statt:

loadAbort=<SoC>:<PowerIn>

ein

loadAbort=<SoC1>:<PowerIn>:<SoC2>

Abgeschaltet würde man bei erreichen SoC1 und <= PowerIn. Battery_ChargeAbort_XX = 0 würde wieder gesetzt, wenn der SoC unter SoC2 fällt statt wie aktuell auch SoC1.

Rückwärtskompatibel wäre die Variante, denn es könnte SoC2=SoC1 angegeben werden.

LG,
Heiko

[DS_Starter]

@Parallix,

nochmal eine Frage zu dem Thema ...

Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Eigentlich müsste es meiner Meinung nach keine minimal geforderte Ladeleistung sein, sondern ein Ladeleistungsrichtwert den man angeben kann oder vllt. sogar eine maximal erlaubte (gesetzte) Ladeleistung.

Denn genau dann würde die ermittelte Anzahl Stunden mit "Überschuß > Ladeleistungsrichtwert" realistisch sein.
Würde ich die Stunden durch Vergleich "Überschuß > minimal geforderte Ladeleistung" ermitteln, würden sie nicht mehr zutreffen wenn die Ladeleistung höher als minimal gefordert wäre und den Prognose-Überschuß übersteigen würde.

Ich hoffe ich habe mich verständlich ausgedrückt. Es ist im Prinzip eine Definitionsfrage. Sie ist aber wichtig, da ich die vergleichende Ladeleistung als Parameter beschreiben muß was das eigentlich ist/sein soll.

[Parallix]

@Parallix,

ich habe deinen Content in einen neuen Abschnitt ins Wiki eingebaut. Eventuell magst du noch weitere Aspekte ergänzen.

Das mache ich natürlich gerne, sollte mir noch ein entsprechender Aspekt einfallen.

In dem Zusammenhang ist mir aufgefallen, dass es evtl. günstig wäre den Schlüssel ctrlBatSocManagementXX->loadAbort um einen Fallback-Wert zu ergänzen.
Also statt:

loadAbort=<SoC>:<PowerIn>

ein

loadAbort=<SoC1>:<PowerIn>:<SoC2>

Abgeschaltet würde man bei erreichen SoC1 und <= PowerIn. Battery_ChargeAbort_XX = 0 würde wieder gesetzt, wenn der SoC unter SoC2 fällt statt wie aktuell auch SoC1.

Rückwärtskompatibel wäre die Variante, denn es könnte SoC2=SoC1 angegeben werden.

Ohne <PowerIn> würde damit das von mir beschrieben Verfahren, welches z.B. BYD inzwischen einsetzt auch mit früheren FW-Versionen (die man vlt. nicht aktualisieren will) verfügbar machen.

Was die Abbruchbedingung angeht, ist es natürlich so, dass es nur sinnvoll ist, bei einer Ladeleistung < PowerIn das Laden zu beenden, wenn der SOC knapp unter 100% ist. Anders ausgedrückt: Wird ein <SoC1> deutlich kleiner als 100 angegeben, dann darf <PowerIn> durchaus auch 0 sein!

Ist damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden? Vielleicht habe ich Sie auch nur nicht richtig verstanden. Gucke sie mir morgen in aller Frische aber nochmal an.

[DS_Starter]

Was die Abbruchbedingung angeht, ist es natürlich so, dass es nur sinnvoll ist, bei einer Ladeleistung < PowerIn das Laden zu beenden, wenn der SOC knapp unter 100% ist. Anders ausgedrückt: Wird ein <SoC1> deutlich kleiner als 100 angegeben, dann darf <PowerIn> durchaus auch 0 sein!

Diese Möglichkeit hat der User, d.h. er kann die Bedingungen nach seinen Maßstäben definieren

Ist damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?

Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.

[Parallix]

Ist damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?

Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.

Wenn ich das richtig sehe, dann weicht Dein Anwendungsfall von meinem ab und wir haben deshalb einen unterschiedlichen Blick auf die Dinge. Daher möchte ich meinen nochmal ausführlich darstellen:

Wenn ein Akku über den Tag möglichst gleichmäßig unter ausschließlicher Nutzung von PV-Energie von einem CurrentSOC auf einen EndSOC gebracht werden soll, dann muss zunächst die Energiemenge E_L ermittelt werden, die per Ladung in ihn gebracht werden muss. Hierzu wird die Energie E_A benötigt, die maximal im Akku gespeichert werden kann. Nun kann E_L ausgerechnet werden:

E_L = E_A * (EndSOC – CurrentSOC)

Unter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich  die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe:

P_L = E_L / T_L

Zur Illustration habe ich unten die Ladekurve meiner Akkus an einem recht normalen PV-Tag angefügt.

PS[1]: Da während eines Tages unvorhergesehen sowohl solare Ertrag, der Hausverbrauch und damit die zur Ladung zur Verfügung stehende Ladeleistung variieren kann, sollte in regelmäßigen Abständen die o.g. Berechnung und das Setzen von P_L neu durchgeführt werden.

PS[2]: Je nach Situation kann P_L natürlich über den Tag auch aus anderen (als den o.g.) Gründen verändert werden. Bei einer schlechten PV-Prognosequalität (Unsicherheit) bietet sich z.B. eine höhere Ladung bereits zu Beginn eines Sonnentages an, um an Ende des Tages den Akku auch gesichert auf den Sollwert zu bringen.

[ch.eick]

Ist damit ggf. auch Deine Nachricht zum "Richtwert" obsolet geworden?

Eigentlich nicht. Ja, lies dir morgen meine Gedanken dazu nochmal durch. Wesentlich ist nicht so sehr der Wert an sich, sondern die verbale Definition. Es sei denn, du setzt gerade in Gedanken PowerIn mit der "minimal geforderten Ladeleistung" gleich. Aber auch dann könnte die reale Ladeleistung höher sein und würde ggf. den Überschuß übersteigen und somit die berechneten Stunden invalidieren.

Wenn ich das richtig sehe, dann weicht Dein Anwendungsfall von meinem ab und wir haben deshalb einen unterschiedlichen Blick auf die Dinge. Daher möchte ich meinen nochmal ausführlich darstellen:

Wenn ein Akku über den Tag möglichst gleichmäßig unter ausschließlicher Nutzung von PV-Energie von einem CurrentSOC auf einen EndSOC gebracht werden soll, dann muss zunächst die Energiemenge E_L ermittelt werden, die per Ladung in ihn gebracht werden muss. Hierzu wird die Energie E_A benötigt, die maximal im Akku gespeichert werden kann. Nun kann E_L ausgerechnet werden:

E_L = E_A * (EndSOC – CurrentSOC)

Unter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich  die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe:

P_L = E_L / T_L

PS[1]: Da während eines Tages unvorhergesehen sowohl solare Ertrag, der Hausverbrauch und damit die zur Ladung zur Verfügung stehende Ladeleistung variieren kann, sollte in regelmäßigen Abständen die o.g. Berechnung und das Setzen von P_L neu durchgeführt werden.

PS[2]: Je nach Situation kann P_L natürlich über den Tag auch aus anderen (als den o.g.) Gründen verändert werden. Bei einer schlechten PV-Prognosequalität (Unsicherheit) bietet sich z.B. eine höhere Ladung bereits zu Beginn eines Sonnentages an, um an Ende des Tages den Akku auch gesichert auf den Sollwert zu bringen.

Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.

VG Christian

[Parallix]

...
Moin,
Ich hatte auch mal versucht die Ladeleistung etwas gleichmäßiger zu regeln um in der Mittagszeit einen schönen grafischen Block zu bekommen, jedoch spielt zusätzlich noch die Ladekurve des Speichers mit rein. Ein möglichst linearer Anstieg des SOC ergibt bei mir eine Art von Keil bei der Ladeleistung. Letztendlich habe ich dann versucht die Ladeleistung so beim WR vorzugeben, das es sich auf die Zeit möglichst Netzdienlich verteilt. Zum Ende wird zwar eine hohe Wünschleistung vorgegeben, jedoch der Speicher entscheidet sich für weniger und es wird ein Keil.
...

Sinnvollerweise verändern die BYDs (und sicher auch andere) die max. Ladeleistung in Abhängigkeit vom akt. SOC und der Temperatur. Das ist auch gut, um den Akku nicht zu viel Stress auszusetzen.

[DS_Starter]

Unter der Annahme, dass die Ladeleistung während der gesamten Ladezeit nie unter die Ladeschlussleistung P_End fallen darf, stehen nicht alle Stunden mit Solarertrag zur Verfügung, sondern nur die, die eine Ladung mit o.g. Ladeschlussleistung garantieren. Also muss ich  die Zeit T_L kennen, die mir für die Ladung mit mindestens P_End (von Dir <PowerIn> genannt) zur Verfügung steht. Wenn ich T_L kenne, kann ich am Wechselrichter die Ladeleistung P_L so limitieren, dass ich den Akku erst am Ende des Tages auf den Zielwert EndSOC gebracht habe

Das <PowerIn> ist der Wert, den wir als eine Komponente der Ladeabbruchbedingung in ctrlBatSocManagementXX->loadAbort verwenden. Deswegen war meine Frage, ob die dort angegebene Leistung identisch zu der gerade diskutierten Ladeschlussleistung ist, da ich ansonsten einen weiteren Parameter in ctrlBatSocManagementXX einführen und auch entsprechend beschreiben muß was der User darunter zu verstehen hat.

Der erste Schritt um weiterzukommen wäre jetzt erstmal ein "Ja" oder "Nein".