76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

tpm88

Hallo Heiko,

aus gegebenen Anlass - werden die stündlichen und von der AI optimierten Korrekturfaktoren bezüglich der erwarteten PV Erzeugung an die Winterzeit angepasst?

Ich habe eine Verschattung durch einen Baum, die jetzt quasi eine Stunde früher zuschlägt...

VG, Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

DS_Starter

Die jeweiligen Medianwerte als Grundlage für die Faktoren verschieben sich, somit auch die Korrekturen. Aber das dauert etwas. Wie sich das konkret bei einer Baumverschattung ausspielt, ist interessant zu erfahren. Bei einer solchen Verschattung kommen als Einflußfaktoren ja nicht nur die Stundenverschiebung, sondern auch die jahreszeitliche Sonnenstandänderung zum Tragen. Dieser Prozess ist natürlich nicht so abrupt wie die Stundenverschiebung.

Ich hoffe die EU schafft diesen Unsinn irgendwann ab ... hoffen darf man ja.  ;)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

#4337
Habe mir die Tage nochmal Gedanken gemacht, wie man die Volatiliät der solaren Leistung über den Tag in SF auch in der Ladestrategie "optPower" geeignet berücksichtigen könnte, wenn man die von SF angelieferte optimale Ladeleistung als durchgängig gesetzten Maximalwert eines Hybridwechselrichters ansieht.

Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte. Über die zeitlich gemittelte Abweichung dieser RMS-Leistung von der von SF berechneten optimalen Ladeleistung könnte dann letztere dynamisch angepasst werden. Vorliegend führt die zeitliche Mittellung zu einem sanften Anheben der Leistung, was ganz in Linie mit der "optPower"-Strategie ist.

@Heiko & all: Was haltet Ihr davon?

Edit: Noch eine Frage am Rande: Nach meinem Verständnis müsste ein in SF registrierter Verbraucher mit einer per default eingestellten mintime von 120 Minuten nach dessen Einschalten für mindestens 120 Minuten in der Verbrauchsvorausschau erscheinen, wenn interruptable auf dem Default-Wert (0) belassen wird, oder?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Hadl

Zitat von: DS_Starter am 26 Oktober 2025, 11:18:34
ZitatMeine Berechnung für 14:00 würde erwarten: Bedarf 3279 Wh auf 3 Stunden aufgeteilt sind 1093 W
Stunde2: Bedarf 3279 Wh in 3 Stunden. Surplus: 997 Wh => 997W Laden + 20% Margin = 1196 W
Stunde1: Bedarf 2282 Wh in 2 Stunden. Surplus: 1736 => 1141W Laden  + 20% Margin = 1369 W
Stunde0: Bedarf 1141 Wh in 1 Stunden. Surplus: 4306 => 1141W Laden + 20% Margin =  1369 W
Das ist nur die halbe Wahrheit, denn smartPower benutzt eine Ratio gewichtete Margin aus (Rest)Tagesüberschuß und Ladebedarf, die du in #4248 ins Spiel gebracht hast und die ich in #4259 beschrieben habe.
Hallo Heiko, ja danke das habe ich mir ja selbst gewünscht, aber in dem Fall sollte es keine Bedeutung haben, da bei einem Bedarf von 3279Wh und einen Überschuss von
14:00: 4306Wh+1736Wh+997Wh=7039Wh; 7039/3279=214% das ist deutlich größer als 120% von 3279Wh => keine Auswirkung
14:51: 718Wh+1736Wh+997Wh=3451Wh; 3451/2035=170% das ist deutlich größer als 120% von 2035 => keine Auswirkung
15:00: 1736Wh+997Wh=2733Wh ; 2733/1843=148%, das ist deutlich größer als 120% von 1843Wh => keine Auswirkung
Übersehe ich hier was?

Zitat von: DS_Starter am 26 Oktober 2025, 11:18:34ABER...dank deines Anschubses habe ich mir die Routine nochmal angeschaut und festgestellt, dass ich leider statt des (Rest)Tagesüberschusses die (Rest)Tages-PV-Erzeugung eingebracht habe.
Das habe ich korrigiert.

Das Modulupdate liegt im Contrib.
Vielen Dank, ich probiers gleich aus!

Generell hab ich mir nochmal Gedanken gemacht und die aktuelle Implementierung angesehen.
Ich denke wir könnten eine deutlich gleichmäßigere Leistung erzielen wenn wir weniger auf die aktuelle Stunde als Zeitfenster schauen, was zum Ende der Stunde manchmal zu Abweichungen führt, sondern immer den Rest-Tag als Fenster hernehmen.
Für den Rest-Tag berechnen wir eine Durchschnitts-Leistung die notwendig ist. Diese Durchschnitts Leistung wird dann erhöht durch die Begrenzug der Leistung in Stunden die diesen Durchnitt nicht erbringen können.
Die Erhöhungen durch die ganzen Margin/OptPower/Efficiency Aufschläge machen wird dann im Anschluss mit der errechneten Optimal-Leistung

Im Code müsste man dann $spls warscheinlich durch $total/RestOfDay ersetzen. Den Wert dann in der Schleife von den schwächsten Surplus zu den stärkeren Surplus Stunden erhöhen wie oben beschrieben

Zitat von: Parallix am 27 Oktober 2025, 09:52:29Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte. Über die zeitlich gemittelte Abweichung dieser RMS-Leistung von der von SF berechneten optimalen Ladeleistung könnte dann letztere dynamisch angepasst werden. Vorliegend führt die zeitliche Mittellung zu einem sanften Anheben der Leistung, was ganz in Linie mit der "optPower"-Strategie ist.
Den RMS halte ich nicht für sinnvoll, da wir damit ja kurze Ausreiser eher aufwerten, in der Praxis aber nicht nutzen wollen.
Für die Zukunft/Prognose hätten wir ja nur Stundenwerte, das heißt ein Ausreiser wäre ja eine Stunde. Warum sollten wir den Quadratisch in ein Mittel einbeziehen?
Ich würde auch versuchen garkeine künstliche Fensterbreite zu definieren, denn wir wollen ja den Rest-Tag möglichst gleichmäßig haben, dann sollten wir auch diesen Zeitraum betrachten.
FHEM: Rpi 5 + SSD / WR: Fronius Symo Gen24 10.0 Plus + BYD HVS 7.7, Fronius Symo Gen24 12.0 SC (60%) PV: (Ost=3.5 West=6.6 Nord=9.9 Ost=4.5) / Homematic BidCoS / Shelly / Viessmann

Parallix

Zitat von: Hadl am 27 Oktober 2025, 10:44:10
Zitat von: Parallix am 27 Oktober 2025, 09:52:29Mein vorläufiges Ergebnis ist, dass hierzu die RMS-Leistung in einem zeitlich gleitenden Fenster, das nicht zu klein aber auch nicht zu groß sein darf (Fensterbreite ca. 1h), herangezogen werden könnte.
...
Den RMS halte ich nicht für sinnvoll, da wir damit ja kurze Ausreiser eher aufwerten, in der Praxis aber nicht nutzen wollen.
...

Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Hadl

Zitat von: Parallix am 27 Oktober 2025, 10:56:03Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 
Dann hab ich da was falsch verstanden. Kannst du bitte nochmals erklären über welche Werte du den RMS rechnen willst?
FHEM: Rpi 5 + SSD / WR: Fronius Symo Gen24 10.0 Plus + BYD HVS 7.7, Fronius Symo Gen24 12.0 SC (60%) PV: (Ost=3.5 West=6.6 Nord=9.9 Ost=4.5) / Homematic BidCoS / Shelly / Viessmann

Parallix

Zitat von: Hadl am 27 Oktober 2025, 12:18:50
Zitat von: Parallix am 27 Oktober 2025, 10:56:03Nein! Sie führen keinesfalls zu keinem RMS-Anstieg, da die Leistung ja (gemäß Annahme) gedeckelt ist! 
Dann hab ich da was falsch verstanden. Kannst du bitte nochmals erklären über welche Werte du den RMS rechnen willst?
Die tatsächliche RMS-Leistung (von WR zum Speicher), die pro SF-Zyklus aus der in den Akku verbrachten Energie (typischerweise in Wh angegeben) und der SF-Zykluszeit (Default: 90s) berechnet wird.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS