76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

Da es nicht systematisch zu einer bestimmten Uhrzeit aufzutreten scheint, glaube ich nicht, dass es an irgendwelchen (falsch gelernten) Korrekturfaktoren liegt.

Wenn du in der Grafik auf den Wert hinter "Qualität:" klickst, bekommst du ein Popup mit den verwendeten Korrekturfaktoren jeder folgenden Stunde. Damit kannst du deine Annahme überprüfen.

So, hat zwar ein bisschen gedauert, aber ich hab's erwischt. Wenn ich die Daten richtig interpretiere, liegt es wohl an einem zu hohen Korrekturfaktor:

Code Auswählen Erweitern

2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string PV1 ->
Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 Wh
Module Temp (calculated) => 26.55 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.06 kWp
modulePeakString => 8400 W

2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 string PV3 ->
Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 Wh
Module Temp (calculated) => 26.55 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.06 kWp
modulePeakString => 8400 W

2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV forecast start time 2024-05-27 15:00:00 limited to 15000 Watt due to inverter capacity
2024.05.26 11:55:42 1: mySolarForecast DEBUG> PV API estimate for tomorrow Hour 16 summary:
Cloudcover => 97
Forecasted temperature => 25.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.66
PV correction quality => 0.60
PV generation forecast => 15000 Wh
Starttime => 2024-05-27 15:00:00
Total Rain last hour => 0.00 kg/m2
Eine Frage noch dazu... kommen diese Werte direkt von der API oder sind die auch schon mit irgendwas "verrechnet"?

Code Auswählen Erweitern

Estimated PV generation (calc) => 7768.8 Wh
Estimated PV generation (raw) => 7768.8 WhDie kommen mir nämlich auch schon recht hoch vor...


Mittlerweile scheint wohl sowohl die Vorhersage als auch der Korrekturfaktor (deutlich) nach unten gegangen zu sein, sodass zumindest die Limitierung weg ist:

Code Auswählen Erweitern

2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 string PV1 ->
Estimated PV generation (calc) => 5074.8 Wh
Estimated PV generation (raw) => 5074.83 Wh
Module Temp (calculated) => 26.3 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.05 kWp
modulePeakString => 8410 W

2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 string PV3 ->
Estimated PV generation (calc) => 5074.8 Wh
Estimated PV generation (raw) => 5074.83 Wh
Module Temp (calculated) => 26.3 °C
Win(+)/Loss(-) String Peak Power by Temp => -0.05 kWp
modulePeakString => 8410 W

2024.05.27 06:36:41 1: mySolarForecast DEBUG> PV API estimate for today Hour 16 summary:
Cloudcover => 98
Forecasted temperature => 25.80 °C
PV Correction mode => on_complex_ai
PV correction factor => 1.13
PV correction quality => 0.89
PV generation forecast => 10149 Wh
Starttime => 2024-05-27 15:00:00
Total Rain last hour => 0.00 kg/m2

[DS_Starter]

Moin,

Eine Frage noch dazu... kommen diese Werte direkt von der API oder sind die auch schon mit irgendwas "verrechnet"?

Hier ist in beiden schon der Korrekturfaktor verrechnet.
Allerdings sollte "Estimated PV generation (raw)" den Wert aus der API und "Estimated PV generation (calc)" den Wert mit dem verrechneten Korrekturfaktur ausdrucken. Mein Fehler. Das korrigiere ich.

LG

[tomcat.x]

Hallo,

mir sind bei der Nutzung des Moduls so ein paar Fragen gekommen. Da ich gerade auf der Suche nach der Ursache für Abweichungen zwischen Prognose und Abweichungen bin, stelle ich sie mal.

Ich habe das Modul gerade in 3 Geräten zum Vergleich im Einsatz (OpenMeteoDWDAPI, OpenMeteoDWDEnsembleAPI, DWD für eine Station 10 km entfernt). Aktuell (gegen 17:00 und bei aktuellem Wetter passiert da heute nicht mehr viel) habe ich für heute fortlaufende Abweichungen zwischen 51 und 65 %. Ist das beim aktuellen Wetter normal?

Hier nun die Fragen:

• Was genau bedeutet der KI-Status: "... liefert jedoch keinen Wert für die aktuelle Stunde"? Oder anders gefragt, nach welcher Laufzeit sollte es den geben? Das habe ich laut Qualitätsübersicht in allen 3 Geräten für die meisten Stunden. 
• Werden die Strings von der KI separat betrachtet? Oder wenn die Ausrichtung gleich ist, macht es einen Unterschied, wenn man mehrere separat definiert? Ich Frage im speziellen, weil ich ein Problem mit Beschattung durch ein anders Gebäude habe, das die Strings je nach Tageszeit unterschiedlich betrifft.
• Vor dem Aufsetzen der 3 Geräte, hatte ich nur eins mit DWD (Station im Ort). Leider gab es bei der Station von einem Tag auf den anderen keine stündlichen Werte mehr, daher hatte ich auf OpenMeteoDWDAPI umgestellt. Hätte ich da die gelernten Werte zurücksetzen sollen?
• Die gleiche Frage für andere Änderungen, z.B. kleiner Fehler in der Ausrichtung der Module korrigiert bzw. Fehler in den Koordinaten (latitude,  longitude) korrigiert.

Vielen Dank für das Modul und die Beantwortung der Fragen
Thomas

[DS_Starter]

Hallo Thomas,

Was genau bedeutet der KI-Status: "... liefert jedoch keinen Wert für die aktuelle Stunde"? Oder anders gefragt, nach welcher Laufzeit sollte es den geben? Das habe ich laut Qualitätsübersicht in allen 3 Geräten für die meisten Stunden. 

Wann die KI einen Wert liefert ist nicht vorhersehbar, da es von der Dauer des Einsatzes und den Lernzustand abhängt. Deswegen gibt es auch keinen reinen KI Modus, sondern eine KI Unterstützung.
"get ... valDecTree aiRawData" bzw. "get ... valDecTree aiRuleStrings" gibt die einen Einblick und Erläuterungen.

Werden die Strings von der KI separat betrachtet?

Nein, es werden die Inputparameter Strahlung, PV-Ertrag, Bewölkung, Niederschlag, Sonnenstand (Altitude, Azimuth), Temperatur pro Stunde verwendet.

Vor dem Aufsetzen der 3 Geräte, hatte ich nur eins mit DWD (Station im Ort). Leider gab es bei der Station von einem Tag auf den anderen keine stündlichen Werte mehr, daher hatte ich auf OpenMeteoDWDAPI umgestellt. Hätte ich da die gelernten Werte zurücksetzen sollen?

Bei dem beschriebenen Wechsel der API nutzen die bisher gelernten Werte nicht mehr viel. Grund ist dass DWD die Globalstrahlung liefert und die OpenMeteoDWDAPI bereits eine sogenannte Tilted Globalstrahlung. Dort steckt der Einfuß der geneigten Fläche bereits mit drin.
Es stört aber auch nicht die Werte zu behalten, vllt. switched du das Device irgendwann mal wieder auf DWD Station zurück.

Die gleiche Frage für andere Änderungen, z.B. kleiner Fehler in der Ausrichtung der Module korrigiert bzw. Fehler in den Koordinaten (latitude,  longitude) korrigiert.

Nein. So großen EInfluß haben diese kleinen Änderungen i.A. nicht. Viel mehr fällt eine unvorhergesehene Bewölkung oder eine Wolke die sich ein paar Stunden über deiner Anlage "festsetzt", wenn drumherum die Sonne strahlt, ins Ertragsgewicht.

Die fortlaufenden Abweichungen zwischen 51 und 65 % sind sehr hoch. Bei mir sind sie zur Zeit bei OpenMeteoWorldAPI ca. 7%, SolCastAPI ca. 5%.
Allerdings habe ich zu den fortlaufenden Abweichungen ein eher gespaltenes Verhältnis und betrachte vorwiegend Tagesabweichungen nach Sonnenuntergang.
Die lagen gestern bei DWD lokal 3,3%, OpenMeteoDWDAPI -3,7 %, OpenMeteoDWDEnsembleAPI 2,4 %, SolCastAPI 5,2 %.
Die VictronKiAPI muß außen vor lassen. Da gab es gestern einen Issue wegen einer API Änderung den ich fixen musste.
Also alle arbeiten bei diesem Wetter sehr zufriedenstellend.

Wenn die Tagesabweichung sich einpendelt, ist alles ok. Ansonsten sollte man da nochmal hinschauen ob es ein Konfigurationsproblem gibt.

LG
 

[kask]

Die fortlaufenden Abweichungen zwischen 51 und 65 % sind sehr hoch

Das kann ich so nicht voll und ganz bestätigen. Habe ich auch ab und an mal, aber eher selten (nur bei sehr unbeständigem Wetter). +/-20% schon eher, aber nicht all zu häufig.
Meist +/-10%.
Ich habe heute +1.4% - -16% Deviation
Im mittel Aller 1% Deviation. Damit (Mittelwert) arbeite ich auch.

Und das mein Konfiguration nicht stimmt glaube ich auch nicht.

Ich habe auch teilweise so Abweichungen.
Mein Fazit ist das bei durchwachsenem Wetter sämtliche DWD Module besser funktionieren.
Bei gutem Wetter SolCastAPI & Victron.
Die openmeteo funktionieren am besten im Durchschnitt betrachtet.
ForcastSolarAPI ist bei mir eigentlich nur noch zum drüber ärgern. Da kann ich auch abends aus dem Fenster gucken und mach die Prognose selber mit gleichem effekt.

Der wirkliche Wert der deviation ist zum Stundenanfang eher "naja", zum Stundenende wird es Aussagekräftiger. Zum Tagesende die Wahrheit.

So sieht das halt bei mir aus.

[DS_Starter]

@kask, gebe dir vollkommen recht. Mir ging es nur darum falls es bei Thomas ein Dauerzustand sein sollte müßte man mal danach schauen.
Das recht große Abweichungen unter Tage immer mal vorkommen können steht außer Frage. Gerade bei wechselhaftem Wetter.

Der wirkliche Wert der deviation ist zum Stundenanfang eher "naja", zum Stundenende wird es Aussagekräftiger.

Liegt in der Natur der Sache. Am Anfang einer Stunde -> hohe Vorhersage + keine oder sehr wenig reale Erzeugung = großer Einfluß auf fortlaufende Abweichung.
 

[gent]

Evtl. hat es auch damit zu tun, dass ich in der ersten Ebene nicht alle Stunden abbilde?

Ich denke es liegt an der unterschiedlichen resultierenden Anzahl der Werte. In der oberen Reihe gibt es nur 20, d.h. die zukünftigen Werte sind nicht verfügbar.
Evtl. hilft es die Attr graphicHistoryHour und graphicHourCount für eine Optmierung zu verwenden. Welchen Wert hast du oben dargestellt?

Grüße,
Heiko

Du meinst im oberen Balkendiagramm? Da habe ich kein spezielles Attribut gesetzt. Ich nur folgende Attribute (die Consumer habe ich mal weg gelassen):

Code Auswählen Erweitern

attr Forecast DbLogExclude .*
attr Forecast affectConsForecastIdentWeekdays 1
attr Forecast ctrlStatisticReadings todayConsumptionForecast,todayGridConsumption,todayGridFeedIn
attr Forecast ctrlWeatherDev1 OpenMeteoDWDEnsemble-API
attr Forecast event-on-change-reading .*
attr Forecast flowGraphicAnimate 1
attr Forecast flowGraphicShowConsumerRemainTime 1
attr Forecast graphicBeam3Content gridconsumption
attr Forecast graphicBeam4Content consumptionForecast
attr Forecast graphicLayoutType double
attr Forecast verbose 2
Ich probiere mal die von Dir genannten Attribute aus.

Liebe Grüße
Holger

[DS_Starter]

@all,

morgen früh gibt es ein Update.

- Debug-Ausgabe von radiationProcess gefixt
- die Debug-Ausgabe von consumerSwitching ist nun für jeden Consumer separiert auswählbar.
  Insbesondere bei vielen Consumern erhöht es die Übersicht des Debuggings.

[tomcat.x]

Allerdings habe ich zu den fortlaufenden Abweichungen ein eher gespaltenes Verhältnis und betrachte vorwiegend Tagesabweichungen nach Sonnenuntergang.

Ja, keine Frage, sehe ich generell auch so. Gestern hat sich nach 17:00 Uhr aber wirklich nicht mehr viel geändert. Und es bringt halt nichts, wenn man um 11:00 einen Verbraucher bei 50 % Abweichung einschaltet, auch wenn gegen Abend dann wieder alles passt. Aber die hohe Abweichung ist ja nicht normal, also das Problem liegt woanders.

Das Wetter bei uns (Rhein-Main-Gebiet) würde ich aktuell schon als sehr wechselhaft bezeichnen. Der "April" hat schon im März angefangen und ist immer noch nicht zu Ende.

Zum Thema "Einpendeln": Die Umstellung auf OpenMeteoDWDAPI ist jetzt 8 Wochen her. Das DWD-Gerät mit der anderen Station ist erst ein paar Tage im Einsatz. Das mit OpenMeteoDWDEnsembleAPI so dazwischen.

Ich spiele jetzt mal Updates ein und suche dann weiter ...

Es sah übrigens mit der alten DWD-Station schon mal viel besser aus. An dem Gerät hatte ich außer der API nichts geändert. Die anderen sind Kopien davon. Die Einstellungen musste ich halt erneut vornehmen, weil die meisten (noch) in Readings gespeichert werden.

[stefanru]

Hi Tomcat,

ich bin auch im Rhein Main Gebiet.
Meine Abweichung gestern war -6,3%.
Ich benutze OpenMeteoDWD-API.

Gruß,
Stefan

[DS_Starter]

Und es bringt halt nichts, wenn man um 11:00 einen Verbraucher bei 50 % Abweichung einschaltet, auch wenn gegen Abend dann wieder alles passt.

Dafür ist die Abweichung-Info nicht gedacht. Das Modul erstellt auf Grund der Prognose die geplanten Schaltsequenzen der Verbraucher. Wenn sich die Wetterbedingungen gegenüber der Prognose ändern, nimmt das Modul eine automatische Anpassung vor sofern der Verbaucher noch nicht gestartet wurde. Sofern die Einstellungen des Verbrauchers es nicht erzwingen, erfolgt bei ungenügenden Überschuß keine Einschaltung.
Das Modul hat also eine entsprechende Logik dafür.
Ein laufende Abweichung hat ohnehin für die Verbraucherschaltung keine Relevanz. Wie ich am Beispiel erläuterte, hat man z.B. um 11:01 eine Prognose von 7000 Wh für diese Stunde, aber nur einen aktuellen Ertrag von 50 Wh. Die Abweichung wäre in diesem Fall exorbitant, aber im Laufe der Stunde gleicht es ich im Idealfall absolut an. Ich denke du siehst was ich damit sagen möchte.

Die Abweichung-Info hat eher die Aufgabe eine Statistik zu erstellen und uns Anwendern zu zeigen wie sich die Prognose/Ist Entwicklung darstellt. Wie im Anhang zum Beispiel.

[tomcat.x]

@Heiko: Ist schon klar, dass die Info nicht zur Steuerung gedacht ist. Wollte damit nur mein Problem mit einem einzelnen, direkt sichtbaren Wert verdeutlichen. Da ich beim Schreiben gestern den Tageswert noch nicht hatte, habe ich die laufenden Abweichungen (kurz vor Ende des Tages) genommen. Die Abweichung ist aber nur die Folge der fehlerhaften Vorhersage bei mir.

Noch ne Frage zu Deinem Beispiel mit "um 11:01 eine Prognose von 7000 Wh für diese Stunde, aber nur einen aktuellen Ertrag von 50 Wh" und "im Laufe der Stunde gleicht es ich im Idealfall absolut an." Bei mir gibt es keine Sprünge mit dem Stundenwechsel. Es sieht also eher so aus, als ob für die Berechnung nicht der stündliche Vorhersagewert mit der mit der minutengenauen Erzeugung verglichen wird. Also würden anhand des Beispiels eher die ~100 Wh für die erste Minute im Vergleich zu den 50 Wh in die Berechnung einfließen.

Aber generell, danke für Deine Hilfe. Dabei sein hilft schon. Die letzten beide Stunden hat es gut gepasst.

@Stefan: Danke für die Info.

[DS_Starter]

Morgen früh gibt es ein Update.
Das Attr ctrlStatisticReadings kennt einen neuen Wert "runTimeAvgDayConsumer".
Er gibt die durchschnittliche Laufzeit (Minuten) des Verbrauchers "XX" an einem Tag aus.

LG

[Dracolein]

Man kann Dir nicht oft genug "Danke" sagen für deine endlosen STUNDEN (!!) für dieses Projekt. MMn hat das mit einem klassischen Modul für FHEM schon gar nichts mehr zu tun;

Wenn es eine Enduser-freundliche Info geben wird, wie Dein Projekt "standalone/extern" auf einer eigenen Instanz lauffähig ist, werde ich das glaube ich umsetzen. Inzwischen ist dies Modul quasi im Zentrum meines FHEM-Projekts, weil es eben nicht nur "Spielereien" wie schaltbare Lampen, Rolläden o.ä. durchführt, sondern intelligente Steuerungen vorh. PV-Stroms diverser Verbraucher übernimmt, die mir effektiv Kosten einsparen.

[DS_Starter]

Freut mich Dracolein.
Ich gebe euch auf jeden Fall eine Info wenn die ersten Schritte für eine remote Fähigkeit vollzogen sind.
Das wird auch nicht mit einem Big Bang passieren, sondern schrittweise. Zum Beispiel wird man zunächst remote Meter integrieren können, dann Inverter usw. Ich muß mich auch erst rantasten wie ich das Ganze praktikabel gestalte.
Und natürlich hänge ich unfassbar mit dem Wiki hinterher. Das weiß ich, aber ich glaube Dokumentationen schreibt keiner von uns sehr gerne. 

LG,
Heiko