Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)

ch.eick · 27 Mai 2020, 00:01:49

Also meine Batterie wird momentan von ca 20:00 bid 6:00 Uhr benoetigt und ist von gestern 8,1 KW auf heute morgen 5,5 KW das sind dann 2,6 KWh /10h = 260 W , die ich als durchschnittliche Grundlast in der Nacht habe.

Ich denke Deine 6-7 KWh entsprechen Deinem Tagesverbrauch ohne eine Waermepumpe oder wie bei mir ein Pool.
Der Speicher sollte so dimensioniert sein, dass er Deinen Bedarf fuer die Nacht deckt, plus einen kleinen Zuschlag.
Du solltest immer daran denken, das der Speicher einen schlechteren Wirkungsgrad, als wenn Du die PV Leistung direkt verbrauchst, hat. Der BYD zeigt bei mir ca 72% Wirkungsgrad an, also als Verhaeltnis von Input zu Output.
Dazu kommt noch, dass es nicht soooo gut fuer den Speicher ist, wenn er nie bis zum eingestellten MinSOC Wert (bei mir 15%) entladen wird.

Die Eigenverbrauchssteuerung soll ja gerade bewirken, dass die Leistung sofort am Tag verbraucht wird, damit sie nicht erst im Speicher landet. Der Speicher liefert nur, wenn Tagsueber viel Bewoelkung ist oder halt in der Nacht, wenn die Sonne aus ist

Wenn Du keine Grossanlage mit >10Kwp hast und Verbraucher, die in der Nacht richtig Leistung benoetigen, dann duerfte der Speicher viel zu gross sein.

Gerade im Winter bekomme ich den Speicher nicht immer voll, bevor die Sonne untergegangen ist, weshalb >10Kwp toll waeren. Und in der Nacht schaffe ich es dann bei milden Wintertemperaturen auch nur bis ca. 1:00 Uhr morgens, weil dann die LWP auch nachts mit bis zu 4x 2,5 KWh ordentlich Leistung braucht. Aber wie gesagt, der Speicher muss auch im Winter erstmal geladen werden koennen und da bedarf es einiger Module.

Gruss
Christian

Edit: Ich habe noch die Bilanz angehaengt, aber nur weil gvzdus vorgelegt hat....
Die PV-Erzeugung "aktueller Wert" kommt gerade aus dem Speicher.

gvzdus · 27 Mai 2020, 07:19:21

2 Anmerkungen / Fragen:

ZitatDazu kommt noch, dass es nicht soooo gut fuer den Speicher ist, wenn er nie bis zum eingestellten MinSOC Wert (bei mir 15%) entladen wird.

Das widerspricht jetzt dem, was ich von der Technik weiß. Aus der E-Auto-Diskussion habe ich mitgenommen, dass die Zellen dann besonders lange halten, wenn sie vor allem im Mittel-SoC gehalten werden, und "ganz voll" und noch schlimmer "ganz leer" an der Lebensdauer zehren. Nun ist "Ganz leer" nicht 15%, aber 15% ist eben auch nicht Mittelbereich. Wie kommst Du zu Deiner Aussage?

Außerdem: Ich bin über Deinen Wirkungsgrad überrascht. Ich habe mehrmals die "Stromspeicher-Inspektion" der HTW Berlin gelesen (https://pvspeicher.htw-berlin.de/speicher-inspektion-2020/), und da ist ja nun gerade Deine Kombination mit das Beste "wo geht". Wie bestimmst Du den?

ch.eick · 27 Mai 2020, 09:13:36

Mein Wissen ist leider auch nur Hörensagen und Altwissen. Leider habe ich noch keine Langzeiterfahrung.
Der Wirkungsgrad wird in % im BYD angezeigt und ich muss meine Angabe korrigieren. Hurra es ist viel besser

Code Auswählen


fhem@raspberrypi:~/python/kostal$ python3 ./readbyd_2.py 
Start querying BYD....
Returnvalue -should be zero if successful :  0
----------------Start Values BYD ----------------
{'Total_Charge_Energy': 982.313,
 'Total_Cycle_Counts': 92.0,
 'Total_Discharge_Energy': 829.741,
 'arrayvoltage': 373.607,
 'current': 1.483,
 'maxcelltemp': 23.1,
 'maxcellvol': 3.344,
 'maxtemppos': '4',
 'maxvolpos': 3,
 'mincelltemp': 19.3,
 'mincellvol': 3.333,
 'mintemppos': '6',
 'minvolpos': '1',
 'packvoltage': 373.094,
 'power': '0',
 'soc': '74.300%',
 'sysTemp': '22.200'}
----------------End - Values from BYD ----------------
Specific values from array....
BYD Total Charge Energy                 : 982.313 Kwh
BYD Total Discharge Energy              : 829.741 Kwh
Calculations...
Charging (+) / Discharging (-) Energy   : 553.0 W
Efficiency is                           : 0.845
fhem@raspberrypi:~/python/kostal$

Der Plenticore steuert die Ladung des Speichers nach einem internen Algorithmus und da kann ich kein MittelSOC erkennen. Es scheint auf jeden Fall der Ladebeginn verschoben zu werden, um die dynamische 70% Regel zu optimieren. Am Abend ist der Speicher momentan immer zu 100% geladen, obwohl ich morgens auch immer noch ca 30% über MinSOC habe.

Gruß Christian

Mumpitz · 27 Mai 2020, 09:58:12

Zitat von: ch.eick am 27 Mai 2020, 09:13:36
Mein Wissen ist leider auch nur Hörensagen und Altwissen. Leider habe ich noch keine Langzeiterfahrung.
Der Wirkungsgrad wird in % im BYD angezeigt und ich muss meine Angabe korrigieren. Hurra es ist viel besser
Code Auswählen Erweitern
fhem@raspberrypi:~/python/kostal$ python3 ./readbyd_2.py Start querying BYD.... Returnvalue -should be zero if successful : 0 ----------------Start Values BYD ---------------- {'Total_Charge_Energy': 982.313, 'Total_Cycle_Counts': 92.0, 'Total_Discharge_Energy': 829.741, 'arrayvoltage': 373.607, 'current': 1.483, 'maxcelltemp': 23.1, 'maxcellvol': 3.344, 'maxtemppos': '4', 'maxvolpos': 3, 'mincelltemp': 19.3, 'mincellvol': 3.333, 'mintemppos': '6', 'minvolpos': '1', 'packvoltage': 373.094, 'power': '0', 'soc': '74.300%', 'sysTemp': '22.200'} ----------------End - Values from BYD ---------------- Specific values from array.... BYD Total Charge Energy : 982.313 Kwh BYD Total Discharge Energy : 829.741 Kwh Calculations... Charging (+) / Discharging (-) Energy : 553.0 W Efficiency is : 0.845 fhem@raspberrypi:~/python/kostal$
Der Plenticore steuert die Ladung des Speichers nach einem internen Algorithmus und da kann ich kein MittelSOC erkennen. Es scheint auf jeden Fall der Ladebeginn verschoben zu werden, um die dynamische 70% Regel zu optimieren. Am Abend ist der Speicher momentan immer zu 100% geladen, obwohl ich morgens auch immer noch ca 30% über MinSOC habe.

Gruß Christian

Bringst du diese Daten auch in FHEM rein?

ch.eick · 27 Mai 2020, 10:06:26

Zitat von: Mumpitz am 27 Mai 2020, 09:58:12
Bringst du diese Daten auch in FHEM rein?

Ich koennte, jedoch habe ich noch keine Verwendung, ueber die Daten, die vom Plenticore eh kommen. Der Plenticore sammelt ja schon von der Batterie und vom KSEM Daten.

Mit den gefundenen Python Skripten kann ich den BYD auslesen und auch beim Plenticore einige Einstellungen fuer den Speicher aendern, z.B. Batterieladung auf Manuell und MinSOC .

EDIT: Um es vollstaendiger zu machen setze ich mich da mal ran, ich hab da eine aenliche Implementierung bereits fuer meine Lueftung gebaut. Der Aufwand waere somit nicht so gross.
Please stay tuned

Gruss
Christian

ch.eick · 27 Mai 2020, 13:05:26

@Mumpitz

Waerest Du bitte so nett und wuerdest Dein Zitat Antwort #42 am: Gestern um 20:30:21 einkuerzen, damit das hier etwas lesbarer bleibt.
Es ist ja nur ein Zitat meines ersten Posts. Du kannst ja auch einfach einen link verwenden, wenn Du es als wichtig erachtest.

Vielen Dank im voraus
Christian

ch.eick · 27 Mai 2020, 13:10:33

Es gibt auch einen kleinen Update im ersten Post fuer die Waschmaschine und den Pool.

Auch zum BYD Speicher habe ich noch eine Idee in der Pipeline
BYD direkt Abfragen und in Fhem anbinden

Mumpitz · 28 Mai 2020, 07:12:46

Zitat von: gvzdus am 11 Mai 2020, 21:25:10

Damit habe ich meine "Stabilitätshysteresen".

Anhand dieser schalte ich nun per Notify und je nach Rahmenvoraussetzungen (würde jetzt zu weit führen, lege ich aber gerne auch noch mal dar) die Verbraucher.

Hallo

Könntest du das bitte für mich noch ein bisschen ausführen?

ch.eick · 28 Mai 2020, 07:29:00

Moin.
Gvzdus verwendet ein Notify um auf die gewünschten Bedingungen zu reagieren. Das steckt bei der hier verwendeten Lösung im DOIF.
Die Stabilitätshysterese ist vergleichbar mit meinem reading Total_PV_reserve . Es soll verhindert werden, dass ein Verbraucher zu schnell eingeschaltet wird, denn an wolkigen Tagen schwankt die Leistung manchmal sehr stark.

Die Bedingung fuer das Einschalten sieht bei mir folgender massen aus.

Code Auswählen


################################################################################################################
## 4 Eigenverbrauch einschalten: wenn PV-Produktion über dem Mindestbedarf ist und PV-Strom ins Netz eingespeist wird
##    und die Laufzeit pro Tag noch nicht erreicht ist; Bei über 7000 Watt Einspeisung sofort aktivieren
##
DOELSEIF
 (([PV_Anlage_1:Total_PV_Power_reserve] >= [Pool:PowerLimitOn] and
   [[Pool:TimeStart]-[Pool:TimeEnd]] and
   [Pool:state] eq "off" and
   [Pool_Counter:pulseTimePerDay] < [Pool:RunTimePerDay]
  ) or
  [PV_Anlage_1:Total_active_power_(powermeter)] <= -7000
 )

Um nun auch eine stabile Leistung zu haben ist beim DOIF das wait attribut gesetzt. Die vierte, durch Doppelpunkt, gesetzte Position verwendet aus dem Dummy das reading PowerLevelMinTime, somit wird vor dem Einschalten nochmals nach dieser Zeit geprueft, ob die Bedingung immernoch erfuellt ist. Natuerlich kann das auch bei einer schwankenden Leistung des WR auftreten, jedoch schwankt es dann um diese Leistungshoehe.

Code Auswählen


wait  0:10:0:[Pool:PowerLevelMinTime]:0:0:0:300:0:300

Bei der oder Bedingung geht es nur darum die dynamische 70 % Regelung auszunutzen. Der Effekt ist, dass auch schon vor der geplanten Zeit den Verbraucher zu aktivieren, wenn sehr viel eingespeist wird. In diesem Fall regelt der Plenticore nicht zu, sondern liefert fuer den Eigenverbrauch noch ueber die 70% hinaus

, was ja direkt im Haus verbraucht wird. In dem angehaengten Diagramm kann man dass recht gut erkennen. Der blaue Block vom ca 1000 Watt, von 11:00 bis 15:20 Uhr, ist der Pool. Dieser wurde vor seiner Zeit aktiviert. Der Plenticore hat auch noch das Laden des Speichers in den Bereich ueber die 70% gelegt, um die Spitzenleistung nutzen zu koennen.
Sehr schön kann man auch um 14:00 Uhr beim Einschalten der LWP sehen, wie der Plenticore kurzfristig die Leistung aus dem Speicher zusteuert. Das ist der rote Peak. Das hellgrüne wird ins Netz eingespeist.

Bei meiner Loesung wurden die zu erfuellenden Bedingungen im DOIF jeweils indirekt in das Dummy ausgelagert. Dort koennen sie dann zentral und uebersichtlich geaendert werden.

Gruß Christian

gvzdus · 28 Mai 2020, 09:18:48

Respekt für Deinen Ritt auf dem DOIF! Die Mächtigkeit des "wait"-Attributs war mir nicht bewusst.

Trotzdem finde ich, dass wir hier etwas Basteln... Eigentlich müsste es doch längst ein Daten- und Parametermodell geben, wie man das, was wir wollen, spezifiziert. Also einen Verbraucher deklariert als:

Wieviel Strom wird er etwa brauchen?
Braucht er ein Tagesquota, oder gilt "soviel wie möglich"?
Welche Prio hat er?
Oder ist er nur die letzte Stromwegmach-Rotze wie ein Heizstab?

Im Prinzip: Ich schalte Waschmaschine / Geschirrspüler / E-Auto ein. Ich wähle "Muss um 15 Uhr fertig sein, bzw. um 16 Uhr zu 70% geladen sein". Das Viech bläst seine Bedarfsmeldung mitsamt erwarteter Strombedarfskurve an einen Controller. Der Controller hat seine Prognose, in die die erwartete Produktion mit allen 3 Preisen (Netz = 28 Ct, PV-Einspeisung vs. Eigenverbrauch = <Deine Verguetung>, Cap = 0 Ct) einfliesst. Und gibt das "Go" zum Zeitpunkt X.

Irgendwelche klugen Köpfe haben doch bestimmt so was schon einmal ausgeheckt?

ch.eick · 28 Mai 2020, 09:49:43

Hallo.

Deine Verbraucherdeklaration habe ich als Klone aus dem SMA Portal abgeleitet und in dem gerätespezifischen Dummy abgebildet. Deshalb sind auch im DOIF die Parameter indirekt angegeben. Schau Dir gerne nochmal die Erläuterung im ersten Post dazu an.
Die Priorisierung war mir etwas zu hart und zu komplex. Es reicht im Normalfall einen Verbraucher nach der Mindestlaufzeit dann einfach wieder weg zu schalten, insbesondere wenn wie hier ein Speicher mit im Spiel ist.

Das mit der Prognose hatte ich bereits auch schon mit KölnSolar diskutiert. Wir sind uns da einig, dass ein sofort reagieren und Verbrauchen besser ist als eine schlechte Prognose:-)
Ein Forecast wäre für mich für den nächsten Tag gut. Wenn der schlecht wird könnte ich der WW-Speicher mit der LWP überheizen und brächte dann an dem Tag die LWP nicht mehr. Aber das wäre mit Kanonen auf Spatzen geschossen. Wie gesagt es ist ein Speicher im Spiel und der kommt im Sommer momentan mit 4KW Reserve aus der Nacht.

Im Prinzip könnte man jetzt bereits ein generiertes Modul erstellen, jedoch müsste ich das dann ja auch maintainen

Gruß Christian

Gesendet von meinem SM-G930F mit Tapatalk

gvzdus · 28 Mai 2020, 11:18:21

So, danke für den Tipp mit SMA, der hat mich nämlich dann mit Googlen zu EEBUS gebracht.
Die Google-Hits für FHEM zusammen mit EEBUS sind übrigens echt übersichtlich.

EEBUS ist genau das, was ich meine: Eine intelligente Synchronisation von Strom-Verbrauchern mit einem System aus PV und ggf. Batterie, einem E-Auto und vor allem der zentralen Intelligenz.

Wer Lust hat, mal die Spec zu lesen (gerade erst runtergeladen und noch nicht selber gelesen):

https://www.eebus.org/media-downloads/#_SPECIFICATIONS

Man muss sich für den Download registrieren, aber der Link zum Registrieren funktioniert nicht. Der hier funktioniert:

https://www.eebus.org/en/registration-downloads/

Viele Grüße, Georg

ch.eick · 28 Mai 2020, 12:04:43

Zitat von: gvzdus am 28 Mai 2020, 11:18:21
So, danke für den Tipp mit SMA, der hat mich nämlich dann mit Googlen zu EEBUS gebracht.
Die Google-Hits für FHEM zusammen mit EEBUS sind übrigens echt übersichtlich.

EEBUS ist genau das, was ich meine: Eine intelligente Synchronisation von Strom-Verbrauchern mit einem System aus PV und ggf. Batterie, einem E-Auto und vor allem der zentralen Intelligenz.

Wer Lust hat, mal die Spec zu lesen (gerade erst runtergeladen und noch nicht selber gelesen):

https://www.eebus.org/media-downloads/#_SPECIFICATIONS

Man muss sich für den Download registrieren, aber der Link zum Registrieren funktioniert nicht. Der hier funktioniert:

https://www.eebus.org/en/registration-downloads/

Haaa, jetzt wo Du es sagst

Das steht ja auch beim Plenticore im MaBuSchie, doch ich denke die sind da noch nicht so weit. Beim Modbus/TCP ist die Firmware fuer den KSEM auch erst auf mein Drengen hin ausgeliefert worden. Ich hatte mich letztes Jahr als der KSEM bei Kostal raus kam direkt fuer diesen entschieden, denn die FW des EM300 wird wohl kaum noch nachgeruestet. Der KSEM soll spaeter auch z.B. mit einer Ladesaeule kommunizieren koennen. Man kann nur hoffen, dass dann auch wirklich alle Hersteller sich an die eebus Kommunikation halten werden. Fuer mich war Modbus/TCP schon eine schoene Oeffnung in die richtige Richtung.

Fuer dieses Forum ist FHEM halt der Dreh- und Angelpunkt fuer die Kommunikation zwischen der Verbrauchern. Bis es ein kostenguenstiges System auf dem Markt geben wird werden wir uns hier wohl noch behelfen muessen.
Auch die Steuerung nach voruebermittelten Leistungskurven wird wohl noch etwas dauern. Bei den Energieerzeugern gibt es auch etwas, um anhand der Verbrauchskurve die einzelnen Verbraucher zu identifizieren, ich komme nur gerade nicht auf den Namen. Das ist auch nicht so einfach, wenn mehrere Verbraucher sich ueberlagern, aber anhand z.B. meiner Grafiken kann ich auch schon sagen, welches Geraet wann gelaufen ist. Da muesste mal jemand mit Integralen ran, ein einzelnes Geraet anhand von Messwerten in einer Grafik koennte ich liefern, das waere dann die Vergleichsbasis, die mit der Gesamtverbrauchskurve per Integral verglichen werden muesste, inklusive Ueberlagerung

Dafuer bin ich jedoch schon viel zu lange raus...

Gruss
Christian

gvzdus · 28 Mai 2020, 12:35:04

Es sprengt allmählich den Thread hier, es könnte glatt eine eigene Thread-Rubrik geben. Aber ich sehe da massenhaft Anknüpfungspunkte für FHEM. Ja, im Moment "können wir" alles, weil wir alles "irgendwie rangebastelt" haben. Aber mal angenommen, EEBUS wird z.B. allein über die E-Mobilitität ein Erfolg, weil der VDA darauf setzt: Man muss sich ja nicht in alles hintenrum reinhacken, wie es nach meinem Eindruck z.Zt. in Sachen Steuerung des Ladens des BEVs läuft.

FHEM könnte einerseits Nicht-EEBUS-fähige Verbraucher EEBUS-fähig machen. Z.B. Deine olle Waschmaschine. Und mittels eines Shelly-Plug-S o.ä. kann FHEM ja auch das Lastprofil ermitteln. Unsere nächste Waschmaschine sollte dann natürlich das von Haus aus können, und idealerweise auch die Heizleistung auf den Solarüberschuss modellieren, statt stumpf 2 kW zu ziehen (und trotzdem nur 100 Euro mehr kosten).

Das andere - darin habe ich mich noch nicht eingelesen - ist, zumindest eine rudimentäre Implementierung des Home-Managers zu liefern. SMA o.ä. wird da m.E. die Nase vorn haben: Theoretisch sollte man in die Solarproduktion eines Tages optimal vorhersagen können, wenn man einerseits über gute Wetterdaten verfügt, und andererseits auch noch die Produktion anderer Solaranlagen aus der Richtung kennt, aus der der Wind die Wolken herbläst.

Das SHIP-Dokument habe ich jetzt überflogen - liest sich alles ganz gut. Da werden nicht uralte Standards aufgehübscht, sondern das hat für mich eher Startup-Atmosphäre: "Nehmen wir TCPIP, AutoDiscovery, Crypto-Stack etc. so, wie man das heute macht!"

Prof. Dr. Peter Henning · 28 Mai 2020, 17:58:48

Ich betreibe meine PV-Anlage jetzt seit 13 Jahren (ohne Speicher, weil schön hohe Einspeisevergütung). Klare Aussage aus der Auswertung wirklich vieler Daten: Eine Vorhersage ist NICHT möglich. Unter anderem ist aus der Windsituation in 7m Höhe keineswegs ableitbar, wie die in 200m Höhe aussieht.

Edit: Ich habe mir den EEBUS-Kram heruntergeladen und genau angesehen. Auf Grund der hohen Asynchronität und der ziemlich engen Timing-Vorgaben sehe ich wenig Chancen, das direkt in FHEM zu integrieren. Auch solche Dinge wie Key Management etc. würden FHEM eher ausbremsen. Eine größere Chance sehe ich, dass es einen Konnektor EEBUS <-> MQTT gibt, der als eigenständiges Programm ohne die (vergleichsweise langsame) Main Loop von FHEM existiert

LG

pah