Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

ch.eick

Hallo zusammen,
einige von Euch verwenden im WR_ctl ja keine DbRep reports für den gester/Vormonat/... , dafür habe ich eine kleine Änderung vorgenommen, damit in der uiTable nicht mehr das "null" angezeigt wird.
In dieser Funktion bitte an zwei Stellen etwas korrigieren, damit einfach nichts zurück gegeben wird.
Hier die kurz Fassung...
sub WR_ctl_Format {
< snip >

    if ($period eq "_Qx" and $QuarterPrevious ne "null") {
        return $QuarterPrevious;
    }

< snip >

  return ;
}

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moinsen,
ich habe mich mal an einen Umbau der dwd_load() MySQL Procedure herangesetzt.

Bei der Procedure hat mich die Laufzeit gestört, da ich gerne jede Stunde ein Update laufen lasse, was im WR_ctl über das LogDBRep_PV_KI_Prognose DbRep Device gestartet wird. Dabei geht der MySQL Docker Container auf 100% CPU, was leider bei einer längeren Laufzeit zu eventuellem stocken im FHEM führt, wenn es auf der selben CPU läuft.

Nach kurzen Nachdenken ist mir eingefallen, dass sich ja die historischen Daten nicht innerhalb eines Tages verändern werden. Verwendet werden ja hierbei Daten mit folgendem TIMESTAMP, also 1-2 Jahre zurück, um einen änlichen Zeitraum zum Vergleichen zu haben.
AND ( TIMESTAMP > DATE_ADD(@date,INTERVAL -30 DAY)
OR    TIMESTAMP > DATE_ADD(@date,INTERVAL -(365+30) DAY)
  AND TIMESTAMP < DATE_ADD(@date,INTERVAL -(365-30) DAY)
OR    TIMESTAMP > DATE_ADD(@date,INTERVAL -(2*365+30) DAY)
  AND TIMESTAMP < DATE_ADD(@date,INTERVAL -(2*365-30) DAY)
    )

Dazu kommen dann fc0 und fc1, wodurch ich dies nun über ein Parameter Wort aufgeteilt habe.
call dwd_load_new('full',curdate(),'none');
call dwd_load_new('update',curdate(),'none');
call dwd_load_new('update_yield_only',curdate(),'none');
- full wäre der komplette Lauf wie bisher
- update aktualisiert nur fc0 und fc1, sowie den yield von heute
- update_yield_only korrigiert somit nur den aktuellen yield von heute

Somit ergibt sich dann zukünftig die Möglichkeit die dwdfull Tabelle vor der KI_Prognose geziehlt und schneller zu aktualisieren.

Nachts sollte immer ein "full" Lauf erfolgen und jede Stunde würde ein "update" reichen.
Wer dann den aktuellen yield der laufenden Stunde wachsen sehen möchte, der kann das mit "update_yield_only" machen, was dann auch ohne die KI_Prognose das Grafana Diagramm aktualisieren würde.

Laufzeiten im Test bisher mit start um *:03
PV_KI_Prognose done 2024-03-19 12:08:55         ==> 1'14  KI_Prognose
state          done 2024-03-19 12:07:41         ==> 4'40  dwd_load(curdate(),'none')
Laufzeit der neuen dwd_load(<step>,curdate(),'none');
4'50       full

3.062 sec  update
0.062 sec  update_yield_only

Somit könnte man jede Stunde eine Laufzeit von > 4'30 einsparen.
An der Laufzeit der KI_Prognose ändert sich hierbei jedoch nichts.

Ich teste dann mal weiter

VG    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
es ist nun soweit und ich habe die dwd_load Procedure nun ins contrib gestellt.
Auch im WR_ctl hat sich deshalb der Aufruf geändert.
Die Procedure muss natürlich in der MySQL Datenbank ausgetauscht werden.

Kurzbeschreibung der WR_ctl Änderung
< snip >
################################################################################################################
## 2 Start der KI Prognose
## Der Reading Name und das Device werden in LogDBRep_PV_KI_Prognose im executeAfterProc eingestellt
##  "/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.40 192.168.178.40 LogDBRep_PV_KI_Prognose WR_1_ctl Yield_fc"
##
2_KI_Prognose
{if( !([$SELF:state] eq "off")                                           ## DOIF enabled
    and
     (
      ReadingsVal("LogDBRep_PV_KI_Prognose","PV_KI_Prognose","null") eq "done"  ## Die Prognose darf nicht gerade laufen !!!
      or
      ReadingsVal("LogDBRep_PV_KI_Prognose","state","null") eq "initialized"
     )
    and
  (
    ([05:00-22:00] and [:03]                                             ## In der PV-Zeit jede Stunde aktualisieren
    )
    or [$SELF:ui_command_1] eq "2_KI_Prognose"                           ## Hier wird das uiTable select ausgewertet
  )
   ) {

  if ($hour == 5) {
    ::CommandSet(undef, "LogDBRep_PV_KI_Prognose sqlCmd call dwd_load_new('full',curdate(),'none')");
  } else {
    ::CommandSet(undef, "LogDBRep_PV_KI_Prognose sqlCmd call dwd_load_new('update',curdate(),'none')");
  }

  if (AttrVal("$SELF","verbose",0) >=3) {
      Log 3, "$SELF 2_KI_Prognose : Start KI Prognose";
    }

    set_Reading("ui_command_1","---");                                   ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten
                                                                         ## kann das Kommando nicht sofort wiederholt werden
  }
}
< snip >
Durch die Änderung im WR_ctl wird nun um 5 Uhr eine komplett neue dwdfull Tabelle erzeugt und danach nur noch mit update aktualisiert, was um einiges schneller geht.

VG    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin,
das nenn ich mal einen schönen Tag. Das Lastmanagement klappt super zwischen den beiden openWB Ladepunkten.
Du darfst diesen Dateianhang nicht ansehen.
Zwei E-Autos, ein Wirlpool, Heizung und WW, sowie der Hausspeicher in der Mittagszeit.
Du darfst diesen Dateianhang nicht ansehen. 
Autarkie 96 % und Eigenvergrauch 68%
Bei der Autarkie hat die Regelungsträgheit der E-Autos 2 kWh aus dem Netz benötigt,
da ich die Speichernutzung für das E-Auto Laden gesperrt hatte, weil ich auf jedenfall den Speicher voll haben wollte.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick