Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

Wzut

ja klar vermutlich hast du in der sub auch das Reading getauscht, da ich die sub aber immer sofort komplett lösche und gegen meine Version ersetze klappt das jetzt nicht ehr . Ich habe jetzt überall  ThisHour_ durch NextHour00_ ersetzt, (forecast & time) nun scheint es gut zu sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Ich wollte jetzt anfangen umschreiben auf Readings für History, aber irgendwie bin ich zu doof es zu verstehen, mal eine X beliebige Stunde als Beispiel :
Today_Hour16_GridConsumption     0 Wh 2021-03-19 15:59:57
Today_Hour16_PVforecast       2232 Wh 2021-03-19 16:59:57
Today_Hour16_PVreal           3000 Wh 2021-03-19 15:59:57

die Zeitstempel von GridConsumption und PVreal sind for mich logisch, kurz vor Ablauf von Hour16 wurden sie nochmal schnell aktualisiert.
Aber warum wird für diese abgelaufene Stunde PVForcast noch immer eine Stunde lang geändert ?
Oder ist da doch ein ungewollter Versatz von 1 Stunde drin wo einfach nur das falsche Reading beschrieben wird ?   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Zitat
Aber warum wird für diese abgelaufene Stunde PVForcast noch immer eine Stunde lang geändert ?
Oder ist da doch ein ungewollter Versatz von 1 Stunde drin wo einfach nur das falsche Reading beschrieben wird ?   
Für DWD beginnt der Tag mit Stunde 00 nicht Stunde 01, d.h. die Stunde 16 geht beim DWD von 16:00 bis 16:59:59.

Ich habe jetzt auch die Weatherdata Zuordnung gerichtet, sollte nun passen. V 0.15.3 im contrib.
ESXi@NUC+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

Wzut

Zitat von: DS_Starter am 19 März 2021, 19:28:32
die Stunde 16 geht beim DWD von 16:00 bis 16:59:59.
Was für mich direkt greifbar ist und auch so für die X Achsenbeschriftung verwendet wird, warum kann das nicht komplett durch alles der rote Faden sein ?
Wie blickst du da noch durch ?, einmal links rum einmal rechts
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Naja, weil wir ja festgestellt haben dass es leider einen Versatz von 1 Stunde gibt wenn man DWD Forecast und PV ERzeugung übereinander legt. Christian hatte ja bereits auch schon darauf hingewiesen. Irgendeinen Tod muss man halt sterben.

Komm, in userem Alter kriegen wir das doch locker hin  ;D

Um es sich besser merken zu können haben ich in der Hilfe dazu geschrieben wie bei den Gettern der Stundenwert zu interpretieren ist.

 
ESXi@NUC+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

DS_Starter

@Wzut, mein DWD hat aktuell solche Readings bezüglich ww/wwd:


     2021-03-19 21:00:05   fc1_2_Neff      22
     2021-03-19 21:00:05   fc1_2_R101      1.00
     2021-03-19 21:00:05   fc1_2_Rad1h     0.00
     2021-03-19 21:00:05   fc1_2_SunUp     0
     2021-03-19 21:00:05   fc1_2_TTT       -3.80
     2021-03-19 21:00:05   fc1_2_time      02:00
     2021-03-19 21:00:05   fc1_2_ww        0
     2021-03-19 21:00:05   fc1_2_wwd       Bewölkungsentwicklung nicht beobachtet


Für "Bewölkungsentwicklung nicht beobachtet" liefert DWD den ww-Wert 0.
In unserer Matrx ist 0 belegt mit "sonnig".

Haben wir einen Fehler in unserer Wettermatrix ?
ESXi@NUC+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

Wzut

Ha ich wusste doch das es die sonnige Nacht = 100 gibt :)
Spass beiseite, ich habe das ja ins Rennen geworfen in https://forum.fhem.de/index.php/topic,102112.msg1117001.html#msg1117001
schau dir mal die dort verlinkte pdf Datei an. Besonders siginfikantes und nicht signifikantes Wetter, der DWD kennt gar kein "sonnig".
Die ww = 0 nehmen wir als Sonnig weil keine Wolken, aber in der Nacht würde man im Volksmund wohl "sternenklar" sagen.
Vllt müssen wir in dem Punkt umdenken, jetzt würde ich wirklich die ID 100 vergeben und der das simple Halbmond Icon weather_night zuordnen.

 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: DS_Starter am 19 März 2021, 20:10:23
Irgendeinen Tod muss man halt sterben.
Das der DWD für diesen Mist verantwortlich ist ist mir schon klar, nur muß der User unbedingt diesen Tod mitsterben ?
Klar wir können im Modul unseren Index auch mit der dritten Wurzel aus Pi verschlüsselen, aber in dem Moment wo es nach aussen zum User geht in Form von Readings sollte es klar und einfach sein. Ich habe gestern Abend bemägelt das ein Reading in einer Stunde einen anderen Zeitstempel hat, du hast nachgezogen, aber es tanzt noch immer eines aus der Reihe :
Today_Hour07_GridConsumption 1103 Wh 2021-03-20 06:59:41
Today_Hour07_PVforecast        37 Wh 2021-03-20 07:15:42
Today_Hour07_PVreal            48 Wh 2021-03-20 06:59:41 

Um  7:150 Uhr ist Verbrauch & Real abgeschlossen -> 6:59 , aber Forecast schreibt noch in diesen Block -> 7:15
Aus User Sicht ist das keine Vorhersage mehr sondern eine nachträgliche Korrektur.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Moin Wzut,

ZitatVllt müssen wir in dem Punkt umdenken, jetzt würde ich wirklich die ID 100 vergeben und der das simple Halbmond Icon weather_night zuordnen.
Habs angepasst und liegt im contrib nebst neuen getter + minor fixes

Wegen der Timestamps der Readings mach dir keine Sorgen.
Ich ändere die TS sowieso noch um damit sie einen Bezug haben zur richtigen Uhrzeit auf die sie sich beziehen. Das ist für das Logging, insbesondere Datenbank, hilfreich. Aber das kommt ziemlich zum Schlß wenn alles andere soweit steht.
ESXi@NUC+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

DS_Starter

#384
Hallo zusammen,

in meinem contrib liegt die V 0.17.0.
Es gibt ein neues Attribut cloudFactorSlope. Mit einem Schieberegler lässt sich der prozentuale Einfluß der Bewölkung auf die Prognose der PV beeinflussen.
Die Hilfe dazu beschreibt die Auswirkung.

Edit: Jetzt gibt es auch das Attr rainFactorSlope zur Einstellung der prozentualen Berücksichtigung der DWD Regenwahscheinlichkeit.

@Wzut, ich habe einen Fehler in der Grafic sub beseitigt. Jetzt klappt das Attr history_hour von 0 bis -2 ordentlich. Ab -3 sind die Werte falsch, da wird wahrscheinlich das falsche Hash gezogen über die Bedingung.
Vllt. kannst du da mal ansetzen.

LG,
Heiko
ESXi@NUC+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

Wzut

Zitat von: DS_Starter am 20 März 2021, 15:01:51
Jetzt klappt das Attr history_hour von 0 bis -2 ordentlich. Ab -3 sind die Werte falsch
Ich bin stark verwundert das es überhaupt für 2 Stunden stimmt, nachdem ich ja davon ausging der Ringpuffer sei komplett History, du dann aber geschrieben hast nur die aktuelle Stunde und der Rest ist Forecast. D.h. in der jetzigen Form habe ich eigentlich gar keine History Werte, daher wollte ich ja anfangen und auf die TodayHour Readings als History auszuweichen. Sag mir doch einfach welchen Fehler du genau beseitigt hast, sonst fang ich wieder mit diff an und bekomme 1000 Zeilen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Hallo Wzut,

bin mir nich 100%ig sicher, es war wohl das:


Zeile  2117     my $t0 = sprintf('%02d', $t{0}+1); # Index liegt eins höher : 10:00 = Index '11'
Zeile  2124     my $t0 = sprintf('%02d', $t{0}+1);
Zeile 2201      my $ii   = sprintf('%02d',$i+2);
Zeilen 2213/2214/2215  jeweils $jj+1


ZitatIch bin stark verwundert das es überhaupt für 2 Stunden stimmt, nachdem ich ja davon ausging der Ringpuffer sei komplett History, du dann aber geschrieben hast nur die aktuelle Stunde und der Rest ist Forecast.
Ja du hast Recht, war eher Zufall dass -2 noch ging weil zu dem Zeitpunkt offensichtlich noch nicht überschrieben mit den Daten des Folgetages.

Deswegen ist prinzipiell richtig alle aktuellen Werte / zukünftigen Werte aus dem FC-Hash ($data{$hash->{TYPE}}{$name}{pvfc}) zu holen und alles Vergangene aus dem History-Hash ($data{$type}{$name}{pvhist}).

Es gibt inzwischen auch ein nextHours Hash ($data{$type}{$name}{nexthours}). Es enthält alle Werte die sich momentan in den Readings NextHourXX... finden. Kann man sich mit get <> nextHours anschauen.
Diese Readings will ich tendenziell eliminieren weil sie für den User keinen Nutzen bieten und nur für die Modulsteuerung benötigt werden.
ESXi@NUC+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

Wzut

Zitat von: DS_Starter am 20 März 2021, 17:35:26
Diese Readings will ich tendenziell eliminieren weil sie für den User keinen Nutzen bieten und nur für die Modulsteuerung benötigt werden.
Ok, kein Problem. Den nextHours Hash habe ich mir angesehen und würde ihn gern nutzen. Kannst du da ausser time + forcast vllt noch die waether id beipacken ? denn die hole ich jetzt aus dem $hash->{HELPER}{NextHourxx_Weather_id}
Vllt kannst den dann auch mal ganz sterben lassen ?
Gerade beim Wetter bin ich mir ziemlich sicher haben wir jetzt einen Versatz, aber das sollte jetzt nicht Prio 1 sein, viel viel wichtiger wäre es mir die Balken fehlerfrei zu bekommen.
BTW: GridConsumption habe ich jetzt auch mit drin und kann als beam Wert ausgewählt werden.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Ja mach ich. Dann reduzieren sich die Datenquellen. Was wir dan nicht mehr brauchen eliminiere ich auch, klar.

Weather habe ich schon x mal gecheckt und mit DWD Readings verglichen. Differenzen konnte ich nicht mehr erkennen.
Ich mach mich mal an den Einbau der Weather data in diesen Hash. Dann sieht man vllt. wieder mehr durch.
ESXi@NUC+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

DS_Starter

Habe die neue V mit dem ergänzten NextHour Hash hochgeladen.

VG
ESXi@NUC+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