Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

DS_Starter

#2805
Hallo Andreas,

die Consumption (CO) Forecast wird aus den vergangenen Werten, die in der pvHistory gespeichert werden, in die Zukunft geschätzt. Das hat zur zum Teil mit etotal, also der summarischen Total-Erzeugung des WR zu tun.

Der Verbrauch wird folgendermaßen berechnet und gespeichert:

  Consumption = PVreal-Erzeugung - Netzeinspeisung + Netzbezug - Batterie-In + Batterie-Out

Hier ist es entscheidend, dass die Angaben in currentBatteryDev, currentInverterDev, currentMeterDev stimmen.
Solltest du dort vorher einen Fehler eingebaut und jetzt vielleicht korrigiert haben, hilft ein Löschen der pvHistory wie kask schon geschrieben hat. Sie baut sich dann neu auf.
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

cwagner

Hi DS_Starter,
Glückwunsch zu diesem professionellen Modul, das ich jetzt mit großer Freude in der Familie  schon auf zwei Anlagen im Einsatz habe. Für die manuelle Steuerung von Verbrauchern, die ich digital noch nicht im Griff habe, liebe ich übrigens die Readings NextHours_SumN_PVforecast.

Bislang wurden alle Wünsche, die ich so im Laufe der Entwicklung hatte, quasi von selbst erfüllt. Einer blieb bislang offen. Ich würde gerne zur längerfristigen Analyse die "Selbstkritik" des Programms in der Überschrift "Abweichung" als Reading haben, um bei längerer Abwesenheit das logen zu können und dann abzuklopfen auf Optimierungspotentiale. Ob das möglich ist?

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

DS_Starter

Hallo Christian,

es gibt bereits ein Reading dafür. Es heißt Today_PVdeviation.
Es wird aber erst nach Sonnenuntergang erstellt und kurz nach Mitternacht wieder gelöscht. Zu diesem Zeitpunkt sind die Abweichungen für den Tag manifestiert.
Das logge ich ebenfalls um die Tendenzen zu verfolgen. Das SVG sieht dann so aus wie im Anhang.
Am 19.Juli hatte ich mal wieder an meiner PV-Anlage gearbeitet, was man sofort im Diagramm sieht.  ;)

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

cwagner

Hallo Heiko,
ich sach doch, meine Wünsche wurden alle "ohne Bestellung" erfüllt. Vielen Dank für die schnelle Antwort und da mache ich mir jetzt auch mal 'nen Graphen.

Herzliche Grüße
Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

kask

Müsste der Today_PVdeviation nicht eigentlich invertiert ausgegeben werden.
Jetzt ist es so, das wenn der forcast größer dem real wert ist dann ist der Wert positiv.
Laut Nomenklatur wäre es aber die Photovoltaikabweichung. Und diese wäre eigentlich geringer also Null also -x.x%.

Will nicht mosern, nur anmerken.

DS_Starter

#2810
Das Thema hatten wir schonmal glaube ich.
Ist halt die Frage der Perspektive. Zur Zeit wird die Abweichung aus der Perspektive der Vorhersage betrachtet.
So ist auch der Text im Mouse-Over über der Abweichung in der Grafik.

Positive Abweichung -> Vorhersage mehr als Real
Negative Abweichung -> weniger vorhergesagt als real produziert

Man könnte das Reading statt Today_PVdeviation auch Today_PVFCdeviation nennen.
Ich glaube das ist Geschmacksache.

Aber wenn die Nutzer es als besser empfinden, kann ich das Reading gerne umbenennen. Will hier nicht auf meiner Sichtweise beharren.


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

kask

Ja umbennen is ja doof wenn man schon volle Trends hat. Unter Umständen.
M.M. lass es wie es ist.
Ist halt ein bischen verwirrend für meine Denkweise. Aber diese ist auch nicht als Gottesansicht zu betrachten.

Aber mir ist noch etwas aufgefallen. Die Daten von "ForecastSolar-API" laufen daneben. Die Werte wurden unterirdisch schlecht. Dann hatte ich die pvHistory resettet (neues Spiel neues Glück).
Und die API liefert aber immer noch schlechte Werte. Hat das einer von euch auch so in letzter Zeit beobachtet?

Zudem ist mir aufgefallen das der DWD Forecast bei schlechtem Wetter besser funktioniert als die SolCastAPI Vorhersage.
Die "ForecastSolar-API" war Anfangs, als diese neu drinne war im Contrib, genauer. Ähnlich der SolCastAPI. Aber jetzt ist diese eigentlich unbrauchbar was diese liefert bei mir.
Daten/Parameter sind in allen 3 Forecast "Devices" gleich, bis auf die Vorhersageabfrage halt.


DS_Starter

#2812
ZitatAber mir ist noch etwas aufgefallen. Die Daten von "ForecastSolar-API" laufen daneben. Die Werte wurden unterirdisch schlecht. Dann hatte ich die pvHistory resettet (neues Spiel neues Glück).
Und die API liefert aber immer noch schlechte Werte. Hat das einer von euch auch so in letzter Zeit beobachtet?
Ja, kann ich bestätigen. Auf meinem Testsystem lasse ich alle drei API's parallel laufen um deren Qualität zu vergleichen.
Die ForecastSolar-API basiert nach deren Angaben auf Wetterdaten des DWD und anderen. Deswegen war ich bisher der Meinung, keine von der Bewölkung abhängige Korrektur einzuschalten weil diese Dinge von der API beachtet werden sollten. Also habe ich bei mir pvCorrectionFactor_Auto=on_simple verwendet.
Das habe ich bei mir jetzt auf pvCorrectionFactor_Auto=on_complex umgeschaltet und schaue mal wie es damit aussieht.
Als die API integriert wurde, hatten wir eine stabile Wetterlage. Mal sehen wie diese API mit Aprilwetter klarkommt.

ZitatZudem ist mir aufgefallen das der DWD Forecast bei schlechtem Wetter besser funktioniert als die SolCastAPI Vorhersage.
Das kann ich bei mir nicht bestätigen.
Gestern hatte die SolCastAPI nur 0,4!! Prozent Tagesabweichung (bei dem aktuellen Aprilwetter), die DWD API lag gestern bei -6,3 % Tagesabweichung was aber auch ein absolut toller Wert ist bei der Wetterlage.
Die DWD API nutze ich mit pvCorrectionFactor_Auto=on_complex, die SolCastAPI mit pvCorrectionFactor_Auto=on_simple.

Also die beiden sind bei mir top, nur die ForecastSolar-API lässt zur Zeit wirklich zu wünschen übrig.
Mals sehen wie es sich nach der Umstellung auf pvCorrectionFactor_Auto=on_complex ausspielt.
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

stefanru

Hi,

ja bei der ForecastSolar-API ist mir auch aufgefallen dass da etwas seltsam ist. Heute geht es bei mir mit -13%.
Aber was mir schon aufgefallen ist, dass sie sich sehr stark ändert im Tagesverlauf.
Also morgens 6 Uhr steht so gut wie kein Ertrag.
Etwas später schaue ich wieder und die Vorhersage ist total anders und hat auf einmal eine Menge Ertrag.

Ich schalte auch mal complex on an. Mal sehen was das bewirkt.

Danke und Gruß,
Stefan


DS_Starter

ZitatEtwas später schaue ich wieder und die Vorhersage ist total anders und hat auf einmal eine Menge Ertrag.
Der Lieferant aktualisiert alle 15 Minuten seine Vorhersagedaten.
Ihr könnt euch die gelieferten Rohdaten (egal von welcher API) anschauen mit:

 get ... solApiData


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

kask

Zur Info: Ich habe alle 3 auf pvCorrectionFactor_Auto=on_complex stehen.

DS_Starter

Als kleine Hilfestellung .... falls man die bisher gesammelten/berechneten Korrekturfaktoren löschen will, macht man das mit dem Kommando:

 set ... reset pvCorrection

Die pvHistory zu löschen ist für diesen Zweck ungeeignet.
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

Christian83

Zitat von: DS_Starter am 01 August 2023, 21:19:12Als kleine Hilfestellung .... falls man die bisher gesammelten/berechneten Korrekturfaktoren löschen will, macht man das mit dem Kommando:

 set ... reset pvCorrection

Die pvHistory zu löschen ist für diesen Zweck ungeeignet.

Das habe ich gemacht. Mit get ... ForecastQualities sehe ich trotzdem noch Faktoren.
Oder hat das damit nichts zu tun?

DS_Starter

ZitatDas habe ich gemacht. Mit get ... ForecastQualities sehe ich trotzdem noch Faktoren.
Oder hat das damit nichts zu tun?
get ... ForecastQualities schaut in die Zukunft.
Wenn jetzt für eine neue (zukünftige) Stunde ein Faktor berechnet wird, dann beginnt die Berechnung bei "0".
Die Löschung der Werte mit "reset" wird im Log mit verbose 3 protokolliert. Man sieht dann was gelöscht wird.
Die gespeicherten Korrekturwerte sind mit get ... pvCircular abrufbar. Dort die Schlüssel corr und quality.
(Sehe gerade dass ich die Hilfe anpassen muß)
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

Christian83

Zitat von: DS_Starter am 02 August 2023, 09:05:58
ZitatDas habe ich gemacht. Mit get ... ForecastQualities sehe ich trotzdem noch Faktoren.
Oder hat das damit nichts zu tun?
get ... ForecastQualities schaut in die Zukunft.
Wenn jetzt für eine neue (zukünftige) Stunde ein Faktor berechnet wird, dann beginnt die Berechnung bei "0".
Die Löschung der Werte mit "reset" wird im Log mit verbose 3 protokolliert. Man sieht dann was gelöscht wird.
Die gespeicherten Korrekturwerte sind mit get ... pvCircular abrufbar. Dort die Schlüssel corr und quality.
(Sehe gerade dass ich die Hilfe anpassen muß)

verbose 3 und dann steht das in Event Monitor
2023-08-02 09:08:32 SolarForecast Forecast2 reset pvCorrection

dann ist erstmal nichts passiert.

erst wenn ich über die Kommandozeile noch das "cached" hinzugefügt habe (über die Auswahlliste geht es nicht) dann kommt:
2023-08-02 09:08:52 SolarForecast Forecast2 reset pvCorrection cached

und im Log:
2023.08.02 09:08:52 3: Forecast2 - all stored PV correction factors / SolCast percentile from pvCircular and pvHistory deleted

jetzt sind die Werte auch weg.