ich wollte eine interessante Beobachtung aus meiner PC Anlage (Victron ESS) teilen und einige Einsichten oder Vorschläge aus der Community sammeln. In meinem aktuellen Setup habe ich zwei Batterien parallel geschaltet, wobei ein Aggregator genutzt wird, um Werte wie Maximal-Ladespannung und -strom für das Gesamtsystem zu steuern.
Die obere Grafik in meinem System zeigt, dass beide Batterien dieselbe Spannung halten, was zu erwarten ist. Interessanterweise wird der "Max Charge Current", also der maximale Ladestrom, vom "dbus-serialbattery" berechnet und durch den BatteryAggregator auf das Gesamtsystem angewendet. Was ich jedoch beobachtet habe, ist, dass unter bestimmten Umständen eine der Batterien mehr Strom aufnimmt als eigentlich für sie berechnet wurde. Dies geschieht, wenn der Aggregator die Summe der Ströme berechnet, während die erste Batterie keinen Strom mehr aufnimmt, da sie voll geladen ist.
Das Resultat ist, dass die zweite Batterie effektiv mehr Ladestrom erhält, als für sie allein berechnet wurde. Dies könnte potenziell zu einer Überlastung führen, wenn nicht durch das BMS entsprechende Anpassungen vorgenommen werden.
Ich frage mich, ob jemand ähnliche Erfahrungen gemacht hat und wie ihr solche Situationen in euren Systemen handhabt. Ist es üblich, dass der Aggregator in einem parallelen Setup die Ströme nicht individuell anpasst, wenn eine Batterie ihre Ladekapazität erreicht hat? Welche Sicherheitsmechanismen oder Software-Updates würdet ihr empfehlen, um solche Probleme zu vermeiden?
-2- Innenwiderstand der Akkus. Wenn der Innenwiderstand beider Akkus nicht gleich ist, wird auch unterschiedlich geladen.
Die Kabeldicke sollte auch nicht unterschiedlich sein. Wenn man dann zudem Akkus mit unterschiedlichem BMS einsetzt, wird es schwer das Verhalten nicht zu haben, dass ein Akku mehr Strom abbekommt.
Solange man pro Akkupack ein eigenes gutes BMS hat, würde ich bei geringen Unterschieden keine Probleme erwarten. Man sollte aber nicht auf die Idee kommen nur ein BMS für mehrere parallelen Akkus zu verwenden..........
Ich muss bei mir auch noch nachbessern. Bei mir stimmen die Kabellängen auch noch nicht. Ändere ich im Sommer, wenn ich den einen Akku umrüste, damit beide das gleiche BMS haben.
ich habe 3 Batterien parallel je 24V 320Ah mit jk-BBS. Sie sind identisch und haben recht lange Anschlussleitungen ca. 1,2m mit 35mm². Die Ströme verteilen sich nicht ganz gleichmäßig. Das stört mich aber nicht. Ich lade nur mit einer Zellenspannung von 3,41V. Float habe ich auf 3,325V gestellt. Damit ab und zu balanciert wird, nutze ich "load_to_SOC_reset" mit 3,48V. Leider übernimmt Batteryaggregator die niedrigste Spannung der Parameter, so dass die Spannung auf float fällt, bevor die anderen Batterien die jeweilige Phase erreicht haben. Bei der niedrigen Spannung wäre es viel besser, wenn erst auf float reduziert wird, wenn alle Batterien die Phase erreicht hätten. Batteryaggregator müsste also die höchste Spannung aus den Parametern anwenden.
auch in meiner Installation sind die Kabellängen identisch und auch ca. 1,2m lang mit 70mm² Querschnitt. Die Sammelschiene ist etwas überdimensioniert massiv. Diese Tatsache ist mir an einem sonnigen Tag ausgefallen, die die Sonne richtig prallte, so hatte ich die Stromstärke an einer Batterie bei ca. 85A.
Das liegt zwar in einem absolut sicheren Bereich, jedoch im Kopf hatte ich die Vorstellung, dass wenn ich 2 Batterien parallel habe und insgesamt vom Dach ca 120 Am kommen, so sollte eine Battery so ziemlich die Hälfte abbekommen. Nun habe ich etwas Besseres gelernt. Das wird an Bedeutung mehr haben, wenn man mehr Akkus im parallel Betrieb hat und die Leistung der PV Anlage groß ist. So kann es werden dass mehrheit der Akkus schon voll sind, und das arme langsame Akku richtig viel Energie abbekommt. (Klar BMS wird dann eingreifen, dazu sollte es jedoch nicht kommen). Eventuell kann diesen Fall der Aggregator berücksichtigen und in diesem Fall nicht blind die CCLs der Akkus aufsummieren. Das muss man überlegen ob und wie sich das umsetzen lässt.
@r-l ja, damit bin auch sehr happy. Zusätzlich den BatteryAggregator als "control BMS" in DVCC und smartshunt als Quelle für SOC des Systems und Strom/Spannung sence.
Der Treiber macht an der Stelle Alles richtig. Wenn hier überhaupt ein Handlungsbedarf gibt, dann scheint mir, dass der BatteryAggregator dafür als zuständige Modul zu sehen wäre. Aber, wie gesagt, das betrifft nur wenigere PV Installationen, wo die Jungs und Mädels normalerweise wissen schon was sie tun.
Das ist das Coole daran, dass alle Komponenten (Treiber, Venus, Aggregator) sie alle arbeiten absolut korrekt. Jedoch unter Umständen kommt das zum "unerwartet" hohen Stromaufkommen bei dem oder (den wenigeren) langsamsten Akkus.
Der Batteriyaggregator müsste wohl erkennen, wieviel Strom die anderen Batterien nicht mehr abfordern und den Gesamtstrom um diesen Betrag senken. Bei mir sind einige Sachen merkwürdig: Ich habe 3 Batterien und einen Smartshunt für den Gesamtstrom. In Batteryaggregator werden aber 4 Batterien angezeigt. Der Shunt ist im Aggregator ebenfalls eine Batterie und sein Strom vom wird doppelt angegeben. Mir ist es nicht gelungen, den Shunt mit
auszuschließen. Bei mit tritt der Shunt aber mit "ttyUSB04" auf. Es ändert sich nichts. Wenn ich den Raspberry neu boote, wird der Shunt dann einer anderen Adresse , zum Beispiel " ttyUSB02" zugeteilt.
Dazu kannst du ja einen Issue in GitHub eröffnen. Die Jungs sind sehr willig und fix in Sachen Optimierung und Fehlerbeseitigung. Hatte zuletzt auch einen Bug aufgedeckt, dass die Ladeschlussspannung aus der config.ini ignoriert wurde und stattdessen der Wert der CellOverVoltageProtection direkt aus dem BMS als Ladeschlussspannung genommen wurde.
@hf_spsler ... Kommando zurück, ich hatte bei mir eine uhralte Version vom BatteryAggregator. Fazit für mich: Je mehr wir uns Features und Modules installieren, desto mehr müssen wir aufpassen und regelmäßig Updates und Patches einzuspielen. In der Aktuellen Version sieht Alles viel besser aus. Ich beobachte das weiter und melde mich, wenn es interessante Aspekte auftauchen.
Ich habe gerade gesehen, dass heute ein update auf V3.0.63 rausgekommen ist. Ich konnte aber keine Veränderungen feststellen. Wieviele Batterien werden bei dir angezeigt? Wenn eine Batterie in "float" geht, wird das in Serialbattery unter Parameters mit geringerer Spannung angezeigt. Wird diese niedrigere Spannung bei dir auch in Batteryaggregator übernommen? (Dann kann die andere Batterie nicht in float gehen). Wird bei dir auch der doppelte Strom den Shunt in Batteryaggregator angezeigt?
Ja, sobald eine Batterie in Float geht, wird Aggregator CVL (unten rechts in grün) entsprechend reduziert. Hier wäre richtiger zu deuten, dass das gesamte System in Float Mode geht, getriggert von der ersten Batterie, welche meint, "es reicht mir, ich bin voll". Das ist m.e. Ok so.
@ogurgurpv Das kann nicht O.K sein. Außer man lädt bis zum Anschlag. Bei unseren moderaten Ladespannungen kann die Spannung ruhig einige Zeit höher sein (sie ist ja nicht kritisch hoch) damit die andere Batterie ebenfalls die gesamte Ladephase durchläuft. Der Strom in der ersten Batterie sinkt dabei fast auf null. Insbesondere zum balancieren ist das wichtig.
@r-l zu diesem Zeitpunk ist der Strom auch bei der anderen Batterie auch bereits fast 0 oder im Promillen- Bereich. Die Grafik zeigt deutlich, dass um 11:22 der Strom bei beiden Akkus kaum mehr lief.
Der BatteryAggregator lässt, glaube ich, dieses Verhalten ändern, wenn man andersrum zu Gunsten der "hungrigen" Batterie die Schnelle lieber "braten" lassen möchte. In der Beschreibung gibt es den Parameter: "cvlMode": "min_when_balancing"
Die Energiemenge die die langsame Batterie in diese Zeit aufnehmen ist nicht kriegsentscheidend. Zusätzlich, solange die Sonne scheint, bleiben die Akkus im Float Mode gut bedient.
@ogurgurpv Ich nutze auch "Load_to_SOC_Reset". Das funktioniert für die erste Batterie gut. Die anderen werden dann aber nicht mehr bedient. Ich hab bei Pulquero mal eine Anfrage gemacht.
@r-l "Load_to_SOC_Reset" fand ich als ein unglücklicher Workaround, was eigentlich dem Sinn des Treibers widerspricht.
Salop formuliert es ist nicht die Aufgabe des Treibers die Batterie ab und zu ein wenig anbraten lassen, damit des SOC auf 100% gesetzt wird.
Wenn man SmartShunt im System einsetzt, dann ist die SOC vom JK BMS nur so ein Wert zum Dekorations- Zwecken. Er wird nirgend wo im System verwendet.
Es ist sehr gut, dass die neue Version vom JK Inverter diese Funktionalität mitbringt. Wenn das neue BMS auch die CVL und CCL in DBus veröffentlicht, wäre gut zu wissen wie "sanft" oder wie er das rechnet. Da an der Stelle wäre gut etwas mehr Transparenz. (Quelltext auf dem Github z.B.)
Das JK-BMS lässt sich ausschließlich durch Over_Voltage_Protection auf 100% setzen. Deshalb hat man es in den Treiber integrieren müssen. Bei meiner Anlage zeigen die BMS ohnehin einen zu hohen SOC an, so dass ich das gar nicht dafür nutzen muss. Eigentlich will ich die Möglichkeit des Zeitplanes nutzen, um das Balancieren bei niedriger Spannung durchzuführen. Dafür habe ich die SOC_Reset_Voltage in Serialbattery auf 3,46 gesetzt. Beim Balancieren werden dann keine 3,5V erreicht, weil Serialbattery die Spannung senkt, um die Zellendifferenz zu begrenzen. Der Strom sinkt dabei auf unter 1A. Als "anbraten" würde ich die niedrige Spannung nicht bezeichnen. Insbesondere wenn das nur alle 14 Tage geplant wird. Die Max_Cell_Voltage habe ich auf 3,41V und die Float_Cell_Voltage auf 3,325V gestellt. Beide solle aber noch etwas runter, weil die Batterien im Sommer fast immer am Anschlag sind.
Dennoch aus Systemsicht überwiegen für mich die Nachteile aus solchem Vorgehen:
Falls ein SmartShunt eingesetzt wird, werden SOCs aus dem JKBMS und im ggf. BatteryAggregator nirgendwo im VenusOS verwendet. Wozu überhaupt muss man sich um diese Werte kümmern ? Es ist keine sachliche Notwendigkeit, sondern vom Gefühl, es wäre schön, dass der Wert etwas Richtigeres anzeigt.
[quote data-userid="31317" data-postid="212425"]
Das JK-BMS lässt sich ausschließlich durch Over_Voltage_Protection auf 100% setzen
[/quote] JK BMS hat an der Stelle einen Fehler (da fehlt die korrekte Funktionalität) verursacht. Die Frage ist warum muss eine Andere Komponente diesen Bug korrigieren ? Die Fehler sollten immer an der Stelle behoben werden wo sie entstehen. Die primäre Ausfgabe des DBus-serialbattery Treibers ist die Übergabe der Daten aus der über die serielle Schnittstelle angeschlossenenen Batterien nach DBus zu übertragen. Das zurücksetzen von SOC ist einfach nicht seine Aufgabe (IMHO). Zusätzlich, mit der intelligenten Berechnung der CVL Werte sorgt der Treiber für Langlebigkeit der Batterie in dem er die Überspannungen der Cellen vermeidet.
Das Aktivieren der Option "Reset SOC Funktionalität" vernachlässigen wir die Langlebigkeit der Batterie und tauschen Das gegen Einstellung eines Wertes, der nicht gebraucht wird.
Es kann sein, dass ich mich irre. (keep it simple und never touch a running system )
