Leistungsprognose für Wechselrichter

[DS_Starter]

--vorher------------------------------------------------
Next04Hours_PV 0 Wh
ThisHour_PVforecast 0 Wh
ThisHour_Time 25.01.2021 18:00:00
Today_PV 2993 Wh
Tomorrow_PV 3185 Wh
--nachher-----------------------------------------------
fc0_4h 0 Wh
fc0_1h 0 Wh
fc0_1h_time 25.01.2021 18:00:00
fc0_PV 2993 Wh
fc1_PV 3185 Wh

Ich sehe weiterhin keinen Vorteil noch nachher zu vorher. Trenne dich gedanklich vom DWD Device. Es ist nur eine Datenquelle. Demnächst ist es ein anderes Device oder die SolCast API. Die hat keinerlei Readings.
fc0 und fc1 als Trennung des heutigen Tages zum nächsten Tag gibt es im Modul nicht. Es werden immer die x nächsten Stunden ab der aktuellen Stunde betrachtet. Das sieht man an den aktuellen Readings.

# hier macht current für mich keinen Sinn

Aber für mich. Damit diese einzugebenden Daten in der Drop-Down gleich oben stehen. Ich habe mir dabei etwas gedacht ...

Bei einer Abfrage des Forecast für die aktuelle Stunde und die nächsten 4 Stunden wäre folgende Maske denkbar

Wie gesagt, wenn jemand sowas braucht zum Logging -> userReading

Gerade im Code merkt man, wie das Namenskonzept aufgebaut sein sollte.

Danke für den Hinweis.

[ch.eick]

Ich sehe weiterhin keinen Vorteil noch nachher zu vorher. Trenne dich gedanklich vom DWD Device. Es ist nur eine Datenquelle. Demnächst ist es ein anderes Device oder die SolCast API. Die hat keinerlei Readings.
fc0 und fc1 als Trennung des heutigen Tages zum nächsten Tag gibt es im Modul nicht. Es werden immer die x nächsten Stunden ab der aktuellen Stunde betrachtet. Das sieht man an den aktuellen Readings.
Aber für mich. Damit diese einzugebenden Daten in der Drop-Down gleich oben stehen. Ich habe mir dabei etwas gedacht ...
Wie gesagt, wenn jemand sowas braucht zum Logging -> userReading
Danke für den Hinweis.

Okay, ich wollte nur ziemlich zu Beginn drüber gesprochen haben. Ales klar, also einfach weiter

[jual]

Nur mal so am Rande, wie unterschiedlich die Prognosen sein können, insbesondere bei so schwierigen Wetterverhältnissen, wie heute. Irgendwie war das Wetter tatsächlich besser als alle Vorhersagen und irgendwie spiegelt sich das dann auch bei den Prognosemodellen wieder. Mal abgesehen davon, dass ich mit meinen zwei Ausrichtungen und unterschiedlichen Verschattungsthemen noch eine zusätzliche Ungenauigkeit einbringe.

Nachfolgende Prognosen habe ich heute morgen um 9:00 abgelesen. Danach habe sich aller auch noch ein wenig verschoben, die habe ich aber nicht mehr im Detail nachverfolgt.

Prognose mit DWD und je einem Device für Ost und West: ca. 2,5 kWh
Prognose über Solcast mit einer "Pseudoausrichtung", da nur eine Ausrichtung unterstützt wird: 0,8 kWh
Prognose über SMA Portal: 4,1 kWh

Also schon mal ziemliche Differenzen. Der tatsächliche Ertrag lag heute bei 3,35 kWh. Dabei war ich mit Solcast in letzter Zeit eigentlich sehr zufrieden.

Hoffentlich gibt es demnächst mal ein paar "verlässliche" Tage, mit denen man dann besser testen kann. In der schwierigen Jahreszeit wird man wahrscheinlich immer deutlichere Abweichungen haben. Ich beobachte das mal weiter und präsentiere gerne demnächst weitere Erkenntnisse. Bei Solcast steht jetzt auch ein Test für das Tuning an und beim DWD Ansatz würde ich demnächst auch auf "Autokorrektur" schalten und sehen, wie das funktioniert.

[Herjemine]

Hallo Heiko,

heute mal wieder upgedatet ...
was mir aufgefallen ist, die Meldung das moduleDirection und moduleTiltAngle fehlen,
das device konnte ich im Room nicht wie sonst per Link aufruffen,
von daher wäre es schön wenn zu dem Hinweis welches reading zu setzten ist

Please specify the module Direction with "set SMASolarForecast moduleDirection"

entweder das Device aufrufbar wäre, oder gleich die möglichen Werte angezeigt würden.
In der Beschreibung stand noch das default Werte verwendet werden.

Gruß Hermann

[DS_Starter]

Hallo miteinander,

ich habe das Modul intensiv erweitert um Multistrings zu unterstützen.
Das ist jetzt der Fall.
Die neue Version liegt wieder im contrib.

Durch die Multistring Unterstützung haben sich alle Setter moduleArea, moduleDirection, moduleEfficiency, moduleTiltAngle inhaltlich verändert und sind erneut auszuführen.

Nach Update und Restart wird euch das Modul auffordern, alle verwendeten Strings mit

       set <> inverterStrings

einzugeben. Ihr könnt eine beliebige Anzahl an Strings eingeben die alle an dem Inverter angeschlossen sind den ihr mit currentInverterDev definiert (habt). Also zum Beispiel:

      set <> inverterStrings Süddach,Ost,Garage

Dann müsst ihr die Setter moduleArea, moduleDirection, moduleEfficiency, moduleTiltAngle durchkonfigurieren. Hier gebt ihr jeweils die Stringnamen als Schlüssel an. Zum Beispiel für moduleDirection:

      set <> moduleDirection Süddach=S Ost=E Garage=NW

Die jeweiligen möglichen Werte stehen in der commandref bzw. werden ja bei der Auswahl des Setters angezeigt.
Gleichzeitig werden Plausi-Prüfungen durchgeführt. Die Ausschriften bitte beachten die kommen sollten.

Wenn alles durchkonfiguriert ist, kann man sich seine fertige Konfiguration anschauen mit:

     get <> stringConfig

Dabei wird ebenfalls eine Konfigurationsprüfung durchgeführt und das Ergebnis mit angezeigt.
Mit verbose 5 werden die Parameter bzgl. Forecast für jeden konfigurierten String und als Summe im Log ausgegeben.

@Hermann, deine Frage/Anregung habe ich mit berücksichtigt.
Hoffe das alles so passt und ich nichts übersehen habe. Habe einigen Aufwand in Tests gesteckt, aber ihr wißt ja wie das manchmal so ist ... 

LG,
Heiko

[DS_Starter]

@jual, ich habe bei mir auch verschiedene Devices definiert und beobachte insgesamt das Verhalten/Ergebnis. Manchmal stimmt es sehr gut überein, manchmal ziemlich daneben, wobei sich bei Devices mit Autokorrektur die Vorhersage recht schnell anpasst.
Vermutlich werde ich auch noch den Sonnenstand über ein Astro Device mit integrieren. Aber das warte ich erstmal ab bis ich mehr Überblick habe.

Ich habe beobachtet, dass wenn der Himmel mal aufreißt sofort ein viel höherer Ertrag zu beobachten ist gegenüber dem Forecast, wohingegen es ziemlich gut passt wenn sich die Bewölkung so entwickelt wie vom DWD vorhergesagt.

Perspektivisch will ich die SolCast API mit integrieren und verspreche mit da eigentlich recht viel davon.
Na mal schauen.

[ch.eick]

Ich habe beobachtet, dass wenn der Himmel mal aufreißt sofort ein viel höherer Ertrag zu beobachten ist gegenüber dem Forecast, wohingegen es ziemlich gut passt wenn sich die Bewölkung so entwickelt wie vom DWD vorhergesagt.

Das ist ein schöner Zugewinn, für mich kommt es darauf an, dass die Grundprognose stimmt. Meistens kann man dann erkennen, dass die Realität mal drüber und mal drunter liegt, jedoch passen fast immer die Flächen, rein optisch, ineinander, also passt die Gesamtleistung recht gut. Vor Deiner Autokorrektur erhoffe ich mir, dass die Gesamtprognose sich dann etwas mehr zur Realität verschiebt und variabler ist als ein fester Faktor.

Den fixen Faktor habe ich bei Solar_forecast() bisher noch gar nicht in Verwendung, weil es sehr oft schon extrem gut passt. Wie bereits schon geschrieben liege ich bei einem Fenster von 0,8 bis 1,2  .

Es ist sicher in dem anderen Thread schon gefragt worden, nach welchem Algorithmus versuchst Du die Autokorrektur zu implementieren?

VG
   Christian

[ch.eick]

Hallo Heiko,
ich habe jetzt auch auf die letzte Version aktualisiert und schaue mal, wie es bei drei Ausrichtungen nun passt.
Weiterhin teste ich ohne Autokorrektur, um die Basis Werte mit Solar_forecast() zu vergleichen.
Da Du jetzt nach meiner Beobachtung alles von Solar_forecast() übernommen hast sollten die Werte ja fast identisch sein. Das wäre ein ganz tolles Ergebnis und würde mich sehr freuen. Vielen Dank schon mal dafür.

Mit ist nun bereits folgendes Aufgefallen:
- Für die Ausrichtung hast Du E,SE,S,... verwendet. Hier fände ich die Winkel besser, ohne jetzt überprüft zu haben, wie groß die Abweichung ist.
  Bei der Winkel Korrektur wirst Du doch sicher von den Buchstaben in Winkel umsetzen müssen. Für die nicht Techniker wäre natürlich beides Wahlweise das Optimum.
  Für meinen Vergleich hätte das keine Relevanz, da ich mit dem Haus exakt im Winkel stehe.

- Bei mehreren Ausrichtungen sind oft auch mehrere Inverter im Spiel, so wie es bei mir auch bald der fall sein wird. Da können natürlich auch verschiedene Wirkungsgrade auftreten.
  Um das abzubilden hatte ich mich damals entschieden den Forecast mit in das WR Device zu schreiben. Dies ist aber Geschmacksache und lässt sich ja mit einem zweiten Forecast
  Device beheben.

Generell möchte ich nochmals sagen, dass Du einen excelenten Job gemacht hast.

VG
   Christian

[ch.eick]

Ich habe da noch eine Frage

Code Auswählen Erweitern


currentInverterDev PV_Anlage_1 pv=Total_DC_Power_(sumOfAllPVInputs):W etoday=Daily_yield:kWh
Today_Hour10_PVforecast 93 Wh
Today_Hour10_PVreal 139370 Wh   <<<< ist das so richtig, oder habe ich da ein Problem bei der Konfiguration?

Ich musste DC_Power nehmen, da der Plenticore den Speicher im DC Bereich angeschlossen hat. Auf der AC Seite wird deshalb die Speicher Leistung mit rein gerechnet.
Als Referenzwert für die Realität sollte das ansonsten ja passen, abgesehen von den Wandlerverlusten.

Müsste dann für die Autokorrektur auch jeder String separat definiert werden?

[DS_Starter]

Hallo Christian,

ziemlich viele Fragen ..

Es ist sicher in dem anderen Thread schon gefragt worden, nach welchem Algorithmus versuchst Du die Autokorrektur zu implementieren?

Es wird für jede Stunde des Tages jeweils die Abweichung zwischen Forecast und Ist aus den vergangenen Tagen X ermitellt, daraus ein Durchschnitt errechnet und auf die Forecast für morgen angewendet. X ist per Attr zwischen 1 und 31 Tagen einstellbar (31 default). Weiterhin ist der max. Faktor der täglichen Anpassung begrenzt und kann auch durch Attr eingestellt werden (default 0.5).

Da Du jetzt nach meiner Beobachtung alles von Solar_forecast() übernommen hast sollten die Werte ja fast identisch sein

Naja, stimmt nicht wirklich. Momentan verwende ich die Formel 1 aus der Vergehensweise gemäß http://www.ing-büro-junge.de/html/photovoltaik.html, d.h. über die Wirkungsgrade. Du benutzt die dort angegebene Formel 2 welche nicht Wirkungsgrad sondern Modulleistung und Anzahl benutzt. Dazu kommen dann noch die diversen Korrekturfaktoren.
Hier wäre bei mir noch das Astro Device einzubinden (evtl.).
Evtl. stelle ich auch auf Formel 2 um, mal schauen.

Für die Ausrichtung hast Du E,SE,S,... verwendet. Hier fände ich die Winkel besser, ohne jetzt überprüft zu haben, wie groß die Abweichung ist.
  Bei der Winkel Korrektur wirst Du doch sicher von den Buchstaben in Winkel umsetzen müssen.

Winkel gehen nicht, da ich das Flächendiagram aus http://www.ing-büro-junge.de/html/photovoltaik.html für die Berücksichtigung der Modul-Ausrichtung benutze. Das arbeitet mit den Himmelsrichtungen.

Bei mehreren Ausrichtungen sind oft auch mehrere Inverter im Spiel

Das Modul geht von einem Inverter für alle Strings aus. Wenn man mehrere Inverter hat, muss man etoday / pv in einem Dummy zusammenfassen und diese Angaben dann in currentInverterDev hinterlegen.

<<<< ist das so richtig, oder habe ich da ein Problem bei der Konfiguration?

Ob das richtig ist weiß ich nicht. Du mußt schauen ob die Hinterlegung für etoday passt. Dort wird die Tageserzeugung angegeben. Sie beginnt 00:00 mit 0 und steigt dann natürlich kontinuierlich hoch über den Tag.
Das Modul errechnet dann über die Differenz den Anteil der Erzeugung für jede Stunde.

Müsste dann für die Autokorrektur auch jeder String separat definiert werden?

Nein, hier wird die Gesamtanlage betrachtet.

Die Hauptcrux ist noch eine evtl. Umstellung von Formel 1 auf Formel 2 und die Integration des Astro Devices.
Die Formel 2 gefällt mir ehrlich gesagt besser weil man die Wirkungsgrade nicht kennen muß. Dort geht zwar noch eine Performance Ratio (PR) ein, aber die hast du überhaupt nicht benutzt. Geht wahrscheinlich irgendwo mit unter. 

Grüße,
Heiko

[EinEinfach]

Vermutlich werde ich auch noch den Sonnenstand über ein Astro Device mit integrieren

Das wird mir vermutlich helfen, denn aktuell habe ich im Forecast Device ab 17:00 eine Ertragsprognose und Real tut sich nichts, weil die Sonne schon untergegangen ist

Code Auswählen Erweitern

17 => pvreal: 0, pvforecast: 127

[ch.eick]

Das wird mir vermutlich helfen, denn aktuell habe ich im Forecast Device ab 17:00 eine Ertragsprognose und Real tut sich nichts, weil die Sonne schon untergegangen ist

Code Auswählen Erweitern

17 => pvreal: 0, pvforecast: 127

Das könntest Du testen, wenn Du parallel das Solar_forecast() mit einbaust. Weiter vorne hatte ich geschrieben, wie man die readings zusätzlich in 76_SolarForecast.pm reinschreiben kann.
In dem verwendeten Solar_Plain() wird der Sonnenstand in der Winkelberechnung verwendet.
Ich mache nur eine Prognose von 7-20 Uhr, was dem gesamten Sommer Fenster entspricht. Im Winter kommt die Funktion dann in einen ungültigen Bereich und bringt dadurch die Prognose gegen 0.
Im Moment ergeben sich somit nur Werte zwischen 9 und 17 Uhr.

[ch.eick]

Die Hauptcrux ist noch eine evtl. Umstellung von Formel 1 auf Formel 2 und die Integration des Astro Devices.
Die Formel 2 gefällt mir ehrlich gesagt besser weil man die Wirkungsgrade nicht kennen muß. Dort geht zwar noch eine Performance Ratio (PR) ein, aber die hast du überhaupt nicht benutzt. Geht wahrscheinlich irgendwo mit unter. 

Die Performance Ratio (PR) steckt in meinem "forecast_factor 1", der fix auf alle Berechnungen angewendet wird. Das wird jedoch nur benötigt, wenn die Prognose Kurve generell zu hoch oder -niedrig ist, was bei mir weder im Sommer noch jetzt im Winter notwendig war. Man könnte den Faktor natürlich auch je nach Jahreszeit verändern, was dann im PV_Schedule Device erfolgen könnte.

VG
   Christian

[DS_Starter]

Hallo zusammen,

ich habe das Modul nun auf eine andere Berechnung umgestellt die sich auf die installierte Leistung der Strings bezieht,
nicht wie bisher auf die Wirkungsgrade.

Dadurch sind die Setter moduleEfficiency und inverterEfficiency entfallen. Die Readings können gelöscht werden mit:

      deleteReading <name> moduleEfficiency
      deleteReading <name> inverterEfficiency
    

Hinzugekommen ist der Setter modulePeakString.
An dieser Stelle tragt ihr die Leistung des jeweiligen Strings in kWp ein.
Wenn ihr zum Beispiel 19 Module a 270W (=5130W Peak = 5.13 kWp) in einem String mit Südlage installiert habt, würdet ihr setzen:

      set <> moduleDirection Süddach=S
      set <> modulePeakString Süddach=5.13

Das ist nun um einiges einfacher als die Wirkungsgrade zusammenzutragen.
Den neuen Setter müsst ihr natürlich wieder ausführen.

Die Version liegt im contrib.
Download + Restart

Code Auswählen Erweitern

"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"

Grüße,
Heiko

[Mumpitz]

Hallo zusammen,

ich habe das Modul nun auf eine andere Berechnung umgestellt die sich auf die installierte Leistung der Strings bezieht,
nicht wie bisher auf die Wirkungsgrade.

Besten Dank, ich habe bereits umgestellt. Leider sind die Werte für morgen so schlecht das ich diese nicht zeigen mag 

Läuft perfekt, danke!