Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Moin Wzut,

konntest du dich schonmal mit der Erweiterung der Grafik um den neuen Teil "consumption" befassen ?

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

Wzut

Ich stehe da ehrlich gesagt etwas auf dem Schlauch.

Zitat@Wzut, die Verbrauchsvorhersage könnte jetzt auch in die Balkengrafik aufgenommen werden. In der nextHours gibt es bereits  den Schlüssel confc dafür. In die History müsste ich ihn noch einbauen wenn du soweit bist.

Das wäre dann eine vierte Auswahl Möglichkeit bei beam1/2Content ?
Wenn ja : wie soll die neue Auswahl heissen ? einfach nur  consumption ?
In der History Tabelle entspricht dies ja dem realen Verbrauch unter dem Key Namen con ?
OK, z.Z. ist schon vorbereitet zu den heutigen $val1 , $val2 & $val3 noch ein $val4 zu nutzen, das klappt schon mal aus dem Stand für con
Nun müsste ich aber wissen unter welchen Key ist es im hash ? auch confc ?
Und warum musst du das noch in History einbauen, con ist doch schon drin - oder willst du wirklich das geschätzte als History haben um zu sehen wie gut die Schätzung war ?

Je länger ich das oben lese um so unsicherer werde ich, denn beim Forecast nehmen wir ja den geschätzen Wert mit in die Vergangenheit.
Das finde ich aber inzwischen etwas unlogisch - ok für dich ist es ein Check über die Güte der Vorhersage.
Für mich wäre aber eine Grafik interessant, die zum einen die geschätzte Zukunft zeigt, aber bei den History Hours nach dem Adenauer Prinzip arbeitet :
( was interessiert mich mein Geschwätz von gestern )
und als History die echten Daten zeigt.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

#722
Zitat
Das wäre dann eine vierte Auswahl Möglichkeit bei beam1/2Content ?
Wenn ja : wie soll die neue Auswahl heissen ? einfach nur  consumption ?
Ja, einfach nur consumption. Zur Abgrenzung gibt es ja schon gridconsumption für den Netzbezug.

Zitat
Nun müsste ich aber wissen unter welchen Key ist es im hash ? auch confc ?
Und warum musst du das noch in History einbauen, con ist doch schon drin - oder willst du wirklich das geschätzte als History haben um zu sehen wie gut die Schätzung war ?
Edit:
Der Key con im pvHistory Hash für den Hausverbrauch in der Vergangenheit.

... oder willst du wirklich das geschätzte als History haben um zu sehen wie gut die Schätzung war ?
Ja, genau. Deswegen muss ich confc in pvHistory noch reinbringen.

Im NextHours Hash gibt es den Key confc der diese Info für die kommenden Stunden beinhaltet, aber du verwendest ja Circular in der Grafik. Möglicherweise reicht NextHours für diesen Zweck.

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

DS_Starter

Hallo zusammen,

im contrib liegt eine neue V 0.43.0.
Ich habe an der Consumerplanung weitergearbeitet.
Jetzt wird eine reale Planung durchgeführt und Readings mit den Planungsergebnissen für jeden registrierten Consumer unter Berücksichtigung seiner Parameter erstellt. Diese sehen etwas so aus:


consumer01      name='Warmwasser Umwälzpumpe mit Energiemessung' state='off' planningstate='planned'
consumer01_planned_start 2021-05-09 13:00:00
consumer01_planned_stop 2021-05-09 20:00:00


Die Planung wird einmal am Tag erstellt. Sobald ein neuer Tag beginnt, wird eine erneute Planung durchgeführt.
Es werden zur Zeit nur erstmal diese Planungsdaten errechnet. Tatsächliche Schaltvorgänge finden noch nicht statt.
Ihr könnt aber schonmal schauen inwieweit bei euch diese Planung plausibel ist.

Der Setter "reset" ist auch erweitert. Man kann nun einzelne Tage aus der pvHistory löschen (falls sich dort mal unsinnige Werte eingeschlichen haben) und man kann die Planungsdaten aller Verbraucher oder eines einzelnen Verbrauchers zurücksetzen mit "reset consumerPlanning ...".
Das bietet sich an, wenn man mehrmals am Tag eine Einplanung ausführen will wenn der davor eingeplante Lauf eines Verbauchers abgeschlossen war.
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

Wzut

Zitat von: DS_Starter am 09 Mai 2021, 19:27:20
Ja, einfach nur consumption. nfc in pvHistory noch reinbringen.
-- snipp --
Im NextHours Hash gibt es den Key confc der diese Info für die kommenden Stunden beinhaltet, aber du verwendest ja Circular in der Grafik.
a. dann kannst consumption schon jetzt als vierte Auswahl bei den beam1/2Content hinzufügen ( wird z.Z. als 0 gewertet)

b. CircularVal wir nur für die aktuelle Stunde benutzt, echte Zukunft verwendet NextHoursVal,  z.Z. ist das halt nur pvforcast

Wir haben dann zukünftig zwei Werte die nach vorne schauen (pvforcast & confc + Wetter) und vier + Wetter in der Vergangenheit.

Im nächsten Schritt müssten wir dann wohl langsam die consumer Icons wiederbeleben ... :)     
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Zitata. dann kannst consumption schon jetzt als vierte Auswahl bei den beam1/2Content hinzufügen ( wird z.Z. als 0 gewertet)
Dann baue ich das Attr beim nächsten Release mit ein.

Zitat
b. CircularVal wir nur für die aktuelle Stunde benutzt, echte Zukunft verwendet NextHoursVal,  z.Z. ist das halt nur pvforcast
Im nextHours ist es schon drin. Bekommst du mit

    NexthoursVal ($hash, "<nextHour>", "confc",  0)

In pvHistory muss ich es dann noch einbauen.

ZitatIm nächsten Schritt müssten wir dann wohl langsam die consumer Icons wiederbeleben ... :)     
Jepp, dauert nicht mehr lange.  :)
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

DS_Starter

In meinem contrib liegt die V.044.0.
Mit dieser V werden die Verbraucher nun auch real entsprechend ihrer Planungsdaten ein und ausgeschaltet, sofern man die Schlüssel on bzw. off in den Cunsumer Attributen angegeben hat.
Die Einschaltung geschieht innerhalb des Planungszeitraums wenn ein Ünerschuß vorhanden ist.

@Wzut ...

es gibt jetzt den Wert "consumptionForecast" im Attr "beamXContent".
Die Schlüssel "confc" gibt es nun in pvHistory für die historischen Verbrauchsvorhersagen und in nextHours für die Zukunft.

Du bekommst sie mit

  NexthoursVal ($hash, <hour>, "confc", 0)                bzw.
  HistoryVal ($hash, <day>,  <hour>, "confc", 0)

Damit solltest du in der Lage sein die Grafik zu ergänzen.

Für die Consumerplanung gibt des einen Consumer-Hash (get ... valConsumerMaster) und zur Abfrage im Programm ein:

  ConsumerVal ($hash, <Consumer-Nummer>, $key, $def)

Die angegebenen Icons für die Consumer bekommst du mit:

  ConsumerVal ($hash, <Consumer-Nummer>, "icon", "")

Die Planungsdaten mit:

  ConsumerVal ($hash, <Consumer-Nummer>, "planswitchon", "")
  ConsumerVal ($hash, <Consumer-Nummer>, "planswitchoff", "")

Grüße,
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

Wzut

der erste Schritt ist relativ einfach, da jetzt nur vier mal confc in den Ring geworfen werden muss um eine Anzeige zu bekommen :
*************** sub forecastGraphic {
*** 3527,3532 ****
--- 3527,3533 ----
        $val1 = HistoryVal ($hash, $hfcg->{0}{day_str}, $hfcg->{0}{time_str}, "pvfc",  0);
        $val2 = HistoryVal ($hash, $hfcg->{0}{day_str}, $hfcg->{0}{time_str}, "pvrl",  0);
        $val3 = HistoryVal ($hash, $hfcg->{0}{day_str}, $hfcg->{0}{time_str}, "gcons", 0);
+       $val4 = HistoryVal ($hash, $hfcg->{0}{day_str}, $hfcg->{0}{time_str}, "confc", 0);
 

*************** sub forecastGraphic {
*** 3535,3540 ****
--- 3536,3542 ----
        $val1  = CircularVal ($hash, $hfcg->{0}{time_str}, "pvfc",  0);
        $val2  = CircularVal ($hash, $hfcg->{0}{time_str}, "pvrl",  0);
        $val3  = CircularVal ($hash, $hfcg->{0}{time_str}, "gcons", 0);
+       $val4  = CircularVal ($hash, $hfcg->{0}{time_str}, "confc", 0);

 
************** sub forecastGraphic {
*** 3630,3635 ****
--- 3632,3638 ----
                $val1                = HistoryVal ($hash, $ds, $hfcg->{$i}{time_str}, "pvfc",  0);
                $val2                = HistoryVal ($hash, $ds, $hfcg->{$i}{time_str}, "pvrl",  0);
                $val3                = HistoryVal ($hash, $ds, $hfcg->{$i}{time_str}, "gcons", 0);
+               $val4                = HistoryVal ($hash, $ds, $hfcg->{$i}{time_str}, "confc", 0);

************** sub forecastGraphic {
*** 3642,3647 ****
--- 3645,3651 ----
 
        if (defined($nh)) {
            $val1                = NexthoursVal ($hash, 'NextHour'.$nh, "pvforecast",    0);
+           $val4                = NexthoursVal ($hash, 'NextHour'.$nh, "confc",    0);


die Icon Anzeige wird vermutlich etwas aufwändiger, besonders da jetzt ein alter Bug bei mir wieder da ist :
Die Balken nutzen die vorgegebene Höhe nicht aus :(
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Moin Wzut,

Zitat$val4  = CircularVal ($hash, $hfcg->{0}{time_str}, "confc", 0);
Wird nichts, wiel ich den Wert im History  und Nexthours drin habe. Reicht das oder brauchst du es im Circular ebenfalls ?
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

DS_Starter

#729
Ich habe die Ergänzung der Grafik übernommen und auch Circular noch ergänzt damit alles funktioniert.
Liegt in meinem contrib.

ACHTUNG: Im Attributen beamXContent wurde forecast in pvForecast und real in pvReal umbenannt.

Damit ist der Inhalt eindeutig unterscheidbar.
Müsst ihr ggf. neu setzen.


@Wzut,
nur als Hinweis, wenn du Unix Timestamps in Zeitstrings (wie sie hier verwendet werden) und zurück wandeln willst, gibt es die beiden Routinen zur Nutzung:

timestampToTimestring
timestringToTimestamp

Die wirst du vermutlich brauchen wenn du die Consumer Plandaten in die Grafik einbaust.
Denn die Plandaten bekommst du ja immer als Unix Timestamp:

  ConsumerVal ($hash, <Consumer-Nummer>, "planswitchon", "")
  ConsumerVal ($hash, <Consumer-Nummer>, "planswitchoff", "")

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

Wzut

na das wird schon irgendwie werden :)
Ich bin erst einmal froh das Problem mit den zu kleinen Balken gefunden zu haben :
Wie der Platz ausgenutzt wird hängt ganz entscheident von $maxVal bzw. $maxCon ab.
Dadurch das nun wesentlich mehr Werte als früher berechnet werden kann es vorkommen das maxVal sich an einem Wert bindet der später gar nicht angezeigt wird. D.h. die Berechnung erfolgt jetzt zu früh, das werd ich jetzt zuerst fixen, da für die Darstellung der Verbrauchs Icons genau dieser Platz so wichtig ist.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

#731
Guten Morgen,

ich hoffe alle hatten einen schönen Feiertag.
Ich habe die interne Datenverarbeitung für die Wechselrichterdaten etwas umgearbietet.
Dadurch hoffe ich dass die vereinzelt gelieferten unsinnigen Werte eliminiert werden oder schlimmstenfalls sich nur mal in einer Stunde einnisten und nicht den ganzen Tag in Mitleidenschaft ziehen.

Liegt im contrib.

Hinweis: Macht das Update am Anfang einer Stunde damit die aktuelle Stunde wegen der internen Umstellung nicht invalidiert wird !
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

DS_Starter

#732
Hallo zusammen,

ich habe eine Frage an die Nutzer von Batteriesystemen.
Ich bin gerade dabei die in die Batterie geladene/entladene Energie (total) zu implementieren wie von Michael in #682
angeregt.

Dabei ist mir folgende Fragestellung durch den Kopf gegangen.
Die in einer Zeiteinheit geladene Energie der Batterie dürfte nicht in die Verbauchsvorhersage eingehen aus zwei Gründen:

  1. in den aktuellen Verbrauch geht bereits die aktuelle Entladeleistung der Batterie ein. Der aktuelle Verbrauch ist
      wiederum die Grundlage für die spätere Verbrauchsvorhersage (jetzt schon implementiert)
  2. die in einer Zeiteinheit geladene Energie ist kein Verbrauch in dem Sinne, da sie erst beim Entladevorgang als
      verbrauchte Energie in den Hausverbrauch eingeht (jetzt schon implementiert)

Meiner Meinung nach würde sich die Erfassung der totalen geladenen/entladenen Energie nur dazu eignen um zum Beispiel die
in einer Stunde geladenen/entladenen Energie zu bestimmen und daraus Readings zu generieren wie es jetzt mit Today_HourXX_GridFeedIn, Today_HourXX_GridConsumption geschieht.

Wie seht ihr das ?

VG,
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

dk3572

Zitat von: DS_Starter am 15 Mai 2021, 11:00:07
Hallo zusammen,

ich habe eine Frage an die Nutzer von Batteriesystemen.
Ich bin gerade dabei die in die Batterie geladene/entladene Energie (total) zu implementieren wie von Michael in #682
angeregt.

Dabei ist mir folgende Fragestellung durch den Kopf gegangen.
Die in einer Zeiteinheit geladene Energie der Batterie dürfte nicht in die Verbauchsvorhersage eingehen aus zwei Gründen:

  1. in den aktuellen Verbrauch geht bereits die aktuelle Entladeleistung der Batterie ein. Der aktuelle Verbrauch ist
      wiederum die Grundlage für die spätere Verbrauchsvorhersage (jetzt schon implementiert)
  2. die in einer Zeiteinheit geladene Energie ist kein Verbrauch in dem Sinne, da sie erst beim Entladevorgang als
      verbrauchte Energie in den Hausverbrauch eingeht (jetzt schon implementiert)

Meiner Meinung nach würde sich die Erfassung der totalen geladenen/entladenen Energie nur dazu eignen um zum Beispiel die
in einer Stunde geladenen/entladenen Energie zu bestimmen und daraus Readings zu generieren wie es jetzt mit Today_HourXX_GridFeedIn, Today_HourXX_GridConsumption geschieht.

Wie seht ihr das ?

VG,
Heiko

Hallo Heiko,

musste mir den Text zwar 3 mal durchlesen,  ???
stimme dir aber zu.  ;)

Schönes Wochenende und VG Dieter

DS_Starter

Danke fürs mitdenken Dieter  :)

Ebenfalls ein schönes WE,
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