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

EDIT: Bei der Gelegenheit habe ich im WR_1 userreading auch die Trigger noch weiter präzisiert, wodurch ich mir verspreche, dass die berechneten readings besser zusammen passen.
Im Dashboard war mir aufgefallen, das es manchmal zu kleinen Abweichungen gekommen ist. Ich lege das im Wiki ab und Ihr könntet dann das userreading komplett neu setzen.


Hallo zusammen,
Ihr müsst aber bitte mal besser aufpassen :-) Ich habe schon wieder etwas gefunden, was nicht so ganz passt.

Im WR_1 userreading ist eine Berechnung falsch. Das kommt noch aus der ersten Version, bei der es das reading Battery_work_capacity noch nicht gab.
Battery_work_capacity ist bei mir fest auf der Brutto Leistung des Speichers -5% und dieser Wert verändert sich auch nicht wenn man den MinSoc verändert. Somit nehme ich an, dass das fest von Kostal so vorgegeben ist.
Für die Schätzung der nutzbaren Leistung in Wh habe ich nun den MinSoc mit berücksichtigt, anstell wie bisher einen fixen Wert.
Ist nun der Act_state_of_charge <= Battery_MinSOC wird für Actual_Battery_charge_usable_P dann 0 angezeigt.

Actual_Battery_charge_usable_P:[Act_state_of_charge|Battery_MinSOC].* {my $x = (ReadingsVal($NAME,"Battery_work_capacity",0)*(ReadingsVal($NAME,"Act_state_of_charge",0)-ReadingsVal($NAME,"Battery_MinSOC",0))/100);; ($x lt 0)? 0 : round($x,0) },

Bisher habe ich diesen Wert zwar noch nicht für Entscheidungen verwendet, jedoch wird er bei mir im Diagramm angezeigt, damit ich sehen kann wie viel  kWh noch verwendet werden können.
Achtung, die Verluste von DC/AC sind dabei nicht berücksichtigt, es müssen so ca. 10-15 % abgezogen werden.

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

zwölfgang

Hallo Christian,
danke für das herzliche Willkommen, freue mich dass ich als Nutznieser hier teilhaben darf. Bin hier halt noch ganz weit vorne am Anfang.
Ich habe wie im wiki beschrieben die Definitionen genau so verwendet und werde eins ums andere hinzufügen (und versuchen zu verstehen:-))

Ja, die Verbindung und login zum Kostal WR, scheint so weit zu funktionieren, auch der KSEM aktuallisiert die Readings.

Ich habe mal die Dateien mit meinen Definitionen von WR_1 und WR_1_API angehängt, vielleicht siehst du mit einem Blick was zu den unpassenden Zahlen führt.
Schau doch mal bitte bei Gelegenheit drüber. Danke

sonnige Grüßle
Wolfgang

ch.eick

Zitat von: zwölfgang am 20 Juni 2021, 09:19:02
Ich habe mal die Dateien mit meinen Definitionen von WR_1 und WR_1_API angehängt, vielleicht siehst du mit einem Blick was zu den unpassenden Zahlen führt.
Schau doch mal bitte bei Gelegenheit drüber.
Hallo Wolfgang,
die readings im ModBus passen nicht und ich habe in einem anderen Forum gelesen, das man die Register Reihenfolge jetzt verändern kann.
Ich habe mal meine Einstellung angehängt, die ich jedoch nie verändert habe.

Im WR_1_API hat es letzte Woche auch Änderungen gegeben, die Du später noch aktualisieren kannst. https://forum.fhem.de/index.php/topic,114849.msg1162883.html#msg1162883

Gruß
   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

zwölfgang

Hallo Christian,
ich habe soeben nachgeschaut, meine Einstellung im Modbus / Sunspec (TCP) stand auf - "big-endian (ABCD) Sunspec". Habe umgestellt auf "little-endian (CDAB) Standard Modbus" und siehe da, das wars. Das schaut schon mal ganz anders aus. Die Werte passen mit dem was ich vom WR angezeigt wird. Damit kann ich jetzt mal gut weiter machen. Ich werde berichten.
Das userReading habe ich auch gleich angpasst.

Danke dir.

VG
Wolfgang

ch.eick

Zitat von: zwölfgang am 21 Juni 2021, 21:39:59
Meine Einstellung im Modbus / Sunspec (TCP) stand auf - "big-endian (ABCD) Sunspec". Habe umgestellt auf "little-endian (CDAB) Standard Modbus" und siehe da, das wars.
Dann kannst Du nun das bisherige Logging in der DbLog bereinigen und die ganzen falschen Werte löschen.
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

Heute ist mal wieder so ein Tag, wo es knapp werden könnte...
- aber die Prognose trifft es ziemlich genau.
- Die Speichersteuerung kam mit SOC 20 % aus der Nacht und hat aufgrund der Prognose entschieden mal wieder auf 100 % zu laden.

Bei der Verbrauchern habe ich mich nun entschieden die Diagramme in zwei Gruppen aufzuteilen.
- Hauptverbraucher ist alles so ab 800 Wh, also Brunnenpumpe, Wirlpool, Wärmepumpe
- Kleinverbraucher geht dann bis 800 Wh (mit Stacking), also die
   Heizungssteuerung mit Pumpen und KWL, Multimedia, Akkus Laden (Shaun), Gartenkühlschrank und alles was sonst noch an einem Shelly
Durch diese Gruppierung kann man die Skala aufteilen und sieht mehr Details der einzelnen Geräte sehen.

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,
bitte kein update von FHEM starten, da scheint es ein Problem mit dem setreading aus dem HTTPMOD Modul zu geben, das ich für die WR_1_API Abfrage verwende.
Nach dem update ist dann kein login zum Plenticore mehr möglich.

EDIT: Alles wieder gut :-)
  Es lag daran, dass es bei dem update wohl zu einer wiederholten falschen Anmeldung am Plenticore kam und dieser dann den user gesperrt hat.
  Also schaut in diesem Fall bitte auf das reading "auth_me_locked 1" und setzt in diesem Fall auf der Web GUI des Plenticore das Passwort zurück.
  Bitte verwendet in diesem Fall das selbe Passwort, das bisher gesetzt war!
  Anschließend habe ich mit "deletereading WR_1_API auth.*" die Reste der gescheiterten Anmeldung entfernt.
  Eine erneute Abfrage der Statistiken führt automatisch wieder eine Anmeldung durch.
  Mit "get WR_1_API 04_auth_me" kann der Anmeldestatus zusätzlich abgefragt werden und sollte dann wie folgt aussehen.


auth_me_active 1
auth_me_anonymous 0
auth_me_authenticated 1
auth_me_locked 0
auth_me_role USER


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

zwölfgang

Hallo Christian,
ich habe Fehlermeldungen im Logfile und weiß da nicht mehr weiter.

2021.07.11 05:55:00 1: PERL WARNING: Argument "Error evaluating WR_1_API userReading SW_Statistic_OwnCo..." isn't numeric in sprintf at (eval 464067) line 47.   (Fehler kommt im 5 min Takt)
2021.07.11 05:57:00 1: Error evaluating WR_1_API userReading SW_Statistic_OwnConsumptionRate_Day: Illegal division by zero at (eval 464574) line 1.  (Fehler kommt jede Stunde)

Dieser Fehler kommt immer  nachts exakt ab 00:57 Uhr. Sobald die PV wieder Strom produziert verschwindetder Fehler. Das userReading SW_Statistic_OwnConsumptionRate_Day macht scheinbar das Problem. Mir ist dabei aufgefallen dass der WR komplett abschaltet und damit evtl. keine readings mehr aktuallisiert. Die Batterie ist leider immer noch nicht da und vielleicht gibt es da einen Zusammenhang weil die dann auf Eingang drei liefern würde und der WR dann nicht mehr aus geht. (Vermutung)

Wäre schön wenn Du eine Idee dazu hättest.

VG
Wolfgang

ch.eick

Zitat von: zwölfgang am 11 Juli 2021, 10:13:08
Hallo Christian,
ich habe Fehlermeldungen im Logfile und weiß da nicht mehr weiter.

2021.07.11 05:55:00 1: PERL WARNING: Argument "Error evaluating WR_1_API userReading SW_Statistic_OwnCo..." isn't numeric in sprintf at (eval 464067) line 47.   (Fehler kommt im 5 min Takt)
2021.07.11 05:57:00 1: Error evaluating WR_1_API userReading SW_Statistic_OwnConsumptionRate_Day: Illegal division by zero at (eval 464574) line 1.  (Fehler kommt jede Stunde)

Dieser Fehler kommt immer nachts exakt ab 00:57 Uhr. Sobald die PV wieder Strom produziert verschwindet der Fehler. Das userReading SW_Statistic_OwnConsumptionRate_Day macht scheinbar das Problem. Mir ist dabei aufgefallen dass der WR komplett abschaltet und damit evtl. keine readings mehr aktualisiert. Die Batterie ist leider immer noch nicht da und vielleicht gibt es da einen Zusammenhang weil die dann auf Eingang drei liefern würde und der WR dann nicht mehr aus geht. (Vermutung)
Hallo Wolfgang
Okay, den Fall, dass der WR komplett abschaltet habe ich nicht.

Versuche mal die Division durch Null so zu vermeiden.
Ansonsten schau mal bitte ob SW_Statistic_Yield_Day zu dem Zeitpunkt Null ist, dann müssten wir das ansonsten abfangen.
Den Wert müsstest Du zu diesem Zeitpunkt in der Datenbank abfragen.

SW_Statistic_OwnConsumptionRate_Day:SW_Statistic_EnergyHomePvSum_Day.* { round(ReadingsVal("$NAME","SW_Statistic_EnergyHomePvSum_Day"  ,0) / ReadingsVal("$NAME","SW_Statistic_Yield_Day",1)*100,0) },
SW_Statistic_OwnConsumptionRate_Month:SW_Statistic_EnergyHomePvSum_Month.* { round(ReadingsVal("$NAME","SW_Statistic_EnergyHomePvSum_Month"  ,0) / ReadingsVal("$NAME","SW_Statistic_Yield_Month",1)*100,0) },
SW_Statistic_OwnConsumptionRate_Year:SW_Statistic_EnergyHomePvSum_Year.* { round(ReadingsVal("$NAME","SW_Statistic_EnergyHomePvSum_Year"  ,0) / ReadingsVal("$NAME","SW_Statistic_Yield_Year",1)*100,0) },


Gruß
   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,

ich werde in den nächsten zwei Wochen im Flut Katastrophengebiet im Ahrtal im Einsatz sein und somit Eure Anfragen nicht bearbeiten können.
Unter Ahrtal@infinity-staging.de wird Eure Bewerbung für den Katastropheneinsatz entgegen genommen.


Besonderen Dank auch an meinen Arbeitgeber, der diesen Einsatz ermöglicht!

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,
und schon geht es weiter.

Im Photovoltaikforum ist folgendes aufgetaucht.

Sobald der Speicher nicht verwendet wird kommt es zu minimalen Entladungen, die ich im Dashboard mit 10-14 W Entladung ebenfalls bereits gesehen habe.
Ist nun der Speicher bei 100 % SOC angelangt kann man nach einiger Zeit einen leichten Knick im Diagramm sehen und der Speicher wird wiederum auf 100 % nachgeladen.
Dies ist etwas unschön, da gerade in diesem Bereich "gefühlt" ziemlich viel Leistung benötigt wird, um den kleinen letzten Rest in den Speicher zu bekommen.

Aus diesem Grund habe ich bei der externen Speichersteuerung ein weiteres DOELSEIF eingefügt, was bei 100 % SOC eine MaxSOC Begrenzung auf 95 % durchführt.
Dadurch wird das Nachladen auf 100 % vermieden und ich werde mal beobachten, wieviel denn über den Tag verloren geht. Verloren ist hierbei natürlich nicht richtig, da ja die 10-15 W ins Haus gehen :-)

Das Nachladen kann man im Diagramm bei 17:20 Uhr an der gelben Linie sehen.

Aktualisiert: 2021 08 06

################################################################################################################
## 11 Der Speicher ist voll geladen. Hier wird das ständige nachladen auf 100 % vermieden.
##
DOELSEIF
( [WR_1:Solar_Calculation_fc0_day] > [WR_1_Speicher_1_ExternTrigger:SpeicherMaxSOC_fc1_Limit] and          ## 1) sobald viel Leistung erwartet wird und der Speicher voll ist
   [WR_1:Act_state_of_charge] == 100 or                                                                     ##    den MaxSOC wieder reduzieren, damit nicht immer nachgeladen wird
  ([WR_1_Speicher_1_ExternTrigger:SpeicherMaxSOC_Actual] == 95 and                                          ## 2) oder das Nachladen gestoppt wurde
   [WR_1:Act_state_of_charge] <  98  and                                                                    ##    und der SOC unte 98 % gefallen ist
   [{sunset_abs("HORIZON=+8.0",-7200,"15:00","21:00")}]) )                                                  ##    zwei Stunden vor Sonnenuntergang eventuell wieder nachladen

  {
   if ([WR_1:Act_state_of_charge] < 98) {
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOC_Actual 100");                   ## Eventuell noch mal nachladen
     if (AttrVal("$SELF","verbose",0) >=3) {
       Log 3, "$SELF cmd_11 : Battery_ExternControl_MaxSocRel auf 100 % nachladen";
     };
   } else {
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOC_Actual 95");
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherCmdRepeatRunning 1");                  ## Start regelmäßiges senden der Kommandos
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOCControlRunning 1");              ## MaxSOC Begrenzung weil Speicher bereits 100 % hat
     if (AttrVal("$SELF","verbose",0) >=3) {
       Log 3, "$SELF cmd_11 : Battery_ExternControl_MaxSocRel auf 95 % reduziert";
     };
   }
  }


Solltet Ihr noch weitere Ideen haben, dann meldet Euch einfach bei mir.

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

Mumpitz

Zitat von: ch.eick am 05 August 2021, 14:13:20
Hallo zusammen,
und schon geht es weiter.

Im Photovoltaikforum ist folgendes aufgetaucht.

Sobald der Speicher nicht verwendet wird kommt es zu minimalen Entladungen, die ich im Dashboard mit 10-14 W Entladung ebenfalls bereits gesehen habe.
Ist nun der Speicher bei 100 % SOC angelangt kann man nach einiger Zeit einen leichten Knick im Diagramm sehen und der Speicher wird wiederum auf 100 % nachgeladen.
Dies ist etwas unschön, da gerade in diesem Bereich "gefühlt" ziemlich viel Leistung benötigt wird, um den kleinen letzten Rest in den Speicher zu bekommen.


Ich finde den Ansatz grundsätzlich gut. Allerdings würde ich es eingrenzen das er diese Beschränkung auf 95% nur durchführt, solang die erwartete, ausstehende Tagesleistung über z.b. 3000Wh liegt. Weil ich möchte ungern in Nächten, wo ich grad so knapp durchkomme, die 5% verschenken. Was meinst du?

Ich habe das übrigens auch bei einem Korrektur DOIF so eingebaut, welche den Actual_Soc auf min 80% korrigiert. Dieses wird auch erst ausgeführt, wenn die erwartete Tagesleistung unter 10000 Wh liegt...

ch.eick

Zitat von: Mumpitz am 05 August 2021, 14:59:33
Ich habe das übrigens auch bei einem Korrektur DOIF so eingebaut, welche den Actual_Soc auf min 80% korrigiert. Dieses wird auch erst ausgeführt, wenn die erwartete Tagesleistung unter 10000 Wh liegt...
Das ist doch bereits mit einem dynamisch berechneten MaxSOC vorhanden.
cmd_7 berechnet den Soc
cmd_6 führt es alle drei Minuten aus

Zitat
Ich finde den Ansatz grundsätzlich gut. Allerdings würde ich es eingrenzen das er diese Beschränkung auf 95% nur durchführt, solang die erwartete, ausstehende Tagesleistung über z.b. 3000Wh liegt. Weil ich möchte ungern in Nächten, wo ich grad so knapp durchkomme, die 5% verschenken. Was meinst du?
Das ist mir gerade auch noch aufgefallen und ich habe im vorherigen Post den Code nochmal erweitert. Die Tests laufen noch.
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

Mumpitz

Zitat von: ch.eick am 05 August 2021, 14:13:20
Hallo zusammen,
und schon geht es weiter.

I

################################################################################################################
## 11 Der Speicher ist voll geladen. Hier wird das ständige nachladen auf 100 % vermieden.
##
DOELSEIF
( [WR_1:Act_state_of_charge] == 100 or                           ## wenn der Speicher voll ist den MaxSOC wieder reduzieren, damit nicht immer nachgeladen wird
  ([WR_1_Speicher_1_ExternTrigger:SpeicherMaxSOC_Actual] == 95 and
   [WR_1:Act_state_of_charge] <  97  and [17:55]) )               ## ab 18:00 Uhr eventuell wieder nachladen

  {
   if ([WR_1:Act_state_of_charge] < 97) {
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOC_Actual 100");                   ## Eventuell noch mal nachladen
     if (AttrVal("$SELF","verbose",0) >=3) {
       Log 3, "$SELF cmd_11 : Battery_ExternControl_MaxSocRel auf 100 % nachladen";
     };
   } else {
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOC_Actual 95");
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherCmdRepeatRunning 1");                  ## Start regelmäßiges senden der Kommandos
     CommandSetReading(undef, "WR_1_Speicher_1_ExternTrigger SpeicherMaxSOCControlRunning 1");              ## MaxSOC Begrenzung weil Speicher bereits 100 % hat
     if (AttrVal("$SELF","verbose",0) >=3) {
       Log 3, "$SELF cmd_11 : Battery_ExternControl_MaxSocRel auf 95 % reduziert";
     };
   }
  }




Wieso so statisch um 17:55 Uhr? Ich habe sehr gute Erfahrungen mit dem Wert "WR_1:Solar_Calculation_fc0_rest" gemacht! Dann ist das ganze etwas dynamischer. Die 5% sind doch vorallem im Winterhalbjahr wichtig, da ist vermutlich 17:55 zu spät!

ch.eick

Zitat von: Mumpitz am 05 August 2021, 16:17:31
Wieso so statisch um 17:55 Uhr? Ich habe sehr gute Erfahrungen mit dem Wert "WR_1:Solar_Calculation_fc0_rest" gemacht! Dann ist das ganze etwas dynamischer. Die 5% sind doch vor allem im Winterhalbjahr wichtig, da ist vermutlich 17:55 zu spät!
Das war nur der erste Test, natürlich wird das dann noch dynamisch und "WR_1:Solar_Calculation_fc0_rest" finde ich einen guten Vorschlag,
jedoch berücksichtigt der Wert nicht den zu erwartenden Hausverbrauch. Ich schau es mir morgen mal in der Datenbank genauer an.

Im Winter wird es keine MaxSoc Begrenzung geben, da eh nicht genug vom Dach kommt. Dann ziehen unsere anderen Regelungen z.B. smart Laden.
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