Leistungsprognose für Wechselrichter

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

Vorheriges Thema - Nächstes Thema

DS_Starter

ZitatBleibt die Fragestellung, welche Information "relevanter "im Kontext der Graphik ist - echter Hausverbrauch (CO) oder der Netzimport (GCO)?
Korrekt. Der Grafik ist es egal, wenn der inhaltliche Wert so bleiben soll wie er ist, müsste ich CO konsequenterweise umstellen auf GCO.  Alternativ kann CO weiterhin so heißen, müßte aber intern auf das Reading Current_Consumption (bisher Current_GridConsumption) umgestellt werden.

Ich persönlich tendiere inzwischen zur internen Umstellung auf Current_Consumption weil die anderen Details im Grafikheader
(CO =>   aktuell    0 W   nächste 4h:    0 Wh   Rest heute:    0 Wh   morgen:    0 Wh) sich auf Forecastwerte des Hausverbrauchs beziehen. Die werden aktuell noch nicht gefüllt, aber werden zukünftig eine Abschätzung des Hausverbrauchs (nächste 4h etc.) darstellen um zu entscheiden wann es sich lohnt größere Verbraucher zu planen.
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

dk3572

Hallo,
ist es eigentlich auch angedacht einen evtl. vorhandenen Batteriespeicher mit einzubeziehen?
VG Dieter

DS_Starter

Hallo Dieter,

ich persönlich habe keinen, aber wenn es Datenquellen/Module bzw. Devices mit entsprechenden Readings gibt spricht eigentlich nichts dagegen.
Ihr müsstet mir dann nur kurz aufzeigen in welcher Form die Einbindung passieren soll.
Ich brauche eine gewisse Vorstellung was du/ihr gern als Inhalt sehen möchtet.

LG
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

papa

Zumindest für die Berechnung des Hausverbrauchs ist der Speicher schon wichtig, da er ja auch Energie aufnimmt. Aber ich bin mir auch nicht sicher, wie kompliziert man das alles braucht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

jual

Zunächst einmal herzlichen Dank an die stetige Weiterentwicklung des Moduls und die vielen neuen Möglichkeiten, die mit dem Modul umgesetzt werden können.

Aktuell habe ich ein kleineres Problem, bei dem ich mir nicht sicher bin, ob es da schonmal eine Lösung gab und ich nur zu ungeschickt bin, diese zu finden.

Ich nutzen einen SMA Wechselrichter und damit auch das Modul SMAInverter. Der Wechselrichter hat immer mal wieder die dumme Eigenart, einen völlig falschen Wert auszugeben (4xxxxxxxxx). Hier gab es ja mal grundsätzlich einen Lösungsvorschlag, wie der Wert beim loggen in der DB ausgeschlossen werden kann. Nun hatte ich aber schon zweimal den Fall, dass dieser Wert auch in den Readings TodayHourXX_PVReal auftaucht und damit auch die Grafik komplett kaputt macht. Gibt es hier einen Lösungsansatz, wie das vermieden werden kann?

Dann hätte ich noch einen weiteren Punkt als Anregung/Diskussion zur Handhabung der Automatik. Seit einigen Tagen teste ich die Automatik und parallel dazu teste ich auch noch den Service von Solcast. Mittlerweile glaube ich aber, dass die hier entwickelte Modullösung wesentlich besser geeignet ist und oft auch näher an der Realität liegt. Auch wenn die Aussagen zur Automatik bei mir noch nicht wirklich valide sind, habe ich den Eindruck, dass insbesondere bei sehr wechselnden Wetterverhältnissen die Prognosen stark von der Wirklichkeit abweichen. Wird sich natürlich nie vermeiden lassen, trotzdem möchte ich mal folgende Idee in die Runde werfen.

Würde es evtl. Sinn machen, die historischen Werte nicht alleine für sich zu betrachten, sondern die tatsächlichen Rahmenbedingungen wie Wolken, Regen usw. mit zu berücksichtigen? Also irgend ein Algorithmus der die Abweichungen bei schlechten Wetter evtl. höher bewertet als die Abweichungen bei gutem Wetter. Wenn also schönstes Wetter vorhergesagt wird, dass dann die Abweichungen bei schönem Wetter in der Historie stärker einfliessen und wenn schlechtes oder sehr wechselhaftes Wetter vorhergesagt wird, dass dann die historischen Werte, bei denen ähnliches Wetter war, stärker berücksichtigt werden? (geht wahrscheinlich schon ein wenig in das Thema Mustererkennung / KI). Ob damit noch bessere Werte erzielbar wären, ist mir auch nicht wirklich klar aber vielleicht ist das ja eine Anregung für weitere Verbesserungen des Moduls.

DS_Starter

@papa:
Stimmt, BattIn & BattOut wären im Ladefall vom Hausverbrauch abzuziehen und im Entladefall dem Hausverbrauch hinzuzufügen. Das SMAInvertermodul müsste solche Daten liefern, kenne es aber nicht aus eigener Erfahrung.
Habt ihr/du Beispiele für solche Datenquellen ?   

@jual:
Zitat
Hier gab es ja mal grundsätzlich einen Lösungsvorschlag, wie der Wert beim loggen in der DB ausgeschlossen werden kann. Nun hatte ich aber schon zweimal den Fall, dass dieser Wert auch in den Readings TodayHourXX_PVReal auftaucht und damit auch die Grafik komplett kaputt macht. Gibt es hier einen Lösungsansatz, wie das vermieden werden kann?
Bei DbLog habe ich eine Logik über valueFn eingebaut, meinst du diese Möglichkeit ?
Zur Zeit gibt es im Modul keine Prüfung auf tendenziell "abstruse" Werte.
Vorschlag: baue dir in dem Invertermodul ein usereading welches auf derart hohe Abweichungen filtert und gib dieses Reading im Modul an. Das sollte das Problem beheben.

Zitat
Würde es evtl. Sinn machen, die historischen Werte nicht alleine für sich zu betrachten, sondern die tatsächlichen Rahmenbedingungen wie Wolken, Regen usw. mit zu berücksichtigen? Also irgend ein Algorithmus der die Abweichungen bei schlechten Wetter evtl. höher bewertet als die Abweichungen bei gutem Wetter. Wenn also schönstes Wetter vorhergesagt wird, dass dann die Abweichungen bei schönem Wetter in der Historie stärker einfliessen und wenn schlechtes oder sehr wechselhaftes Wetter vorhergesagt wird, dass dann die historischen Werte, bei denen ähnliches Wetter war, stärker berücksichtigt werden? (geht wahrscheinlich schon ein wenig in das Thema Mustererkennung / KI). Ob damit noch bessere Werte erzielbar wären, ist mir auch nicht wirklich klar aber vielleicht ist das ja eine Anregung für weitere Verbesserungen des Moduls.
Da hast du absolut Recht und eine solche Erweiterung der Logik über eine "Wetterwichtung" würde sicherlich die Genauigkeit sehr erhöhen. Ein Modell für die Umsetzung dafür habe ich allerdings (noch) nicht. Wer sich damit oder KI schon etwas näher befasst hat kann sich gerne einbringen. Würde mich freuen.
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

@jual, ich glaube ich habe eine erste Idee für eine Wetterführung bei der Automatic. Dazu werde ich ein paar Werte in die pvHistory zusätzlich einfügen.
Wenn ich soweit bin stelle ich eine neue V zur Verfügung die du/ihr erstmal übernehmen müsstet. Ich brauche etwas Vorlauf damit Werte zum Test eines ersten Ansatzes gespeichert 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

dk3572

Zitat von: DS_Starter am 07 April 2021, 16:07:14
@papa:
Stimmt, BattIn & BattOut wären im Ladefall vom Hausverbrauch abzuziehen und im Entladefall dem Hausverbrauch hinzuzufügen. Das SMAInvertermodul müsste solche Daten liefern, kenne es aber nicht aus eigener Erfahrung.
Habt ihr/du Beispiele für solche Datenquellen ?   

Sowas?

   FVERSION   76_SMAInverter.pm:v2.14.1-s23909/2021-03-07
   HOST       192.1xxxxx
   INTERVAL   60
   LASTUPDATE 07.04.2021 / 16:59:39
   MODEL      SBS3.7-1VL-10 (Sunny Boy Storage 3.7)
   NAME       SMA_Wechselrichter_Bat
   NR         431
   PASS       xxxxxx
   STATE      <font color="White">Batterieladung: -0.05 kW </font><br>Batterieladezustand: 51.0 %
   TYPE       SMAInverter
   HELPER:
     DEFAULT_TARGET_SERIAL xxxxx
     DEFAULT_TARGET_SUSYID xxxxx
     FAULTEDCYCLES 0
     INTERVAL   60
     MAXBYTES   300
     MYSERIALNUMBER xxxxxx
     MYSUSYID   233
     PACKAGE    main
     PKT_ID     32769
     VERSION    2.14.1
   Helper:
     DBLOG:
       bat_loadtoday:
         logdb:
           TIME       1617807519.32685
           VALUE      3.25
       bat_loadtotal:
         logdb:
           TIME       1617807519.32685
           VALUE      500.409
       etoday:
         logdb:
           TIME       1617807459.00302
           VALUE      2.761
       etotal:
         logdb:
           TIME       1617807459.00302
           VALUE      395.48
       power_in:
         logdb:
           TIME       1617807579.23926
           VALUE      54
       power_out:
         logdb:
           TIME       1617807459.00302
           VALUE      0
       total_pac:
         logdb:
           TIME       1617807579.23926
           VALUE      -0.054
   READINGS:
     2021-04-07 16:59:39   background_processing_time 0.6460
     2021-04-07 16:59:39   bat_loadtoday   3.25
     2021-04-07 16:59:39   bat_loadtotal   500.409
     2021-04-07 16:59:39   chargestatus    51
     2021-04-07 16:59:39   device_class    Batterie-Wechselrichter
     2021-04-07 16:59:39   device_name     SN: xxxxx
     2021-04-07 16:59:39   device_status   Ok
     2021-04-07 16:59:39   device_type     SBS3.7-1VL-10 (Sunny Boy Storage 3.7)
     2021-04-07 16:59:39   etoday          2.761
     2021-04-07 16:59:39   etotal          395.48
     2021-04-07 16:59:39   feed-in_time    1554.51
     2021-04-07 16:59:39   grid_freq       50.01
     2021-04-07 16:59:39   gridrelay_status geschlossen
     2021-04-07 16:59:39   inverter_processing_time 0.6139
     2021-04-07 16:59:39   modulstate      normal
     2021-04-07 16:59:39   operation_time  3910.35
     2021-04-07 16:59:39   opertime_start  07.04.2021 06:16:36
     2021-04-07 16:59:39   opertime_stop   07.04.2021 20:38:33
     2021-04-07 16:59:39   pac_max_phase_1 3680
     2021-04-07 16:59:39   pac_max_phase_2 0
     2021-04-07 16:59:39   pac_max_phase_3 0
     2021-04-07 16:59:39   phase_1_iac     -0.001
     2021-04-07 16:59:39   phase_1_pac     0.000
     2021-04-07 16:59:39   phase_1_uac     0.00
     2021-04-07 16:59:39   phase_2_iac     -0.001
     2021-04-07 16:59:39   phase_2_pac     -0.054
     2021-04-07 16:59:39   phase_2_uac     234.33
     2021-04-07 16:59:39   phase_3_iac     -0.001
     2021-04-07 16:59:39   phase_3_pac     0.000
     2021-04-07 16:59:39   phase_3_uac     0.00
     2021-04-07 16:59:39   power_in        54
     2021-04-07 16:59:39   power_out       0
     2021-04-07 16:59:39   serial_number   xxxxxx
     2021-04-07 16:59:39   state           -0.054
     2021-04-07 16:59:39   susyid          361 - SN: xxxxx
     2021-04-07 16:59:39   total_pac       -0.054
Attributes:
   DbLogExclude .*
   DbLogInclude bat_loadtoday,bat_loadtotal,etoday,etotal,total_pac,power_in,power_out
   SBFSpotComp 1
   alias      SMA Wechselrichter Batterie
   detail-level 2
   disable    0
   event-on-change-reading bat_loadtoday,bat_loadtotal,etoday,etotal,total_pac,power_in,power_out,chargestatus
   event-on-update-reading state,modulstate
   icon       measure_power
   interval   60
   offset     0
   room       Photovoltaik
   showproctime 1
   suppressSleep 1
   target-serial 3xxxxxx
   target-susyid 361
   timeout    90

DS_Starter

#533
Naja, diese beiden Readings:

     2021-04-07 16:59:39   power_in        54
     2021-04-07 16:59:39   power_out       0

Könnten die Werte für laden/entladen (Leistung in W) sein. Kannst du das bestätigen Dieter ?
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

dk3572

Zitat von: DS_Starter am 07 April 2021, 17:18:04
Naja, diese beiden Readings:

     2021-04-07 16:59:39   power_in        54
     2021-04-07 16:59:39   power_out       0

Könnten die Werte für laden/entladen (Leistung in W) sein. Kannst du das bestätigen Dieter ?

das kann ich zu 100% bestätigen  ;)

DS_Starter

Danke  :)

Im contrib liegt eine neue V. Übernehmt sie bitte in Vorbereitung der nächsten Schritte.
Das CO in der Grafik ist nun der aktuelle Verbrauch des Hauses und nicht nur der Netzbezug.
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

papa

Zitat von: DS_Starter am 07 April 2021, 16:07:14
@papa:
Stimmt, BattIn & BattOut wären im Ladefall vom Hausverbrauch abzuziehen und im Entladefall dem Hausverbrauch hinzuzufügen. Das SMAInvertermodul müsste solche Daten liefern, kenne es aber nicht aus eigener Erfahrung.
Habt ihr/du Beispiele für solche Datenquellen ?   
Beim Plenticore habe ich
     2021-04-07 21:36:06   Actual_battery_current 0.00
     2021-04-07 21:36:06   Battery_voltage 205.13

und rechne mir das dann selber aus. Das kommt mit verschiedenen anderen Energiewerten in einen Dummy.
PV_1:(Act_state_of_charge|Actual_battery_current|Total_DC_Power_|Total_DC_PV_Energy_|Total_yield|Total_home_consumption).* {
  if( $EVTPART0 eq "Actual_battery_current:" ) {
    fhem("setreading Energy bat_power ". floor($EVTPART1 * ReadingsNum('PV_1','Battery_voltage','0') * -1));
  }

bat_power ist dann positiv, wenn geladen wird, und negativ, wenn entladen wird.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

DS_Starter

Danke, ich werde im nächsten Release die Batteriewerte mit anbieten zu integrieren und ein identisches Verfahren wie bei gcon und gfeedin etablieren.
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

dk3572

#538
Zitat von: DS_Starter am 07 April 2021, 16:07:14
@jual:Bei DbLog habe ich eine Logik über valueFn eingebaut, meinst du diese Möglichkeit ?
Zur Zeit gibt es im Modul keine Prüfung auf tendenziell "abstruse" Werte.
Vorschlag: baue dir in dem Invertermodul ein usereading welches auf derart hohe Abweichungen filtert und gib dieses Reading im Modul an. Das sollte das Problem beheben.

Hallo Heiko und jual,
kaum wird drüber berichtet, habe ich heute bei mir auch die Ausreißer in der Grafik.
Wie könnte das userReadind aussehen?
Ich habe mehrere Beispiele gefunden, allerdings wird hier entweder ein Ersatzwert od. 0 gesetzt.
Das wäre ja auch nicht richtig.
Danke und VG Dieter

Bsp.:
userReadings Differenz difference {abs(ReadingsVal($name,"etotal",0))},
Temp {sprintf "%.1f", ReadingsVal($name,"Differenz",0)<100 ? ReadingsVal($name,"etotal",0) : "0"}


Edit:
Habe es jetzt mal so versucht:
etoday_fc:modulstate.* {
                         my $hour = (localtime(time))[2];
                         if (ReadingsVal($name, "gridrelay_status", "") eq "geschlossen" || $hour > 12 || ReadingsVal($name, "etoday", "") <100000) {
                           ReadingsVal($name, "etoday", 0);
                         }
                         else {
   
                           0;
                         }
                       }


Kommt ja eigentlich nur in der Nacht vor.

papa

Hab mit der neuesten Version folgendes im Log
2021.04.08 08:21:39 1: stacktrace:
2021.04.08 08:21:39 1:     main::__ANON__                      called by ./FHEM/76_SolarForecast.pm (1789)
2021.04.08 08:21:39 1:     FHEM::SolarForecast::_transferMeterValues called by ./FHEM/76_SolarForecast.pm (1303)
2021.04.08 08:21:39 1:     FHEM::SolarForecast::centralTask    called by fhem.pl (3379)
2021.04.08 08:21:39 1:     main::HandleTimeout                 called by fhem.pl (695)

MeterDev ist
currentMeterDev     PowerMeter gcon=power:W contotal=total_consumption:Wh gfeedin=-gcon feedtotal=total_feed:Wh
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire