76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Dessen Werte korrelieren sehr gut mit der (momentanen) PV-Leistung

Ja, das glaube ich dir und das sieht man auch.

Das Problem ist, dass die gemessenen Werte ein Pendant in der Vorhersage brauchen um damit direkt einen Korrekturfaktor ableiten zu können.
Also:

Gemessen Lumen -> Vorhersage in Lumen  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Gemessen rad1h -> Vorhersage in rad1h  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Da diese Gegebenheiten (auch rad1h) nicht gemessen, sondern nur vorhergesagt werden, ergibt sich diese Vorgehensweise:

Vorhersage in rad1h X + Vorhersage von Rahmenbedingungen (Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von rad1h X mit gleichen/sehr ähnlichen Rahmenbedingungen angewendet wird.

Umgesetzt / unterstützt durch einen Strahlungs-/Helligkeitssensor würde es sich so darstellen:

Vorhersage in Lumen X + Vorhersage von Rahmenbedingungen (rad1h, Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von Lumen X mit gleichen/sehr ähnlichen Rahmenbedingungen (rad1h, Bewölkung etc.) angewendet wird.

Dadurch ergibt sich die Notwendigkeit eine Vorhersage in Lumen für die kommenden Stunden zu haben, was nicht gegeben ist.

Diesen Zusammnhang gibt es auch bei Verwendung eines neuronalen Netzes. Wenn man die KI mit dem gemessenen Lumen-Wert im Training füttert (was als gemessener Wert sehr sinnvoll ist), benötigt man für die Abfrage des trainierten Modells zur Prognose ebenfalls einen Eingangswert Lumen für die abgefragte Stunde. Der steht aber nicht zur Verfügung, maximal als irgendwie geartete Umrechnung des prognostizierten rad1h falls man das überhaupt umrechnen kann. Dann kann man aber auch gleich rad1h benutzen wie es aktuell getan wird ODER man hat einen Strahlungsmesser der die Solarstrahlung misst und man diese gemessenen Werte beim KI Trainung verwendet. Dann macht es wieder Sinn.

Abgesehen von der ganzen Betrachtung haben die Ungenauigkeite bei der Bewölkungsprognose deutlich mehr Einfluß auf das Ergebnis als andere Faktoren. Eine einzige größere Wolke am sonst wolkenlosen Himmel kann die Stundenprognose zerstören wenn deren Schatten genau auf die kleine Solarfläche von 10 x 10 Meter fällt. Wir sind schon ein wenig vermessen in einem solchen Mikrokosmos Stundenprognosen aufzustellen ... klappt aber irgendwie doch ganz gut über weite Strecken. 

LG,
Heiko

[peterboeckmann]

Hallo TheTrumpeter,

Helligkeitssensor

hast Du an jeder PV-Fläche so einen Helligkeitssensor? Unterscheidet die Helligkeit sich je nach Ausrichtung der Module?
Ich könnte mir vorstellen, dass Einstrahlung und Abschattung von der Helligkeit erfasst werden. Aber auch diffuse Strahlung?
Meine Anlage besteht aus einem nach ONO und einem nach WSW ausgerichteten String. Daher meine Fargen.

Und etwas OffTopic: Hast Du einen Helligkeitssensor "von der Stange" oder selbst was gelötet? Wie hast Du den umgesetzt?

Viele Grüße,
Peter

[TheTrumpeter]

Das Problem ist, dass die gemessenen Werte ein Pendant in der Vorhersage brauchen um damit direkt einen Korrekturfaktor ableiten zu können.
Also:

Gemessen Lumen -> Vorhersage in Lumen  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Gemessen rad1h -> Vorhersage in rad1h  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Dadurch ergibt sich die Notwendigkeit eine Vorhersage in Lumen für die kommenden Stunden zu haben, was nicht gegeben ist.

Klar, das geht so nicht.

Drum habe ich auch geschrieben:

Mit der Zeit müsste es dann auch möglich sein aus den (durchschnittlichen) Helligkeitswerten auf das Wetter zu schließen, um es für die Prognosen zu berücksichtigen. (Beispielsweise könnte das NN lernen, dass ein durchschnittlicher Helligkeitswert von > 50.000 lux im Dezember zwischen 11 und 12 Uhr "ungetrübter Sonnenschein" bedeutet und die Erzeugung dieser Stunde somit "Sonne" zuweisen und nicht wie von der Wetter-API vielleicht behauptet "Nebel".

Oder anders, die KI müsste den Helligkeitswerten erstmal das tatsächliche Wetter zuordnen, d.h. beispielsweise
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 40.000 und 50.000: ungetrübter Sonnenschein
Juli 11-12 Uhr, Durchschnitt Lumen zwischen 40.000 und 50.000: teilweise bewölkt
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 25.000 und 40.000: teilweise bewölkt
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 5.000 und 10.000: vollständig bewölkt

Der IST-Wert vom 10.12.2025 11-12 Uhr wird dann abhängig von dem Lumen-Wert der Wetterbedingung zugeordnet, d.h. wenn die Lumen bei 8.000 lagen => vollständig bewölkt.
Dann lernt das NN mit der Zeit, dass im Dezember bei vollständiger Bewölkung zwischen 11 und 12 Uhr 3kW vom Dach kommen.
Bei der Prognose kann dann das berücksichtigt werden, wenn die Wettervorhersage "vollständig bewölkt" behauptet.

[TheTrumpeter]

hast Du an jeder PV-Fläche so einen Helligkeitssensor? Unterscheidet die Helligkeit sich je nach Ausrichtung der Module?

Ja.
Aber ich habe nur eine Fläche, ca. SSO ausgerichtet.

Ich könnte mir vorstellen, dass Einstrahlung und Abschattung von der Helligkeit erfasst werden. Aber auch diffuse Strahlung?

Abschattung des Sensors gibt's nur in den hellsten 4-5 Wochen in der ersten und letzten Stunde nach/vor Sonnenauf-/untergang, d.h. praktisch vernachlässigbar.
Abschattung der PV-Module gibt's nur an wenigen Tagen im Winter kurz vor Sonnenuntergang, auch das ist vernachlässigbar. (Nur 1 String ist davon betroffen, aber zu dem Zeitpunkt kommen eh nur mehr ca. 200 W von 1 String.)

Und etwas OffTopic: Hast Du einen Helligkeitssensor "von der Stange" oder selbst was gelötet? Wie hast Du den umgesetzt?

Ich habe das alte "Theben Luxor" System zur Beschattungssteuerung. Der Sensor ist auf der zugehörige Wetterstation "Luxor 412" integriert.
Da ich 3 Fassaden mit Behängen habe, habe ich zusätzlich noch 2 weitere Lichtsensoren, die von der Steuerung aber abhängig vom Widerstandswert nur "digital" ausgewertet werden. Das ganze System ist proprietär und funktioniert grundsätzlich gut, lässt aber je nachdem wie man die Schaltschwelle "Sonne ja/nein" setzt bzw. in welche Richtung man die Sensoren dreht "Lücken" in der Abdeckung. Das führt dann im Sommer dazu, dass zu spät und/oder zu kurz beschattet wird.
Entsprechend habe ich versucht das Ding zu "tweaken", siehe auch https://forum.fhem.de/index.php?topic=69123.0.

[DS_Starter]

Moin,

Oder anders, die KI müsste den Helligkeitswerten erstmal das tatsächliche Wetter zuordnen, d.h. beispielsweise
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 40.000 und 50.000: ungetrübter Sonnenschein
Juli 11-12 Uhr, Durchschnitt Lumen zwischen 40.000 und 50.000: teilweise bewölkt
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 25.000 und 40.000: teilweise bewölkt
Dezember 11-12 Uhr, Durchschnitt Lumen zwischen 5.000 und 10.000: vollständig bewölkt
...
Der IST-Wert vom 10.12.2025 11-12 Uhr wird dann abhängig von dem Lumen-Wert der Wetterbedingung zugeordnet, d.h. wenn die Lumen bei 8.000 lagen => vollständig bewölkt.

Das ist ein anderer Case, nämlich der Ersatz des Bewölkungsgrades durch eine Ableitung aus der Lumen-Messung. Das geht ohne KI auf herkömmlichen Wege.
Man überschreibt den Bewölkungsgrad des Wetterdienstes mit einer Ableitung aus dem gemessenen Lumen-Wert. Dieser Wert muß dann noch auf einen Bewölkungsgrad von 0...100% normiert werden damit er mit der Bewölkungsvorhersage des Wetterdienstes, von dem ja im nächsten Step die PV-Vorhersage abgeleitet wird, korreliert.

Damit hätte man eine Ist-Aufnahme des vorhandenen Bewölkungsgrades, bzw. der Strahlungsverhältnisse übertragen auf einen Bewölkungsgrad.

Das würde soweit funktionieren denke ich. Aber es bleibt in der Praxis die auch aktuell vorhandene Unsicherheit, ob die durch den Wetterdienst vorhergesagte Bewölkung (für die kommenden Stunden) die örtlichen Gegebenheiten realistisch prognostiziert. Damit steht und fällt die gesamte Prognosequalität und vor allem daraus ergeben sich auch aktuell unsere Abweichungen.

 

[TheTrumpeter]

ob die durch den Wetterdienst vorhergesagte Bewölkung (für die kommenden Stunden) die örtlichen Gegebenheiten realistisch prognostiziert.

Klar, das Problem bleibt immer bestehen...

vor allem daraus ergeben sich auch aktuell unsere Abweichungen.

Das bezweifle ich ehrlich gesagt.

Ich habe mittlerweile 2 Instanzen von SolarForeast laufen...
1x meine "alte Instanz", mit der ich "schalte und walte" inkl. Ist-Wert-Erfassung samt KI.
1x eine "neue Instanz" für die EEG, die ich betreibe. Da sind 2 WR konfiguriert (1x meiner und 1x der des 2. Einspeisers in der EEG), die im Wesentlichen die gleichen Erträge liefern sollten (Strings sehr ähnlich ausgerichtet, gleiche Peakleistung usw.). Ich verwende für diese Instanz dieselbe Wetterprognose und dieselbe PV-Prognose, aber ohne Lernen, weil ich die Erzeugung vom "fremden WR" nicht bekomme.

Wenn ich die beiden Vorhersagen vergleiche, gibt es bei meiner "alten Instanz" unrealistische Vorhersagen, deren Ursache meiner Meinung nach wegen wiederholt falscher Wetterprognosen falsch gelernte Korrekturfaktoren sind.

[DS_Starter]

Wenn ich die beiden Vorhersagen vergleiche, gibt es bei meiner "alten Instanz" unrealistische Vorhersagen, deren Ursache meiner Meinung nach wegen wiederholt falscher Wetterprognosen falsch gelernte Korrekturfaktoren sind.

Das ist nicht auszuschließen.

[TheTrumpeter]

Wenn ich die beiden Vorhersagen vergleiche, gibt es bei meiner "alten Instanz" unrealistische Vorhersagen, deren Ursache meiner Meinung nach wegen wiederholt falscher Wetterprognosen falsch gelernte Korrekturfaktoren sind.

Das ist nicht auszuschließen.

Eben.

Durch die Verknüpfung der IST-Werte mit dem IST-Wetter könnte das verhindert werden. Natürlich sind die Vorhersagen weiterhin falsch, wenn die Wettervorhersage falsch ist, aber zumindest passt der Vorhersagewert dann zum vorhergesagten Wetter.

[DS_Starter]

Moin,

wenn du magst, kannst du dir eine Normalisierungsfunktion überlegen, wie der mögliche (für mich aktuell unbekannte) Lumenbereich auf einen definierten Bereich von 0..100 gemappt werden kann. In diesem Bereich bewegt sich die Bewölkung. Die Funktion selbst ist nicht schwer, nur den maximal möglichen Lumenwert zu bestimmen der evtl. auch vom Sensor / Gerätetyp abhängt.
Um es generalisieren zu können, muß man herausfinden welcher der maximal mögliche Lumenwert ist. Die untere Grenze ist ja 0 (die Nacht).

Edit: Der Wert müsste natürlich als Durchschnittswert über eine Stunde ermittelt werden um wechselnde Verhältnisse zu glätten. Dazu kommt noch die Abhängigkeit vom Sonnenstand. Denn schwächere Lumen können im Winter bei wolkenlosen Himmel die gleichen Werte haben wie mit leichter bis mittlerer Bewölkung im Sommer.

[Wolle02]

Moin Heiko, kann man eigentlich den Zeitpunkt an dem der OTP-SoC neu berechnet und eingestellt wird irgendwo einstellen oder fixieren? Bei mir wandert der immer etwas. Am Anfang war er zum Ende des Sonnentages, so um den Sonnenuntergang herum, dann war er plötzlich um Mitternacht und aktuell ist er morgens um halb sechs. Das führt dazu, dass die Batterie dann Nachts plötzlich auf einen bestimmten SoC-Wert entladen wird, nur um dann ein paar Stunden später mittels Zwangsladung aus dem Netz wieder auf einen neuen SoC geladen zu werden.
Ich für mich fände es passend einen Zeitpunkt für die Neuberechnung eine Stunde vor Sonnenuntergang zu haben.

[DS_Starter]

Hallo Wolle02,

kann man eigentlich den Zeitpunkt an dem der OTP-SoC neu berechnet und eingestellt wird irgendwo einstellen oder fixieren?

Der opt. SoC wird ständig neu berechnet, aber erst nach der halben Strecke zwischen Sonnenauf- und Untergang aktiviert sofern der neue SoC höher als der alte Sollwert ist. Die care Zeit spielt auch noch eine Rolle.
Eine Verringerung des Soll-SoC wird sofort umgesetzt.
Nachverfolgen kann man es mit dem Debug "batteryManagement".

Code Auswählen Erweitern

2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 859 Wh, con till sunset: 1884 Wh, Surp: -1025 Wh
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 4704 Wh, con till sunset: 13906 Wh, Surp: -5726 Wh (75% con)
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 0 Wh, need until maxsoc: 1421 Wh
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 10 %, remain days until care SoC: 19, Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: 100 %, newtarget: 45 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 45 % (no change)
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 10 %, upSoc: 50 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)


Am Anfang war er zum Ende des Sonnentages, so um den Sonnenuntergang herum, dann war er plötzlich um Mitternacht und aktuell ist er morgens um halb sechs. Das führt dazu, dass die Batterie dann Nachts plötzlich auf einen bestimmten SoC-Wert entladen wird, nur um dann ein paar Stunden später mittels Zwangsladung aus dem Netz wieder auf einen neuen SoC geladen zu werden.

Wenn ich dich richtig verstehe, steht die Batterie morgens durch die Entladeprozesse auf dem gesenkten Soll-SoC. Das ist richtig, weil erwartet wurde, dass die Batterie über den kommenden Tag wieder aufgeladen wird.

Wenn diese Erwartung nicht erfüllt wird, sei es durch weniger PV oder mehr Verbrauch als erwartet, erhöht sich der SoC nicht wie erwartet und durch die evtl. neue Ziel-SoC Erhöhung um 5% ist der SoC unter Soll-SoC. Je nach Verhalten des BMS kann eine Unterschreitung des Soll-SoC um X % das BMS veranlassen eine Ladung aus dem Netz vorzunehmen. Eventuell kann man die Schwelle des BMS einstellen ab wann es mit Nachladung reagiert.

Jetzt kommt es darauf an wie dein BMS gebaut ist. Wenn es beispielsweise mit Prozentwerten arbeitet, könntest du im Modul die Schrittweite der SoC-Anpassung verkleinern mit ctrlBatSocManagementXX->stepSoC.
Beachte dabei aber den Zusammenhang careCycle * stepSoC = 100 wie in der Hilfe erwähnt.
Dadurch wird die Wahrscheinlichkeit erhöht, dass eine Ladung durch PV doch noch z.B. innerhalb der nächsten 3 Tage auf den erhöhten Soll-SoC erfolgt ohne dass sich das BMS veranlasst fühlt mit Netzstrom zu laden.

LG,
Heiko

[Parallix]

Übrigens: Die Integration von Helligkeitssensoren wird unerlässlich sein, um im Fall einer abgeregelten Netzeinspeiseleistung überhaupt noch erkennen zu können, ob zu einem Zeitpunkt mehr an PV-Leistung abgerufen werden kann, als dies zu diesem Zeitpunkt aktuell der Fall ist. Daher möchte ich anregen, diesen Fall bei der Weiterentwicklung von SF zu berücksichtigen.

[DS_Starter]

Übrigens: Die Integration von Helligkeitssensoren wird unerlässlich sein, um im Fall einer abgeregelten Netzeinspeiseleistung überhaupt noch erkennen zu können, ob zu einem Zeitpunkt mehr an PV-Leistung abgerufen werden kann, als dies zu diesem Zeitpunkt aktuell der Fall ist. Daher möchte ich anregen, diesen Fall bei der Weiterentwicklung von SF zu berücksichtigen.

Gerne. Deswegen habe ich in #4628 schon einige Aspekte aufgeschrieben, die dafür gelöst werden müssen.
Ich freue mich auf euren Input.