76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 27 Oktober 2025, 22:16:07

Ich habe dazu einen Abschnitt im Wiki geschrieben. Schau es dir mal an und wenn dann noch Fragen existieren melde dich einfach nochmal.

LG

Parallix · 28 Oktober 2025, 08:14:40

Hatte jemand von Euch schon mal die im Bild dargestellte Anzeige? Diese hatte ich noch nie und nun frage ich mich, welche Geister heute in meinem System werkeln

peterboeckmann · 28 Oktober 2025, 08:23:05

Hallo Parallix,

Zitat von: Parallix am 28 Oktober 2025, 08:14:40Hatte jemand von Euch schon mal die im Bild dargestellte Anzeige?

Die Meldung habe ich gelegentlich, wenn ich fhem neu starte - nach Update oder so - und auf der Raumseite mit SolarForecast bin.
Das gibt sich aber nach 1-2 Minuten.

Ich erkläre mir die Meldung so, dass die Datenmenge, die vom Backend ans Frontend als JSON geliefert wird, nicht vollständig ankommt und daher nicht geparsed werden kann.

Viele Grüße,
Peter

DS_Starter · 28 Oktober 2025, 08:38:52

Moin,

da müsste man ein Debugging mit den Browser Entwicklerwerkzeugen machen. Ich bin mit diesen Werkzeugen auch nicht so vertraut, Rudolph König ist da natürlich ein Wissender. Der Fehler müsste nur reproduzierbar sein, sonst ist es schwer zu finden.

Hast du oder Peter im global->encoding=unicode gesetzt?

Parallix · 28 Oktober 2025, 09:09:32

Zitat von: peterboeckmann am 28 Oktober 2025, 08:23:05...
Die Meldung habe ich gelegentlich, wenn ich fhem neu starte - nach Update oder so - und auf der Raumseite mit SolarForecast bin.
Das gibt sich aber nach 1-2 Minuten.

Ist bei mir tatsächlich auch so, tauchte heute aber erstmals (von mir bemerkt) auf.

@Heiko: global->encoding ist bei mir nicht (explizit) gesetzt.

DS_Starter · 28 Oktober 2025, 09:11:14

Ok (diese Einstellung ist experimentell). War nur eine Vermutung wegen "Unicode". Ansonsten habe ich eine solche JS Ausgabe auch noch nie bei mir gesehen.

peterboeckmann · 28 Oktober 2025, 09:32:07

Zitat von: DS_Starter am 28 Oktober 2025, 08:38:52Hast du oder Peter im global->encoding=unicode gesetzt?

Nein, das attr ist bei mir nicht gesetzt.

Viele Grüße,
Peter

Hadl · 28 Oktober 2025, 09:34:53

Zitat von: DS_Starter am 27 Oktober 2025, 19:21:21Nach meinem Gefühl gibt es Klärungsbedarf wie die Leistung in Battery_ChargeOptTargetPower_XX zu interpretieren ist.
Grundsätzlich ist dieser Wert eine _Leistungsbegrenzung_, keine Sollleistung. D.h. die Aussage "durchgehend mit pinmax=3000W laden wollen" ist so nicht richtig. Wir stellen diesen Wert in der Batterie als oberen Grenzwert ein, voraussetzend dass ohnehin durch das BMS gesteuert nicht mit mehr Leistung als dem realen Überschuß geladen werden wird.

Guten Morgen Heiko,
ja, das ist natürlich richtig. Auf der anderen Seite legen wir diesen Sollwert auch genau dort am Tag an, wo wir auch erwarten das wir ihn erfüllen können. Das trifft natürlich hauptsächlich die Zeiten mit Überschuss. Der Rückfall auf pinmax ist eher ein "wir nehmen was wir kriegen". Das BMS soll dann nach seiner Strategie regeln.

Zitat von: DS_Starter am 27 Oktober 2025, 19:21:21Interessant wäre gewesen wie es z.B. 10:15 ausgesehen hat.

Liefer ich gerne:

Code Auswählen

2025.10.27 10:15:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/10 - hod: 11/00, lr/lc: 1/1, SoC S/E: 4316/3915 Wh, Surp h/d: 0/6249 Wh, OTP: 3000 W

Scheinbar hat er da keinen Überschuss erwartet.
Ich würde mal zur Diskussion stellen ob man in dem Fall das am Rest-Tag mehr als genug Energie erwartet wird, wir nicht den notwendigen Durchschnittswert bereits einstellen.
Also ungefähr so:

Zitat von: Hadl am 27 Oktober 2025, 17:06:42Die Stunden von 10 bis 16 hätten alle genügend prognostizierten Überschuss gehabt um den Akku in diesen 7 Stunden mit konstant 521W vollzuladen.
521W * 120%(margin) / 87%(efficiency) = 719W
Kein weiterer Aufschlag wegen SmartPower da genügend Energie da ist.

Zitat von: DS_Starter am 27 Oktober 2025, 19:21:21Dieses Verhalten lässt mich allerdings immer mehr zu dem Schluß kommen die Zeitgewichtung wieder auszubauen da dieses Verfahren, wenn physikalisch auch richtig, nicht zielführend zu wirken scheint.

Ja, wenn man es nur auf eine Stunde betrachtet ansieht schwankt dadurch die Ladeleistung doch teilweise sehr.

Zitat von: DS_Starter am 27 Oktober 2025, 21:36:50Ich habe das Modul im Contrib upgedated. Das Debuglog zeigt weitere Informationen an wie zuvor geschrieben.
Weiterhin habe ich die Berücksichtigung der Zeitgewichtung derart abgeändert, dass sie sich nur noch auf die Bewertung der Zielerreichbarkeit auswirkt und nicht mehr auf die Power Iteration.
Vllt. löst diese Änderung schon das oben diskutierte Verhalten.

Ich habe aktualisiert und werde die Ergebnisse berichten

Was hältst du davon die Berechnung des OTP nicht auf den Werten der aktuellen Stunde aufzubauen, sondern auf der Summe des Rest-tages (inclusive Zeitgewichtung der aktuellen Stunde)
Das sollte dann deutlich gleichmäßigere OTP Werte ergeben, so wie in meinen selbstgemalten Bildern weiter oben. Und wäre auch physikalisch richtig. Auch wäre man toleranter wenn sich entgegen der Vorhersage eine Wolkenlücke früher oder später am Tag zeigt.

Viele Grüße

Hadl

DS_Starter · 28 Oktober 2025, 11:22:07

ZitatAuf der anderen Seite legen wir diesen Sollwert auch genau dort am Tag an, wo wir auch erwarten das wir ihn erfüllen können. Das trifft natürlich hauptsächlich die Zeiten mit Überschuss.

Ich vergaß ... ja in Zeiten mit deutlichem Überschuß befindet sich die Leistungsbegrenzung über weite Strecken gleichmäßig unterhalb der Überschußlinie. Die Leistung wird dann natürlich nicht auf pinmax gesetzt.

ZitatLiefer ich gerne:
Code Auswählen
2025.10.27 10:15:33 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 27/10 - hod: 11/00, lr/lc: 1/1, SoC S/E: 4316/3915 Wh, Surp h/d: 0/6249 Wh, OTP: 3000 W
Scheinbar hat er da keinen Überschuss erwartet.

Ja, genau. Deswegen ist das eine Stunde mit einem effektiven Verbrauch anstatt einem effektiven Überschuß über die gesamte Stunde gerechnet/geschätzt. Wenn keinerlei Überschuß erwartet wird, gehen wir auf pinmax. Es ist quasi der Ausgangszustand der auch zutrifft wenn die Regelung durch das Modul (zu bestimmten Zeiten) ausgeschaltet wird.

ZitatWas hältst du davon die Berechnung des OTP nicht auf den Werten der aktuellen Stunde aufzubauen, sondern auf der Summe des Rest-tages (inclusive Zeitgewichtung der aktuellen Stunde)

Das wird bereits gemacht. Man sieht es in dem aktuellen Debuglog besser. Heute ist ein Tag ohne jeglichen Überschuß, deswegen hier der Ausschnitt von morgen:

Code Auswählen

2025.10.28 10:52:21.429 1: SolCast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: optPower
2025.10.28 10:52:21.429 1: SolCast DEBUG> ChargeMgmt Bat 01 - General load termination condition: 0
2025.10.28 10:52:21.429 1: SolCast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.10.28 10:52:21.430 1: SolCast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 95 %
2025.10.28 10:52:21.430 1: SolCast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2025.10.28 10:52:21.430 1: SolCast DEBUG> ChargeMgmt Bat 01 - charging target: 100 % / 28416 Wh
2025.10.28 10:52:21.431 1: SolCast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2025.10.28 10:52:21.431 1: SolCast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2025.10.28 10:52:21.436 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
...
2025.10.28 10:52:21.445 1: SolCast DEBUG> ChargeOTP Bat 01 29/07 - hod:08/21, lr/lc:1/1, SocS/E:14208/14208 Wh, SurpH/D:0/9467 Wh, OTP:5040/- W
2025.10.28 10:52:21.445 1: SolCast DEBUG> ChargeOTP Bat 01 29/08 - hod:09/22, lr/lc:1/1, SocS/E:14208/15149 Wh, SurpH/D:991/8476 Wh, OTP:1189/3154 W
2025.10.28 10:52:21.445 1: SolCast DEBUG> ChargeOTP Bat 01 29/09 - hod:10/23, lr/lc:1/1, SocS/E:15149/17031 Wh, SurpH/D:1981/6495 Wh, OTP:2377/3154 W
2025.10.28 10:52:21.446 1: SolCast DEBUG> ChargeOTP Bat 01 29/10 - hod:11/24, lr/lc:1/1, SocS/E:17031/19001 Wh, SurpH/D:2074/4421 Wh, OTP:2489/3154 W
2025.10.28 10:52:21.446 1: SolCast DEBUG> ChargeOTP Bat 01 29/11 - hod:12/25, lr/lc:1/1, SocS/E:19001/21885 Wh, SurpH/D:3036/1385 Wh, OTP:3643/3154 W
2025.10.28 10:52:21.446 1: SolCast DEBUG> ChargeOTP Bat 01 29/12 - hod:13/26, lr/lc:1/1, SocS/E:21885/24881 Wh, SurpH/D:3154/0 Wh, OTP:3785/3154 W
2025.10.28 10:52:21.447 1: SolCast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/27, lr/lc:1/1, SocS/E:24881/26161 Wh, SurpH/D:1347/0 Wh, OTP:1616/1463 W
2025.10.28 10:52:21.447 1: SolCast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/28, lr/lc:1/1, SocS/E:26161/27551 Wh, SurpH/D:1463/0 Wh, OTP:1756/1463 W
2025.10.28 10:52:21.447 1: SolCast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/29, lr/lc:1/1, SocS/E:27551/27391 Wh, SurpH/D:0/0 Wh, OTP:5040/- W
2025.10.28 10:52:21.448 1: SolCast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/30, lr/lc:1/1, SocS/E:27391/26726 Wh, SurpH/D:0/0 Wh, OTP:5040/- W
...

Der zweite Wert nach OTP (z.B. OTP:1189/3154 W) ist der durch die Iterationslogik gelieferte Wert für Battery_ChargeOptTargetPower_XX. Er ist über weite Strecken im Beispiel konstant (9-13 Uhr und auch 13-15 Uhr). Der Wert davor ist der nachbehandelte und letztendlich eingesetzte Wert, der sich aus den unterschiedlichen Anforderungen der Strategien, Sicherheitsaufschlägen, Sicherheitszuschlags-Iterationen usw. ergibt. Also dem ganzen Blumenstrauß der individuellen Wünsche und eingeflossenen Erfahrungen der vergangenen Wochen (vllt. schon Monate?) die sich mit dem Thema befassen.

D.h. die Iterationslogik für den initialen Leistungsaufschlag passt aus meiner Sicht definitiv. Die Kunst besteht darin, die diversen individuellen Vorstellungen und Interessen im Ergebnis der Nachbehandlungen so zu bündeln, dass gut handhabbare Lösungen in Form von definierten Strategien im Sinne der Erreichung der Ziele entstehen. Das bedeutet aber auch, dass jeder bereit sein sollte Kompromisse einzugehen wenn die Idealvorstellung nicht 100%ig erreicht wird. Sonst wird das hier eine never ending Story.

Und es warten noch weitere spannende und herausfordende Aufgaben, wie zum Beispiel die Implementierung eines neuronalen Netzes zur besseren Vorhersagbarkeit des Verbrauches mit der Option dieses Modell im Erfolgsfall auch für die PV-Vorhersage zu nutzen und den bisher genutzten Entscheidungsbaum zu ersetzen.

LG,
Heiko

DS_Starter · 28 Oktober 2025, 11:46:52

Zur Ergänzung...
Hier sieht man nochmal den oben angeführten Bereich (der sich bereits dynamisch verändert hat) im Vergleich zwischen optPower und smartPower.

optPower:

Code Auswählen

2025.10.28 11:41:20.918 1: SolCast DEBUG> ChargeOTP Bat 01 29/07 - hod:08/20, lr/lc:1/1, SocS/E:14208/14208 Wh, SurpH/D:0/10974 Wh, OTP:5040/- W
2025.10.28 11:41:20.919 1: SolCast DEBUG> ChargeOTP Bat 01 29/08 - hod:09/21, lr/lc:1/1, SocS/E:14208/15149 Wh, SurpH/D:991/9983 Wh, OTP:1189/3834 W
2025.10.28 11:41:20.919 1: SolCast DEBUG> ChargeOTP Bat 01 29/09 - hod:10/22, lr/lc:1/1, SocS/E:15149/17086 Wh, SurpH/D:2039/7944 Wh, OTP:2447/3884 W
2025.10.28 11:41:20.919 1: SolCast DEBUG> ChargeOTP Bat 01 29/10 - hod:11/23, lr/lc:1/1, SocS/E:17086/19836 Wh, SurpH/D:2895/5049 Wh, OTP:3474/3986 W
2025.10.28 11:41:20.920 1: SolCast DEBUG> ChargeOTP Bat 01 29/11 - hod:12/24, lr/lc:1/1, SocS/E:19836/24545 Wh, SurpH/D:5172/0 Wh, OTP:4957/4131 W
2025.10.28 11:41:20.920 1: SolCast DEBUG> ChargeOTP Bat 01 29/12 - hod:13/25, lr/lc:1/1, SocS/E:24545/25457 Wh, SurpH/D:960/0 Wh, OTP:1152/1855 W
2025.10.28 11:41:20.920 1: SolCast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/26, lr/lc:1/1, SocS/E:25457/27627 Wh, SurpH/D:2433/0 Wh, OTP:2284/1903 W
2025.10.28 11:41:20.921 1: SolCast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/27, lr/lc:1/1, SocS/E:27627/28416 Wh, SurpH/D:1054/0 Wh, OTP:944/787 W
2025.10.28 11:41:20.921 1: SolCast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/28, lr/lc:0/1, SocS/E:28416/28256 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2025.10.28 11:41:20.921 1: SolCast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/29, lr/lc:1/1, SocS/E:28256/27591 Wh, SurpH/D:0/0 Wh, OTP:5040/-

smartPower:

Code Auswählen

2025.10.28 11:41:23.558 1: SolCast DEBUG> ChargeOTP Bat 01 29/07 - hod:08/20, lr/lc:1/1, SocS/E:14208/14208 Wh, SurpH/D:0/10974 Wh, OTP:5040/- W
2025.10.28 11:41:23.559 1: SolCast DEBUG> ChargeOTP Bat 01 29/08 - hod:09/21, lr/lc:1/1, SocS/E:14208/15149 Wh, SurpH/D:991/9983 Wh, OTP:5040/3834 W
2025.10.28 11:41:23.559 1: SolCast DEBUG> ChargeOTP Bat 01 29/09 - hod:10/22, lr/lc:1/1, SocS/E:15149/17086 Wh, SurpH/D:2039/7944 Wh, OTP:5040/3884 W
2025.10.28 11:41:23.559 1: SolCast DEBUG> ChargeOTP Bat 01 29/10 - hod:11/23, lr/lc:1/1, SocS/E:17086/19836 Wh, SurpH/D:2895/5049 Wh, OTP:5040/3986 W
2025.10.28 11:41:23.560 1: SolCast DEBUG> ChargeOTP Bat 01 29/11 - hod:12/24, lr/lc:1/1, SocS/E:19836/24624 Wh, SurpH/D:5172/0 Wh, OTP:5040/4131 W
2025.10.28 11:41:23.560 1: SolCast DEBUG> ChargeOTP Bat 01 29/12 - hod:13/25, lr/lc:1/1, SocS/E:24624/25536 Wh, SurpH/D:960/0 Wh, OTP:5040/1776 W
2025.10.28 11:41:23.560 1: SolCast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/26, lr/lc:1/1, SocS/E:25536/27847 Wh, SurpH/D:2433/0 Wh, OTP:5040/1824 W
2025.10.28 11:41:23.561 1: SolCast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/27, lr/lc:1/1, SocS/E:27847/28416 Wh, SurpH/D:1054/0 Wh, OTP:5040/567 W
2025.10.28 11:41:23.561 1: SolCast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/28, lr/lc:0/1, SocS/E:28416/28256 Wh, SurpH/D:0/0 Wh, OTP:0/- W

Hier wird deutlich, dass in beiden Fällen der Input durch die Iteration gleich ist, sich jedoch durch die Strategie-spezifischen Anpassungen entsprechend deutliche Unterschiede ergeben.

klaus.schauer · 28 Oktober 2025, 21:37:11

In meiner Konfiguration werden die LOG-Daten nicht als SVG-Plots ausgegeben. Nun bringt mich u. U. der Beitrag https://forum.fhem.de/index.php?topic=140509.0 weiter. Rudolf führt dies darauf zurück, dass LOG-Einträge nicht in der chronologische Reihenfolge in der LOG-Datei gespeichert sind. Dies ist in meinen LOG-Dateien tatsächlich so:

Code Auswählen

2025-10-27_00:00:04 SolarForecast wrote cachefile plantconfig successfully
2025-10-27_00:00:04 SolarForecast wrote cachefile airaw successfully
2025-10-27_00:00:04 SolarForecast gridTariff: N
2025-10-27_00:00:04 SolarForecast gridEnergyFixedPrice: 0.192542
2025-10-27_00:00:04 SolarForecast gridEnergySpotPrice: 0.0869057
2025-10-27_00:00:00 SolarForecast LastHourGridconsumptionReal: 0 Wh
2025-10-26_23:59:59 SolarForecast LastHourGridconsumptionReal: 699 Wh
2025-10-27_00:00:05 SolarForecast Today_SunRise: 07:18
2025-10-27_00:00:05 SolarForecast Today_SunSet: 17:18
2025-10-27_00:00:05 SolarForecast Tomorrow_SunRise: 07:20
2025-10-27_00:00:05 SolarForecast Tomorrow_SunSet: 17:16
...
2025-10-27_00:59:50 SolarForecast updated
2025-10-27_01:00:04 SolarForecast wrote cachefile airaw successfully
2025-10-27_01:00:04 SolarForecast gridEnergySpotPrice: 0.0869176
2025-10-27_01:00:00 SolarForecast LastHourGridconsumptionReal: 1375 Wh
2025-10-27_01:00:04 SolarForecast Today_Hour02_PVreal: 0 Wh
2025-10-27_01:00:04 SolarForecast Today_Hour02_GridConsumption: 0 Wh

Gibt es einen Grund, weshalb "LastHourGridconsumptionReal" mehrmals am Tag "falsch" einsortiert wird und könnte man das ändern? Soweit ich das sehe, scheint sonst alles richtig zu sein.

Rudolf schlägt vor, die fehlerhaften Datensätze in andere LOG-Dateien auszulagern. Das ist vielleicht nur die zweitbeste Lösung.

DS_Starter · 28 Oktober 2025, 22:39:14

ZitatGibt es einen Grund, weshalb "LastHourGridconsumptionReal" mehrmals am Tag "falsch" einsortiert wird und könnte man das ändern?

Die Readings LastHourGridconsumptionReal, LastHourPVforecast und LastHourPVreal beinhalten die Werte der vorangegangenen Stunde. Sie werden rückwirkend berechnet, weswegen sie immer den Zeitstempel XX:00:00 haben.
Also z.B. hat LastHourGridconsumptionReal den Stempel 2025-10-28 22:00:00 und enthält die Daten von Today_Hour22_GridConsumption mit dem Stempel 2025-10-28 21:59:56.
Das klappt bis zum Tageswechsel gut. Aber wenn ich LastHourGridconsumptionReal der letzten Stunde des Vortages erstelle, hatte ich als Zeitstempel 23:59:59 gewählt und nicht 24:00:00.
Ich kann dir heute nicht mehr sagen aus welchem Grund. Möglicherweise gibt es diesen Grund nach der langen Entwicklungszeit nicht mehr.

Ich habe den Zeitstempel in der Contrib Version zum Tageswechsel auf 24:00:00 umgestellt. Falls sich unerwartete Seiteneffekte einstellen, muß eine andere Lösung gefunden werden.

Edit: Ich bin mir unsicher ob das bei dir eigentlich hilft, der Timestamp ändert sich nur in 2025-10-26_24:00:00 statt 2025-10-26_23:59:59.

Eine "falsche" Einsortierung ist eine typische Problematik eines sequentiellen Filelogs. In einem DbLog ist es natürlich kein Problem und wird richtig eingefügt bzw. führt dadurch erst zu einem zutreffenden Plot da die Zeiträume zu den Werten passen.