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

killah78 · 14 Juni 2023, 12:18:41

Habe das KI Thema jetzt erst bemerkt und will mich mal einlesen.
Im Yield ist das Laden der Batterie garnicht drin. Da brauchst du nichts rausrechnen.
Wenn ich aktuell gucke, morgens um 6:30 ist schon Leistung da und es wird die Batterie geladen. Bis ca 9. In der Zeit habe ich keinen Yield Anstieg in WR1. Somit wird das Laden nicht gezählt. Jedoch später am Abend das Entladen. So ist die Philosophie von Kostal, dass die (nutzbare)Energie, die aus dem Wechselrichter kommt den Ertrag darstellt.
Der WR2 ist eigentlich nur ein Dummer WR, der nix kennt. Für den ist um 6:30 Sonne da, und er speist in AC ein. Von Batterien oder anderen Wechselrichtern kennt der nix. Daher zählt er ab 6:30 Yield. Die aber tatsächlich in die Batterie wandern. Das heißt einmal wird Yield gezählt (WR2) und einmal nicht (WR1).
Scheint Kostal aber nicht mehr ändern zu wollen, sonst hätten sie es schon im Griff. Sie korrigieren die Werte nur im Solarportal.
Gruss

ch.eick · 14 Juni 2023, 12:30:05

Zitat von: killah78 am 14 Juni 2023, 12:18:41Habe das KI Thema jetzt erst bemerkt und will mich mal einlesen.
Im Yield ist das Laden der Batterie garnicht drin. Da brauchst du nichts rausrechnen.
Wenn ich aktuell gucke, morgens um 6:30 ist schon Leistung da und es wird die Batterie geladen. Bis ca 9. In der Zeit habe ich keinen Yield Anstieg in WR1. Somit wird das Laden nicht gezählt. Jedoch später am Abend das Entladen. So ist die Philosophie von Kostal, dass die (nutzbare)Energie, die aus dem Wechselrichter kommt den Ertrag darstellt.

Genau durch diese Verschiebung brauche ich die Bereinigung des Yield der gesamt PV-Anlage. Damit die KI weiß, das zum Zeitpunkt des Speicher Ladens der Yield in Wirklichkeit höher wäre. Ansonsten verläuft die Yield Kurve um das Speicherladen niedriger und wird beim Entladen nach oben verfälscht.

ZitatDer WR2 ist eigentlich nur ein Dummer WR, der nix kennt. Für den ist um 6:30 Sonne da, und er speist in AC ein. Von Batterien oder anderen Wechselrichtern kennt der nix. Daher zählt er ab 6:30 Yield. Die aber tatsächlich in die Batterie wandern. Das heißt einmal wird Yield gezählt (WR2) und einmal nicht (WR1).
Scheint Kostal aber nicht mehr ändern zu wollen, sonst hätten sie es schon im Griff. Sie korrigieren die Werte nur im Solarportal.
Gruss

Und diese Korrektur mache ich über die SW_* readings im WR_1_API Device. Der Kostal Yield wird dort einfach zusammen gerechnet, wobei beim WR_1 ja der Speicher nach Kostal Philosophie angewendet wird. Zeichne Dir mal die Kurve des Yield, aber als Ertrag/Stunde, dann solltest Du beim Speicher Laden einen Einbruch bei den Balken Diagramm sehen können. Und Du wirst einen Ertrag in der Nacht haben

Um es mir einfacher zu machen habe ich eh schon die KI Prognose auf 6-21 Uhr eingeschränkt, denn nachts kommt kein PV-Ertrag, außer bei Kostal

ch.eick · 14 Juni 2023, 13:41:30

Ich habe mal bei mir die Speicher Korrektur des Ertrages erweitert.
Bei mir ist es meistens zwar jetzt im Sommer nicht viel, aber etwas kommt per AC Laden dann doch dazu, was ich nicht berücksichtigt habe.
Da das jetzt ja bereits beim yield vom WR_2 gezählt wurde müsste ich es in meiner Korrektur dann noch abziehen.
Das schau ich mir noch genauer an.
In der Tabelle würde das was als yield steht beim Laden des Speichers zum korrigierten yield dazu kommen und das was entaden wurde abgezogen werden.
Somit wird dann der yield wie bei einer PV-Anlage ohne Speicher angezeigt werden, also entgegen der Kostal Philosophie.

Code Auswählen

        TIMESTAMP          DCto   ACto  DCfrom yield
    2022-05-05 08:00:00    370     20    50    272
    2022-05-05 09:00:00    577     37    8     484
    2022-05-05 10:00:00    691     80    92    509
    2022-05-05 11:00:00    1909    758        1623
    2022-05-05 12:00:00    2942    116   3    2498
    2022-05-06 06:00:00    0       0     0       0

ch.eick · 14 Juni 2023, 15:27:54

Für alle die, die bereits auf dem Weg sind das WR_clt Device zu nutzen könnte man bereits schon mal die WR_*_config Devices aufräumen.
Die WR_*_config Devices werden später nicht mehr benötigt, da die KI Prognose diese Werte nicht mehr verwendet.
Darüber hinaus gibt es nur noch wenige Devices, die tatsächlich aus dem WR_*_config ihre IP-Adresse lesen. Dies wird leider in den verschiedenen Devices nicht durchgängig angeboten, weshalb ich auch das nicht mehr nutze.

Code Auswählen

Falls ihr mehrere WRs habt, bitte bei allen entsprechend ändern
attr WR_1_API replacement01Mode text
attr WR_1_API replacement01Regex %IP-WR%
attr WR_1_API replacement01Value <Ip-Adresse>


Für die, die einen BYD HV Speicher haben, was mir aber niemand zurück gemeldet hat...
attr WR_1_Speicher_1 replacement01Mode text
attr WR_1_Speicher_1 replacement01Regex %IP-WR_1_Speicher_1%
attr WR_1_Speicher_1 replacement01Value <Ip-Adresse>

Mehr Stellen habe ich nicht mehr gefunden, weshalb dann bei Verwendung die WR_*_config weg können.

ch.eick · 14 Juni 2023, 15:31:48

Auch in den WR_1 und WR_1_API Devices kann man generell das stateFormat etwas ändern, damit der Status im FHEMWEB nicht bei den ganzen Devices doppelt angezeigt wird.
Durch die Einklammerung mit der zusätzlichen verbose >=3 Angabe kann man somit das stateFormat ausblenden und nur bei der Fehlersuche aktivieren.

Code Auswählen

Im stateFormat

{
if (AttrVal("$name","verbose",0) >=3) {
   < hier steht der ganze Code >
}
}

Danach sollte es dann so aussehen
Du darfst diesen Dateianhang nicht ansehen.

ch.eick · 15 Juni 2023, 08:47:28

Moin,
ich habe da mal wieder eine Tages Kurve.
- Es war mittags Bewölkung
- In Spitzen wäre das Einspeiselimit überschritten worden (rote Linie aus Punkten), hierbei ist die orangene Linie SW_Total_AC_Active_P nicht
die Einspeisung. Total_Active_P_EM_to_Grid liegt um den Hausverbrauch und Speicherladung darunter, das kann ich separat einblenden.
- Die Speicher SOC Berechnung vom BYD ist zusammengebrochen (einige Tage durch MaxSOC Limitierung keine Vollzyklen)
- Bis ca. 7 Uhr wurde der Speicher mit dem ersten PV-Überschuss bis MinSOC geladen
- Ab 9 Uhr begann das Laden mit geringer Leistung bis zum SOC von 30%, was um 11 Uhr in das Mittagshoch gewechselt hat
- Gegen 14 Uhr hatte der Speicher dann 100%, da er ja vorher komplett gelehrt wurde
- Der Netz Bezug von 4:45 - 5:45 Uhr lag unter 0.5 kWh (13 ct Kosten), was ich mir für eine längere Haltbarkeit des Speichers gönne.
- Die gelbe Stufenlinie von 11-17 Uhr ist der Tibber Trigger für die günstigsten Kosten an dem Tag. Im Sommer brauche ich jedoch kein Tibber

Falls Ihr Anmerkungen habt, dann bitte her damit

Du darfst diesen Dateianhang nicht ansehen.

killah78 · 15 Juni 2023, 13:43:45

Hallo Christian,
ich habe jetzt die einzelnen KI Schritte mal durchgearbeitet. Leider führt er das Script nicht aus.
folgende Ausgabe:

Code Auswählen

PV_KI_Prognose  running - start
CSRF token requested for server that doesn't know CSRF
CSRF token requested for server that doesn't know CSRF
CSRF token not available!
CSRF token requested for server that doesn't know CSRF
Failed to get fhem state. Not connected.
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 44, in <module>
    if (verbose >= 4):
TypeError: '>=' not supported between instances of 'dict' and 'int'

Wie kann ich das lösen?

Dann ist mir noch aufgefallen, dass in einem SVG das Reading "Solar_Calculation_fc1" verwendet wird. Das habe ich nicht. Was ist das und wo müsste es herkommen?

Edit: Ok, im Script habe ich CSRF ausgeschaltet. Jetzt läuft es weiter:

Code Auswählen

Query had no result.
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 53, in <module>
    print("Inverter_Max_Power {}".format(Inverter_Max_Power["Value"]))
KeyError: 'Value'

Ein Device "WR_1_Speicher_1_ExternControl" gibt es bei mir nicht, da ich nur intern_control nutze.

ch.eick · 15 Juni 2023, 14:00:55

Zitat von: killah78 am 15 Juni 2023, 13:43:45Dann ist mir noch aufgefallen, dass in einem SVG das Reading "Solar_Calculation_fc1" verwendet wird. Das habe ich nicht. Was ist das und wo müsste es herkommen?

Das war noch aus dem alten WR_1 Device.
Welches SVG?

ZitatEdit: Ok, im Script habe ich CSRF ausgeschaltet. Jetzt läuft es weiter:

Okay
[/quote]

Code Auswählen

Query had no result.
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 53, in <module>
    print("Inverter_Max_Power {}".format(Inverter_Max_Power["Value"]))
KeyError: 'Value'

[/quote]
Im Python Skript wird das hier gelesen

Code Auswählen

Inverter_Max_Power = fh.get_device_reading("WR_1_Speicher_1_ExternControl", "SpeicherMidday_Inverter_Max_Power")Hast Du da einen Wert gesetzt?
Du darfst diesen Dateianhang nicht ansehen.

killah78 · 15 Juni 2023, 14:23:38

a) SVG_LogDB_Photovoltaik_4
b) Nutze kein Extern Control. Ist das Voraussetzung?

ch.eick · 15 Juni 2023, 14:49:29

Zitat von: killah78 am 15 Juni 2023, 14:23:38a) SVG_LogDB_Photovoltaik_4

Ich verende die SVGs schon lange nicht mehr.
Falls Du auch das WR_ctl verwenden möchtest, dann musst Du im SVG das WR_ctl und das entsprechende reading auswählen, das sollte dann z.B. "Yield_fc0" sein, wenn Du die Prognose so aufrufst.

Code Auswählen

"/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.40 192.168.178.40 LogDBRep_PV_KI_Prognose WR_ctl Yield_fc"

Zitatb) Nutze kein Extern Control. Ist das Voraussetzung?

Nein, das kann man extra verwenden. Ich schau mir das Python Skript nochmal an und fang den Fehler ab.
Du könntest die Zeilen erstmal so ändern und bei "xxxx" einen Wert eintragen, ab dem Du Dein Mittagshoch beginnen möchtest.

Code Auswählen

# Inverter_Max_Power = fh.get_device_reading("WR_1_Speicher_1_ExternControl", "SpeicherMidday_Inverter_Max_Power")

# if (verbose >= 4):
#     print("Inverter_Max_Power {}".format(Inverter_Max_Power["Value"]))

Inverter_Max_Power = XXXX

ch.eick · 15 Juni 2023, 15:21:57

Hallo zusammen,
für alle, die die KI Prognose mit dem Mittagshoch nutzen und auch das WR_ctl verwenden, stellt sich die Frage, wo wir das SpeicherMidday_Inverter_Max_Power am besten ablegen. Es wird vom KI Python Skript gelesen und liegt momentan im WR_1_Speicher_1_ExternControl Device, um es einstellen zu können. Eigentlich wird es aber dort gar nicht verwendet und passt jetzt besser zum WR_ctl, da dort ja auch alle Informationen bereits liegen.
Du darfst diesen Dateianhang nicht ansehen.
Ich bitte um Meinungsbekundung

killah78 · 16 Juni 2023, 15:44:06

Hi Christian,
ich habe jetzt das WR_ctl eingebaut. Und auch das External control. KI Script läuft jetzt.
So viele Zahlen die jetzt auf mich einwirken. Muss erstmal durchblicken. Will aber erstmal den letzten Stand implementieren.

Paar Fragen:

1. Technisch: Im WR_ctl wird mit !([$SELF:state] eq "off") abgefragt, ob das DOIF nicht off ist. Wann wird off gesetzt? Wenn ich das disable, bekomme ich im state nur "disabled" oder "deactivated". Wann wird off gesetzt?

2. Kann ich aus den alten Definitionen jetzt folgendes löschen:
PV_Schedule, LogDBRep_PV_Forecast_SQL, DWD_forecast? Auch was aus der 99_myUtils.pm? Da habe ich Solar_plain und Solar_forecast. Können die weg?

3. Kannst du auch die Solar_Radiation wieder in die KI Prognose einbauen? Diese müsste ja jetzt im WR_ctl-Radiation sein. Oder wo kam die her?

4. Was schreibst du bei WR_ctl in die Datenbank? Ich habe da nur Yield_fc0_day drin. Habe aber jetzt auch Yield_fc0_current und Yield_fc1_current hinzugefügt, damit ich es im SVG nutzen kann. Also analog Solar_Calculation. Oder sollten die ganzen Yield Werte bereits durch das Script in die db geschrieben worden sein? Im SVG kann ich nur Yield_fc0_day auswählen.

5. External Control: Das muss ja im WR erstmal eingeschaltet werden. Was sind für mich die Auswirkungen? Klar, ich kann Zeitsteuerung,Trigger etc setzen. Muss da irgendwas beachtet werden? Oder bietet der WR das dann einfach an, dass ich das beeinflussen kann und ansonsten das selbe wie intern control?

Viele Grüße

ch.eick · 16 Juni 2023, 16:40:50

Zitat von: killah78 am 16 Juni 2023, 15:44:06Hi Christian,
ich habe jetzt das WR_ctl eingebaut. Und auch das External control. KI Script läuft jetzt.
So viele Zahlen die jetzt auf mich einwirken. Muss erstmal durchblicken. Will aber erstmal den letzten Stand implementieren.

Die Zahlen waren vorher auch schon da

, jetzt sind sie aber im Status sortiert, damit man den Zusammenhang erkennt.

ZitatPaar Fragen:

1. Technisch: Im WR_ctl wird mit !([$SELF:state] eq "off") abgefragt, ob das DOIF nicht off ist. Wann wird off gesetzt? Wenn ich das disable, bekomme ich im state nur "disabled" oder "deactivated". Wann wird off gesetzt?

Das hatte ich aus einem Beispiel von Damian übernommen, es aber noch nie angewendet.
Eventuell kann man ja "set WR_ctl off" absetzen, wenn man die DOIF Blöcke mal nicht haben möchte.
Da müsste ich aber Debian mal anschreiben, so ist das mit den Vorlagen

Zitat2. Kann ich aus den alten Definitionen jetzt folgendes löschen:
PV_Schedule, LogDBRep_PV_Forecast_SQL, DWD_forecast? Auch was aus der 99_myUtils.pm? Da habe ich Solar_plain und Solar_forecast. Können die weg?

Also, DWD_forecast liefert Dir die Wetter Daten und wird weiter verwendet. Schau da bitte mal, ob Du alle Einstellungen drin hast.

Zitat3. Kannst du auch die Solar_Radiation wieder in die KI Prognose einbauen? Diese müsste ja jetzt im WR_ctl-Radiation sein. Oder wo kam die her?

Die rad1h Werte kommen vom DWD_forecast

Zitat4. Was schreibst du bei WR_ctl in die Datenbank? Ich habe da nur Yield_fc0_day drin. Habe aber jetzt auch Yield_fc0_current und Yield_fc1_current hinzugefügt, damit ich es im SVG nutzen kann. Also analog Solar_Calculation. Oder sollten die ganzen Yield Werte bereits durch das Script in die db geschrieben worden sein? Im SVG kann ich nur Yield_fc0_day auswählen.

Das WR_ctl nimmt die Forecast readings aus der KI Prognose auf. Um die KI Prognose dann auch stundenweise in der DbLog zu haben werden die Yield_fc[0|1] Werte direkt aus dem Python Skript mit dem richtigen TIMESTAMP in die DbLog geschrieben.
Alles was man sonst noch so haben möchte ginge dann über DbLogInclude, wobei Yield_fc*.* keinen Sinn macht, da diese ja alle zur gleichen Zeit erzeugt werden und sich somit schlecht im Diagramm darstellen lassen. Deshalb das direkt schreiben aus dem Python Skript.

Code Auswählen

    2023-06-16 06:00:00    WR_ctl    addlog        Yield_fc0    1386    
    2023-06-16 07:00:00    WR_ctl    addlog        Yield_fc0    3755    
    2023-06-16 08:00:00    WR_ctl    addlog        Yield_fc0    6012    
< snip >
    2023-06-16 18:00:00    WR_ctl    addlog        Yield_fc0    3788    
    2023-06-16 19:00:00    WR_ctl    addlog        Yield_fc0    1113    
    2023-06-16 20:00:00    WR_ctl    addlog        Yield_fc0    153    


    2023-06-16 06:00:00    WR_ctl    addlog        Yield_fc1    1365    <<< Diese fc1 Werte wurden bereits gestern geschrieben
    2023-06-16 07:00:00    WR_ctl    addlog        Yield_fc1    3726    
    2023-06-16 08:00:00    WR_ctl    addlog        Yield_fc1    6014    
< snip >
    2023-06-16 18:00:00    WR_ctl    addlog        Yield_fc1    3788    
    2023-06-16 19:00:00    WR_ctl    addlog        Yield_fc1    1113    
    2023-06-16 20:00:00    WR_ctl    addlog        Yield_fc1    153    


    2023-06-17 06:00:00    WR_ctl    addlog        Yield_fc1    1268    <<< Und diese fc1 Wurden heute, bereits für morgen geschrieben
    2023-06-17 07:00:00    WR_ctl    addlog        Yield_fc1    3624    
    2023-06-17 08:00:00    WR_ctl    addlog        Yield_fc1    5912    
< snip >
    2023-06-17 18:00:00    WR_ctl    addlog        Yield_fc1    3788    
    2023-06-17 19:00:00    WR_ctl    addlog        Yield_fc1    1113    
    2023-06-17 20:00:00    WR_ctl    addlog        Yield_fc1    153    


    2023-06-16 05:05:34    WR_ctl    DOIF        Yield_fc0_day    106078    
    2023-06-16 06:05:33    WR_ctl    DOIF        Yield_fc0_day    106078    
    2023-06-16 07:05:32    WR_ctl    DOIF        Yield_fc0_day    105076    
< snip >
    2023-06-16 14:05:45    WR_ctl    DOIF        Yield_fc0_day    105475    
    2023-06-16 15:05:36    WR_ctl    DOIF        Yield_fc0_day    105475    
    2023-06-16 16:05:29    WR_ctl    DOIF        Yield_fc0_day    105475

Zitat5. External Control: Das muss ja im WR erstmal eingeschaltet werden. Was sind für mich die Auswirkungen? Klar, ich kann Zeitsteuerung,Trigger etc setzen. Muss da irgendwas beachtet werden? Oder bietet der WR das dann einfach an, dass ich das beeinflussen kann und ansonsten das selbe wie intern control?

Die extern Control arbeitet nach dem "dead man" Prinzip, wenn nichts von extern für die eingestellte Zeit mehr kommt, dann gilt die interne Steuerung.

Der Zeit Trigger dient eigentlich nur denen, die einen HT/NT Tarif haben, ansonsten nutz besser die Zeitsteuerung im Plenticore, die man übrigens auch mit dem WR_1_API bedienen kann. Das hat aber bisher noch keiner verwendet

Der Vorteil der WR_1_Speicher_1_ExternControl wäre:
- Sommer/Winter Umschaltung des MinSOC
- MaxSOC Begrenzung, wenn im Sommer der Speicher morgens noch zuviel Ladung hat und somit nie zum MinSOC kommen würde.
- Laden im Mittaghoch, wegen der 70% Regelung, wenn man über 7 kWp hat
- Zwangsladen/entladen des Speichers mit einstellbarer Leistung (zu Wartungszwecken

)

- Ich verwende auch den SG-Ready Ausgang für die Einschaltung eines Ventilators, der also über die API Ein/Aus geschaltet werden kann.
- Bei einer openWB kann ich auch die Unterstützung des Hausspeichers zulassen, oder diesen komplett sperren

ch.eick · 19 Juni 2023, 16:42:37

Hallo zusammen,
ich habe jetzt hier mal ein Diagramm, bei dem man den Verlauf des SOC in Verbindung mit der WR_1_Speicher_1_ExternControl MaxSoc Limitierung sehen kann.
Zu erkennen ist, das der SOC ca. 5 Tage verlässlich vom Speicher berechnet werden kann, bis es dann zu einem abbruch kommt und des Speicher schlagartig auf den MinSOC oder darunter abfällt. Im Diagramm beginnt es mit einem abfallen und es wurde aus dem Netz ca. 0,5 kWh bezogen, was ich icht so dramatisch sehe. Dann erfolgte ein Aufladen auf 100% in einem schönen Vollzyklus. In den folge Tagen wurde jeden Tag etwas weniger aufgeladen, da morgens immer noch recht viel SOC vorhanden war. Am 5. Tag war dann durch die Nachtentladung wieder die SOC Berechnung plötzlich am Ende, jedoch passte es dann ohne Netzbezug wieder wieder bündig an den nächsten Tag. Es erfolgte wieder eine 100% Ladung and here we go

Du darfst diesen Dateianhang nicht ansehen.
Das ganze Thema wird ja recht controvers diskutiert und soll ja bei den aktuellen Speichern so nicht mehr erforderlich sein, jedoch sehe ich es trotzdem als Speicher schonend an. Warum sollten ansonsten die E-Auto Hersteller auch eine 80% Ladegrenze angeben, wenn das alles nichts bringen sollte.

VG Christian

killah78 · 21 Juni 2023, 11:47:10

Hallo Christian,
ich spiele gerade mit der externen Batteriesteuerung herum.
Ich habe jetzt mal das Zwangsladen bzw Entladen des Speichers getestet. Mit dem Reading SpeicherDcPowerAbs. Bzw. sind da ja auch set Behle im WR_1 und auch im WR1_API.
Funktioniert auch wunderbar. Hätte aber gedacht, dass Battery_ExternControl_DcPowerAbs sich nur aus DC bedient. Allerdings zieht er auch aus dem Netz.

Nun gut. Ich habe dann Battery_ExternControl_DcPowerAbs wieder auf 0 gesetzt, in der Hoffnung, dass jetzt wieder automatisch geregelt wird. Bleibt aber jetzt auf 0. Keine Entladung, keine Ladung mehr.
Muss da noch irgendwas gesetzt werden? Ich hatte das so verstanden, dass wenn das Signal nicht alle 60 Sekunden wiederholt wird, dass dann die Automatik wieder greift. Ist aber scheinbar nicht so.

Hast du da einen Tip?