76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

DS_Starter

ZitatDessen 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



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

peterboeckmann

Hallo TheTrumpeter,

Zitat von: TheTrumpeter am 10 Dezember 2025, 06:46:40Helligkeitssensor

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

Zitat von: DS_Starter am 10 Dezember 2025, 09:17:44Das 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.).
Zitat von: DS_Starter am 10 Dezember 2025, 09:17:44Dadurch 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:
Zitat von: TheTrumpeter am 09 Dezember 2025, 07:23:08Mit 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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

Zitat von: peterboeckmann am 10 Dezember 2025, 10:35:46hast 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.

Zitat von: peterboeckmann am 10 Dezember 2025, 10:35:46Ich 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.)


Zitat von: peterboeckmann am 10 Dezember 2025, 10:35:46Und 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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

DS_Starter

#4624
Moin,

ZitatOder 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.

 
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

TheTrumpeter

Zitat von: DS_Starter am 11 Dezember 2025, 09:54:31ob die durch den Wetterdienst vorhergesagte Bewölkung (für die kommenden Stunden) die örtlichen Gegebenheiten realistisch prognostiziert.
Klar, das Problem bleibt immer bestehen...

Zitat von: DS_Starter am 11 Dezember 2025, 09:54:31vor 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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

DS_Starter

ZitatWenn 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.
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