Leistungsprognose für Wechselrichter

DS_Starter · 07 Dezember 2023, 12:37:44

Mahlzeit,

die Datei liegt in /lib/FHEM/SynoModules. Dort gibt es noch eine API.pm und ErrCodes.pm.

Die Einbindung siehst du gleich in den ersten Zeilen von 76_SolarForecast.pm:

....
use utf8;
use HttpUtils;
eval "use JSON;1;" or my $jsonabs = 'JSON'; ## no critic 'eval' # Debian: sudo apt-get install libjson-perl
eval "use AI::DecisionTree;1;" or my $aidtabs = 'AI::DecisionTree'; ## no critic 'eval'

use FHEM::SynoModules::SMUtils qw(
checkModVer
evaljson
getClHash
delClHash
moduleVersion
trim
); # Hilfsroutinen Modul

LG

DS_Starter · 07 Dezember 2023, 22:28:01

@all,

morgen früh ist wieder ein Update verfügbar.
Im plantConfiguration check wird nun auch die Aktualität der FTUI widget Files überprüft (Anhang).

Nachdem ihr das Modul upgedated habt, könnt ihr den Plant Check gleich duchführen. Das Modul wird euch dann neue Widget Files melden. Ich habe die Widgets gepatcht. Auch mit dem forecast Widget funktionieren jetzt die Schalter in der Grafik.

DS_Starter · 10 Dezember 2023, 09:53:37

Guten Morgen,

ich implementiere gerade ein neues Feature für Batterie Besitzer, was ich gern andiskutieren und eure fachliche Meinung entgegennehmen möchte.
Gerade jetzt in der dunklen Zeit, werden die Batterien oft nicht vollgeladen. Manche Batteriesysteme brauchen aber eine bestimmte Zellspannung (3,6V?), bei Pylontech ca. 90% Ladung, um einen Zellabgleich vornehmen zu können.
Victron hat dafür ein BatteryLife genanntes System welches den SOC schrittweise hochhebt wenn 100% SOC nicht erreicht werden. Das funktioniert ganz ordentlich, hat aber den Nachteil dass viel Energie für uns verlorengeht wenn wie vor kurzem, plötzlich doch mehrere Stunden volle Sonne scheint um dann wieder hinter dichten Wolken zu verschwinden. Dann können nur z.B. 10% gespeichert werden (weil schnell von 90% auf 100% voll), der Rest wird eingespeist.

Jetzt habe ich eine erste Implementierung im Test. Die Logik verfolgt den Ansatz, den User einen LowSoc (z.B. 10%), einen UpSoc (z.B. 50%) und einen MaxSoc (üblich 100%) definieren zu lassen.
Nach dem Vorbild von Victron erfolgt eine 5%ige Anhebung des Minimum SoC wenn am Vortag der MaxSoc nicht erreicht wurde. Die Anhebung erfolgt aber nicht über UpSoc. UpSoc ist die obere Grenze des Minimum SoC. Wird am Vortag MaxSoc Ladung erreicht, verringert sich der Minimum SoC wieder schrittweise um 5%, aber nicht tiefer als LowSoc.

Ergänzt wird die Logik noch um die PV Vorhersage. Dabei wird die obige Minimum SoC Berechnung um die Erwartung der PV Erwartung am aktuellen und morgigen Tag korrigiert. Das bedeutet, dass der Minimum Soc z.B. von heute 50% auf 10% abgesenkt und dadurch die gespeicherte Energie dem Haushalt zugeführt wird, wenn am heutigen oder kommenden Tag eine entsprechende PV Energie zu erwarten ist um die Bat wieder vollzuladen.
Dadurch ist immer genügend "Freiplatz" in der Batterie und andererseits hat die Batterie in langen Dunkelphasen eine Reserve für einen eventuellen Stromausfall (falls der abgesichert werden soll) und wird vor einem lange bestehenden tiefen SoC geschützt.

Weiterhin wird kalkuliert, dass mindestens einmal innerhalb 30 Tagen eine Ladung von mindestens MaxSoC (default 95%) erreicht werden soll um den Zellenausgleich zu aktivieren und die Leistungsfähigkeit der Batterie zu erhalten.
Dazu wird ein Pflege-SoC berechnet, der die Anzahl einer täglichen 5% SoC-Steigerung berücksichtigt um das Ziel eines maximalen MaxSoC-Zyklus von 30 Tagen einzuhalten. Ist der Pflege-SoC höher als der bisher berechnete SoC, wird dieser Wert als Target SoC übernommen. In diesem Fall wird auch der vom Nutzer angegebene UpSoC ignoriert.

Victron lädt die Batterie dann tatsächlich im schlimmmsten Fall aus dem Netz nach um die Batterie zu pflegen.

Das Ergebnis der ganzen Logik wird im Modul zur Zeit in einem Reading "Battery_OptimumTargetSoC" abgebildet.
Den SoC kann man abgreifen und damit seine Batterieanlage (Minimum SoC) dynamisch setzen.
Soweit mein aktueller Ansatz.

Grüße,
Heiko

kask · 10 Dezember 2023, 21:27:05

Finde ich gut soweit erst einmal.

Habe aber ein anderes Verhalten mit den Victrons. Bei Victron ist es zwar so beschrieben wie du es geschildert hast.
Bei mir Verhält sich das aber leicht anders. Bei mir muss der SoC nicht auf 100% kommen damit er das limit um 5% senkt.
Wieviel genau kann ich nicht sagen. Aber es scheint mir so, das es so ist das wenn der Soc am Tage ca. 5-10% höher kam wie er limitiert war dann wird um 5% dekrementiert. Wird sehr wenig eingeladen dann geht das Limit hoch. Ich stecke momentan bei 75-85% fest. Ein auf und ab ist das zur Zeit.

Die Logik ansich hört sich erst einmal plausibel an.

Aber wie bringst du den Victron zum definierten laden alle 30Tage? Wie bringt man generel den Victron zum laden ohne am "ESS/Grid setpoint" zu schrauben?

DS_Starter · 10 Dezember 2023, 22:25:43

ZitatBei mir Verhält sich das aber leicht anders. Bei mir muss der SoC nicht auf 100% kommen damit er das limit um 5% senkt.
Wieviel genau kann ich nicht sagen. Aber es scheint mir so, das es so ist das wenn der Soc am Tage ca. 5-10% höher kam wie er limitiert war dann wird um 5% dekrementiert.

Deine Beobachtungen werden stimmen denke ich. Laut der Victron Doku arbeitet BatteryLife so:

"...Es erhöht diesen Wert (den SoC Anm.) jeden Tag um 5% , bis die Energie, die das System während 24h aus den Batterien bezieht, mit der auszutauschenden Energie übereinstimmt. Das Ziel ist, dass die Batterie bei oder nahe 100% SoC betrieben wird...."

Das Prinzip 1:1 zu übernehmen war im ersten Ansatz für mich zu komplex. Deswegen habe ich die Logik etwas abgeändert und hoffe allerdings das gleiche Ziel zu erreichen mit den Vorteilen die Prognose zu berücksichtigen was Victron nicht kann.
Die Tests müssen zeigen wie gut die Logik funktioniert. Dauert seine Zeit.

ZitatAber wie bringst du den Victron zum definierten laden alle 30Tage? Wie bringt man generel den Victron zum laden ohne am "ESS/Grid setpoint" zu schrauben?

Man kann den SoC generell dynamisch im CerboGX setzen. Ich habe die Kopplung per MQTT2 hergestellt. Der Parameter ist in dem Fall "MinimumSocLimit" den man setzen kann mit dem publish (Beispiel für SoC 50%):

Code Auswählen

W/<Id>/settings/0/Settings/CGwacs/BatteryLife/MinimumSocLimit {"value":50}
setzen kann.

Ab 90% SoC findet der Zellenausgleich statt. Habe ich getestet, funktioniert sichtbar.
Ich halte den Zeitpunkt des letzten Erreichens von SoH fest. Daraus errechnet sich ein 30 Tage Zyklus in dem SoH wieder erreicht werden soll. Wenn sich dieser Zyklus seinem Ende nähert, wird berechnet, wieviel Tage theoretisch benötigt werden um vom aktuellen SoC bis zum SoH mit einer täglichen 5% Steigerung zu kömmen.
Dementsprechend wird der SoC manipuliert. Wird SoH (wieder) erreicht, wird die normale Berechnung des SoC angewendet und SoC wieder stark gesenkt auf maximal "UpSoc".

Wenn man bei Victron z.B. aktuell 50% SoC hat und per Befehl MinimumSocLimit auf z.B. 90% stellt, startet Victron sofort durch starkes Nachladen aus dem Netz den Run auf den neuen SoC. Das habe ich bei mir ausgetestet. Als Status bringt Victron dann "Aufladen - SOC 5% oder mehr unter Min-SoC" und geht richtig zur Sache.
Deswegen ist es wichtig in Steps zu 5% den SoC langsam zu erhöhen.
Man braucht auf jeden Fall eine Möglichkeit der Kopplung mit dem Battriesystem, dass FHEM den SoC schalten kann.

Edit: Wie du auch beobachtet hast, setzt BatteryLife den SoC sehr hoch (85%). KOmmt die Sonne heraus, sind die 15% schnell geladen und der Rest entfleucht ins Netz. Das will ich verhindern und halte den SoC bei "UpSoC", bei mir im Test 50%. Dadurch ist immer genug "Luft". Damit die Batteriepflege aktiviert werden kann, kommt die beschriebene 30-Tage Logik zum Einsatz.

kask · 11 Dezember 2023, 12:16:32

Zitatenn man bei Victron z.B. aktuell 50% SoC hat und per Befehl MinimumSocLimit auf z.B. 90% stellt, startet Victron sofort durch starkes Nachladen aus dem Netz den Run auf den neuen SoC

Ahhhh. Das Hatte ich nicht probiert/hrausgefunden/bedacht. Minsoclimit erhöhen und Chargecurrent für den Ladestrom bestimmen. Wie einfach, genial! Danke

kask · 11 Dezember 2023, 12:20:35

Der Vorteil wäre auch das man so manuell vom hohen Batterielife Soc schneller wegkommt.
Vitron geht ja "nur" 5% pro Tag runter.

kask · 11 Dezember 2023, 13:00:07

Ob es so gut ist in einem Speicherverbund aus mehreren Speichern auf 50% zu gehen weiß ich nicht.
Ich beobachte bei mir nur das die Speicher auseinanderdriften was den SOC betrifft.
Da diese nicht auf die 100% kommen wird der SoC auch nicht "Kalibriert".
Und bei 50% kommt man nicht oft zum kalibrieren, zumindest bei mir hier gerade mit dem Wetter. Gilt zu prüfen ob die 30 Tage optimal sind.
Das wird aber vermutlich von Speicherverbund zu Speicherverbund unterschiedlich sein. Somit sollte man die 30Tage anpassbar machen.
So kann sich jeder seinen Interval selber festlegen.Eventuell könnte man das auch dynamisch machen um weniger strom aus dem Netz zu kaufen.
z.B. Nach X Tagen ohne fully charged state wird der upsoc um Y % erhöht bis wieder einmal der fully charged state aufkam, dann wieder auf den definierten upsoc.
Also ohne Zwangsladen. So eine art Hybrid zum BatterieLife verfahren.
Da speise ich doch lieber 5kWh ein anstatt mir z.b. 10kWh alle 30(X) Tage zu kaufen im worst case.
Ist halt eine Ansichtssache, was wie wer will.

DS_Starter · 11 Dezember 2023, 13:40:24

Hallo kask,

danke fürs mitdenken und deinen Input.

ZitatDer Vorteil wäre auch das man so manuell vom hohen Batterielife Soc schneller wegkommt.
Vitron geht ja "nur" 5% pro Tag runter.

Genau, das ist Teil des Plans.

ZitatOb es so gut ist in einem Speicherverbund aus mehreren Speichern auf 50% zu gehen weiß ich nicht.
Ich beobachte bei mir nur das die Speicher auseinanderdriften was den SOC betrifft.

Ja, die driften auseinander wenn eine Teit lang kein SoC > 90% (bei Pylontech) erreicht werden. Es gibt wohl einen Industriestandard der auf 3,6V abgestellt ist. Deswegen das zyklische Aufladen auf SoH.

ZitatGilt zu prüfen ob die 30 Tage optimal sind.

Absolut. Eine Einstellbarkeit des Wertes werde ich vorsehen.

ZitatEventuell könnte man das auch dynamisch machen um weniger strom aus dem Netz zu kaufen.
z.B. Nach X Tagen ohne fully charged state wird der upsoc um Y % erhöht bis wieder einmal der fully charged state aufkam, dann wieder auf den definierten upsoc.
Also ohne Zwangsladen. So eine art Hybrid zum BatterieLife verfahren.

Genau so ist es zur Zeit implementiert.
Konkret gibt es ein Attribut zur Aktivierung der SoC Optimierung. Hier die momentane Hilfe dazu:

ctrlBatSocManagement <unterer MinSoC>:<oberer MinSoC>:<SoH>
Sofern ein Batterie Device (currentBatteryDev) installiert ist, aktiviert dieses Attribut das Batterie SoC-Management. Dadurch wird das Reading Battery_OptimumTargetSoC erstellt.
Dieses Reading kann zur Steuerung des SoC im Batterie Device verwendet werden.
Anzugeben sind:

unterer MinSoC    Die Batterie wird nicht tiefer als dieser Wert entladen (>= 0).
oberer MinSoC    Die Berechnung des optimalen SoC bewegt sich zwischen "unterer MinSoC"
   und diesem Wert.
SoH    State of Health, die maximal verfügbare Batteriekapazität (<= 100)

Alle Werte Angaben sind ganze Zahlen in %. Dabei gilt: 'unterer MinSoC' < 'oberer MinSoC' < 'SoH'.
Die Ermittlung des optimalen SoC erfolgt nach folgendem Schema:

-    Ausgehend von 'unterer MinSoC' wird der SoC am folgenden Tag um 5%, aber nicht größer als
   'oberer MinSoC' erhöht, sofern SoC am laufenden Tag SoH nicht erreicht hat.
-    Wird am laufenden Tag SoH (wieder) erreicht, wird SoC um 5%, aber nicht unter 'unterer MinSoC', verringert.
-    SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages
   von der Batterie aufgenommen werden kann. SoC wird nicht tiefer als 'unterer MinSoC' verringert.
-    Das Modul erfasst den letzten Zeitpunkt am SoH-Level, um eine Ladung auf SoH mindestens alle 30 Tage zu
   realisieren. Zu diesem Zweck wird der optimale SoC in Abhängigkeit der Resttage bis zum nächsten
   30 Tage Punkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung SoH am 30Tage Punkt erreicht
   wird. Wird zwischenzeitlich SoH erreicht, beginnt der 30 Tage Zeitraum erneut.

Beispiel:
attr <name> ctrlBatSocManagement 10:50:100

Sicherlich werde ich die Syntax noch umbauen in das Key-Prinzip wie bei den Consumern. Macht sich einfach besser.

ZitatDa speise ich doch lieber 5kWh ein anstatt mir z.b. 10kWh alle 30(X) Tage zu kaufen im worst case.
Ist halt eine Ansichtssache, was wie wer will.

Völlig richtig. Es gibt ein weites Spektrum der Verfahren und sicherlich auch von dem Batterietyp und dem Produkt abhängig.
Deswegen werden die Rahmenparameter anpassbar sein und im Ergebnis wird auch "nur" ein Reading mit dem Optimal SoC Vorschlag erstellt ohne direkt in das Batteriesystem einzugreifen.

Das bleibt jedem selbst überlassen ob/wie er diesen Vorschlag nutzt, z.B. ganz simpel per Notify abgreifen und an die Bat übertragen oder hier im Modul in der ctrlUserExitFn per Code aufnehmen und mit weiteren Verknüpfungen entscheiden was man wann an die Bat übertragen will.
Es ist ein weites Feld, aber ich versuche einen Standard zu definieren der nach Gusto angepasst werden kann.

kask · 11 Dezember 2023, 15:06:05

SoH = State of Health
SoC = State of Charge

Ich will nicht klugscheissen aber:
Der SoH ist die momentane verbleibende maximale Kapazität vergliechen zur Maximalen Designkapazität vor IBN bzw. bei den aller ersten Ladezyklen.
Somit der Alterungsindikator der Batterie in Prozent.
Ein SoC von 100% kann auch bei 80% SoH anstehen.
Bei meinen Batterien ist es so das diese, wenn diese nicht auf 100 % SoC geladen werden in 24h mit minimal einmal laden in der Zeit, der SoH um 0.02% pro Tag dekrementiert wird.
Ob das Sinn macht ist für mich auch noch Fraglich.

Was der SoC ist erläutere ich mal nicht. Das is ja eigentlich Sonnenklar.

Ich vermute mal das sind alles Tippfehler in deiner Beschreibung.

Die 3,6V ist annähernd die maximale Ladespannung der Einzelzelle/Einzelzellenverbund. Dieser wird vermutlich auf 3,6V bei dem Pylontech stehen da noch etwas Luft zum balancen bleiben muß im die Zelle nicht in die Überspannung zu schicken und somit die Zellchemie zu zerstören.
Die 3,6V sind somit Zellen/Hersteller/Typ anhängig.

Und da bei dir die Zellen stabil angeglichen bleiben wenn du nur >90% aber nicht annähernd 100% SoC hast, dann hast du einen guten Speicher erwischt.
Früher oder später kommt immer ein Drift wenn die zellen nicht in das balancing fahren. Und bei 90% zu balancen ist ja fast Sinnfrei.
Dann würde man doch eher die Designkapazität ändern um bei echten 90% 100% angezeigt zu bekommen.
Ich kann mir nicht vorstellen das pylontech bei 90% das balancen anfängt. Es sei den der gesamte zellenverbund hat einen drift von 80-100% und zeigt dir 90% an.
Dann würden die 100% Zellen (3,6V) sicher balancen. Aber dann wäre dein Speicher eine Vollkatastrophe.

DS_Starter · 11 Dezember 2023, 15:55:31

ZitatDer SoH ist die momentane verbleibende maximale Kapazität vergliechen zur Maximalen Designkapazität vor IBN bzw. bei den aller ersten Ladezyklen.
Somit der Alterungsindikator der Batterie in Prozent.
Ein SoC von 100% kann auch bei 80% SoH anstehen.

Ja das ist klar. Nur habe ich bewusst SoH gewählt, damit bei einem Bat-System, welches aufgrund seines Zustandes nicht mehr auf 100% SoH kommt, bei der Berechnung der verschiedenen Differenzen zur Steuerung nicht von einer (nicht mehr) richtigen installierten Kapazität ausgegangen wird.

Bei dem ganzen Vorhaben gibt es dann auch im currentBatteryDev auch einen Schlüssel cap=BatCap:<Einheit> mit dem mir die Installierten Batteriekapazität mitgeteilt wird sonst könnte ich nicht mit den Prozenten agieren. Diese cap ist defacto 100% SoH im Neuzustand.

Möglicherweise muß ich das nochmal überdenken, erscheint mir momentan aber schlüssig.

Zu dem Thema Balancing des Verbundes habe ich mal ein SVG angehängt. Es werden die Batterien einzeln ausgelesen (4 Stck) und geloggt.
Man sieht ziemlich deutlich wie die Batterien auseiandergedriftet sind, da sie längere Zeit bei 50% betrieben wurden. Dann wurden sie ordentlich geladen und genau bei 90% setzte der Ausgleich ein, danach ging es wieder "gemeinsam" weiter.

ch.eick · 11 Dezember 2023, 16:04:50

Hallo zusammen.

Bei mir habe ich es mir da mit dem Speicher recht einfach gemacht.

1. Anhebung des MinSoc im Winter auf 10% nach Hersteller angabe.
2. Bei erreichen des MinSoc und schlechter Leistungsprognose sperre ich den Speicher gegen entladen.
3. Wird dann ein Soc von > 90% erreicht wird der Speicher wieder freigegeben und das Spiel beginnt von neuem.

So passiert es dann bei schlechtem Wetter, dass es mehrere Tage braucht, bis der Speicher mal wieder voll ist. Dann kommt die realität und der Haushalt mit WP leert leider ziemlich schnell den Speicher wieder. Der Vorteil ist ich habe keine Notladungen mehr und bekomme auch im Winter meine Vollzyklen, wodurch die Soc Berechnung auch recht stabiel funktioniert.

Und immer wieder frage ich mich, was das alles mit der Leistungsprognose in diesem Thread zu tun hat?
Es wäre echt besser das mal richtig zu trennen.

1. Leistungsprognose und nichts mehr
2. Eigenverbrauchsteuerung mit Zugriff auf das separate Leistungsprognose Device
3. Das neue Thema Speicher Steuerung

@Heiko... Jetzt bitte Dein Ach Christiaaaaan

VG Christian

ch.eick · 11 Dezember 2023, 16:07:25

Wie kann ich den den SOH selber bestimmen, um z.B. mal das E-Auto zu checken, da habe ich noch 5 Jahre Gewährleistung auf den Accu und möchte schnell reagieren können.

DS_Starter · 11 Dezember 2023, 16:35:37

Zitat@Heiko... Jetzt bitte Dein Ach Christiaaaaan

Ach Christiaaaaan ....

ZitatEs wäre echt besser das mal richtig zu trennen.

Kann jeder machen wie er das möchte. Ist niemand gezwungen das Modul zu nutzen und nur ein Angebot daran zu partizipieren.

Benenne den Thread einfach um in SolarForecast und mehr.

DS_Starter · 11 Dezember 2023, 16:43:58

@Christian,

ZitatWie kann ich den den SOH selber bestimmen, um z.B. mal das E-Auto zu checken, da habe ich noch 5 Jahre Gewährleistung auf den Accu und möchte schnell reagieren können.

Kann ich dir nicht sagen. Victron spuckt den Wert als MQTT Topic aus.

Aber ich habe etwas gefunden für EV (https://aviloo.com/newsreader/soh-batteriegesundheitszustand-was-bedeutet-das-eigentlich.html):

Der Grundlagen der Analyse:

Gesundheitszustand (SoH) wird mittels aufwändiger Berechnungen, Algorithmen und Modellen berechnet. Zwei wichtige Faktoren, die in der Berechnung berücksichtigt werden, sind die Temperaturkompensation und die Entladeratenkompensation (Art der Fahrweise).
Um eine Temperaturunabhängigkeit während des Batterietests zu gewährleisten, wird jedes Messergebnis auf eine Batterietemperatur von 25°C kompensiert.
Um eine Entladeratenunabhängigkeit während des Batterietests zu gewährleisten, wird jedes Messergebnis auf eine entsprechend dem WLTP Zyklus typische Entladerate kompensiert.
Beispiel:

Die gemessene Batteriekapazität (100% bis 0% gemäß Display) für ein Automodell ist 60 kWh, das ist der Wert für ,,Energieinhalt Neuzustand".
Bei dem AVILOO PREMIUM Test sind nur noch 54 kWh entnehmbar, das ist der Wert für ,,Energieinhalt jetzt".
54 kWh / 60 kWh = 0,9 * 100 = 90%
Das bedeutet, der SoH dieser Batterie beträgt noch 90% im Vergleich zum Neuzustand.