Prognosekorrektur durch Hinterlegung einer Maximalprognose

[RienSte]

Hi @wiggal

mir kam die Idee zur Hinterlegung einer monatlichen maximalen Prognosekurve, auf die die Tagesprognose dann gekappt wird. Ich habe in den Übergangs und Wintermonaten das Problem, dass meine Anlage durch einen nahen Wald ziemlich abrupt beschattet wird. D.h. meine Prognose stimmt hinten und vorne nicht, da diese die Verschattung nicht wiederspiegelt. Zeitweise kommt morgens auch ein Berg dazwischen :-)

Man könnte das korrigieren, in dem man monatsweise eine maximal mögliche Prognose in der config hinterlegt. Müsste in der config auch halbwegs übersichtlich abzubilden sein, bspw:

[Prognoselimit]
; Stunden = 7, 8, 9, 10 , 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
; Prognose_Limit_XX ==> XX = Monat (zB 10 = Oktober)
Prognose_Limt_10 = 0, 500, 1000, 2000, 3000, 4000, 4000, 3500, 1000, 500, 400, 0, 0, 0

Und die Beträge dann mit einer min-Funktion mit der Tagesprognose verrechnen (d.h. der kleinere Betrag wird als Prognose übernommen).

Schöne Grüße,
Stephan

[wiggal]

OK, lass es und durchdenken bzw. diskutieren:

mir kam die Idee zur Hinterlegung einer monatlichen maximalen Prognosekurve, auf die die Tagesprognose dann gekappt wird. Ich habe in den Übergangs und Wintermonaten das Problem, dass meine Anlage durch einen nahen Wald ziemlich abrupt beschattet wird. D.h. meine Prognose stimmt hinten und vorne nicht, da diese die Verschattung nicht wiederspiegelt. Zeitweise kommt morgens auch ein Berg dazwischen :-)

Welche Probleme entstehen durch die falsche Prognose, die du nicht durch die vorhandenen Mittel lösen kannst?

Hier einige Gedanken, die mir auf die schnelle kommen, wenn wir das einbauen sollten:

• Wenn man das für jeden Monat in der Config hinterlegen will, wird das ganz schön unübersichtlich.
• Wann sollten wir die Begrenzung anbringen, bei der Erzeugung der weatherData.json, oder bei allen Berechnungen, die auf die Prognose zurückgreifen?
• Beachtung der Sommer- bzw. Winterzeit (weil wir das gerade hatten).
  .....

[RienSte]

Naja, im Grunde bräuchtest du ja nur pro Monat einen Datenvektor mit den 12 Stunden. Sind zwar in Summe 12 * 12 Einträge, aber das einzutragen macht man ja nur einmal. Ich würde - in meiner Situation - einfach den besten Tag im jeweiligen Monat als Referenz nehmen und das hat dann im Grunde ja bis in alle Ewigkeit Gültigkeit. Außer uns sägt jemand den Wald um :-)

Man kanns auch flexibel machen, wenn für einen Monat eine Max-Prognose hinterlegt ist, dann wird die verrechnet. Falls nicht, dann nicht. Das verschlankt die config, bringt aber extra Aufwand im Code. Dann würde ich in meinem Fall für die Monate 10-02 so eine Maximalkurve hinterlegen. Für 05-09 nicht, die wären dann unbeeinflusst.

z.B.:

Prognose_Limit_Monate = 10, ... n
Prognose_Limit_10 = x, y, z, ...
Prognose_Limit_n = x, y, z, ...

Die Verrechnung würde ich nur bei Generieren der WeatherData.json machen. Man bekommt die Prognose vom Wetterdienst, limitiert diese auf die Werte per config, fertig. Muss man imho nicht alle 5 Minuten machen. Das reicht beim Abrufen der Prognose.

Sommer / Winterzeit ist ein guter Punkt. Wie geht dein Tool generell damit um? Hast du da vom Wochenende grad Erfahrungen? Das betrifft ja generell die Prognose wie es aktuell implementiert ist auch.

EDIT: auf die Frage welche Probleme entstehen... meine Prognose stimmt bei mir aktuell bis ~09:00 und ab ~ 14:00 überhaupt nicht mehr, das hat mir aktuell schon den ein oder anderen Tag meine BattVollUm so falsch berechnet, dass der Akku nicht voll wurde. Ich könnte das natürlich auch mit der monatsabhängigen BattVollUm regeln (mach ich grad auch). Aber generell würde ich es einfach schön finden, wenn meine Prognose halbwegs zur Realität passt.

Ich hab das Thema ja schon öfter mal aufgegriffen und ich finde, das wäre eine recht einfach Möglichkeit, wie sich alle Nutzer ihre Prognose ein bisschen hin-tunen können.

[wiggal]

Sommer / Winterzeit ist ein guter Punkt. Wie geht dein Tool generell damit um? Hast du da vom Wochenende grad Erfahrungen? Das betrifft ja generell die Prognose wie es aktuell implementiert ist auch.

Um die Zeitumstellung muss ich mich normal nicht kümmern, das geht mit den Prognosediensten automatisch

[wiggal]

Welche Prognose verwendest du?

Hast du dir schon mal bei solarprognose.de die "Leistungseinschränkungen für das Modulfeld" angesehen?
Wenn ich es richtig verstanden habe, ist das genau das, was du einstellen möchtest, oder?
Trotzdem kann ich das mal in #76 aufnehmen, wenn du möchtest.

Hier ein Ausschnitt aus dem Menü:

[RienSte]

Ja, das ist im Grunde genau das, was ich mir vorgestellt habe. Wobei mir absolute Werte lieber wären, da ich die einfach direkt aus dem Log vom Fronius ziehen könnte und nicht erst in Relation zur Maximalleistung setzen müsste.

Ich bin mir noch nicht ganz sicher, bei welchem Anbieter ich verbleibe. Aktuell verfolge ich forecast.solar und solarprognose.de ... beide liefern bei mir gleich gute bzw. schlechte Ergebnisse :-) leider geht in Österreich kein mosmix (bei solarprognose), der soll wohl ganz gut sein. Mit solcast.au habe ich recht oft Fehlermeldungen bekommen, drum hab ich das nicht weiter verwendet.

[wiggal]

Wie gesagt kann ich das mal in #76 aufnehmen, wenn du möchtest.

IDEE:
Da ich gerade ein Lastprofil aus der PV_Daten.sqlite Datenbank erzeuge, wäre es aus meine Sicht auch möglich, die Maximalwerte der Produktion für jede Stunde aus z.B. den letzten 30 Tagen zu lesen und bei der Prognose als Maximalwert zu verwenden.

Schalter: Maximalwertbegrenzung = 0/1
evtl. Aufschlag aus der config, oder auf 100 aufrunden...

[RienSte]

Wie gesagt kann ich das mal in #76 aufnehmen, wenn du möchtest.

Ja bitte, danke :-)

IDEE: Da ich gerade ein Lastprofil aus der PV_Daten.sqlite Datenbank erzeuge, wäre es aus meine Sicht auch möglich, die Maximalwerte der Produktion für jede Stunde aus z.B. den letzten 30 Tagen zu lesen und bei der Prognose als Maximalwert zu verwenden.

Schalter: Maximalwertbegrenzung = 0/1 evtl. Aufschlag aus der config, oder auf 100 aufrunden...

Deine Idee hört sich auch gut an.... evtl. würde das schon reichen. Wir könnten ja damit mal starten und sehen, wie es sich verhält 👍

[wiggal]

Wenn du die DB mit einem Tool (z.B. DB Browser for SQLite) öffnest, kannst du ja mal folgenden SQL ausführen, dann siehst du die Ergebnisse:

WITH stundenwerte AS (
            SELECT
                strftime('%Y-%m-%d %H:00:00', Zeitpunkt) AS volle_stunde,
                MAX(DC_Produktion) AS max_dcproduktion
            FROM
                pv_daten
            WHERE
                Zeitpunkt >= datetime('now', '-30 days')
            GROUP BY
                strftime('%Y-%m-%d %H:00:00', Zeitpunkt)
        ),
        differenzen AS (
            SELECT
                strftime('%H:00:00',a.volle_stunde) AS Stunde,
                a.max_dcproduktion - COALESCE(b.max_dcproduktion, 0) AS DCProduktion
            FROM
                stundenwerte a
            LEFT JOIN
                stundenwerte b ON a.volle_stunde = datetime(b.volle_stunde, '+1 hour')
            WHERE
                DCProduktion < 20000
        )
SELECT
Stunde, MAX(DCProduktion) AS maximalwert
FROM differenzen
GROUP BY Stunde
ORDER BY Stunde

[wiggal]

In die WeatherDataProvider2.py für forecast.solar habe ich jetz mal einen Prototypen eingearbeitet.

Ergänzung in CONFIG/weather.ini

[env]
; 0 = aus, 1 = ein: damit wird die Prognose auf den Höchsten Wert der Produktion der letzten 30 Tage begrenzt
MaximalPrognosebegrenzung = 0

[wiggal]

mit print_level = 2 gibt er nun als Debug die ersetzten Werte aus

[RienSte]

Cool, probier ich gleich aus.

Sehe ich das richtig, das hast du direkt in den main eingebaut? Also pullen reicht?

[RienSte]

Ja, ich hab auch grad überlegt, wie man die Funktion noch persönlich "tunen" kann.
Mir sind zwei Sachen eingefallen: Länge des Beobachtungszeitraumes (aktuell 35 Tage, richtig?) und eine Skalierung (Faktor) auf die ermittelten Werte.

Wobei mir der Beobachtungszeitraum als der wichtigere Parameter erscheint.

Aber das kann man ja notfalls auch einfach selber in der functions.py ändern. Meine SQL Zeit liegt ca. 20-25 Jahre zurück.... sehe ich das richtig, dass ich das Statement in Zeile 100 ändern muss?

Zeitpunkt => datetime('now', '-35 days')

[wiggal]

ja genau, -35 das sind die Tage zurück. kann ich auch noch einen Parameter machen.

[RienSte]

Ausgezeichnet, danke.

[wiggal]

hab mal schnell die Parameter

MaxProGrenz_Faktor = 1
MaxProGrenz_Dayback = 35

eingebaut

[wiggal]

Was mich mal interessieren würde, wie gut so Machine Learning Tools in dem Zusammenhang sind.
Werd mich mal daran setzen, und das zu Verbesserung der Prognosen mal ausprobieren, weis aber nicht ob das klappt, was bringt und wie lange es dauert.

[wiggal]

Das mit den Maximalwerten ist nicht zielführend, oder?

[RienSte]

Hi, doch doch aktuell sieht das ganz gut aus :-) von mir aus kann das so drin bleiben.
Mal sehen, wie es sich verhält wenn die Tage wieder länger werden. Dann hat man ja wahrscheinlich den umgekehrten Fall und die Prognose ist dann ja tendenziell immer "zu schlecht".

[wiggal]

Wie viele Tage gehst du denn zurück, bzw. hast du einen Faktor angebracht?

Es steckt aktuell ja noch das Problem mit der Zeitumstellung drin. Das heißt, vor dem 27.10. sind die Werte ja um eine Stunde versetzt und damit zu hoch.

[RienSte]

Aktuell habe ich 14 Tage eingestellt, das passt recht gut. Faktor habe ich nicht, nein. Es passt echt gut, so wie's aktuell konfiguriert ist.