Diskussion über Stromverteilung und Aggregatoren in parallelen Batteriesystemen

[r-l]

Wie gesagt: Mir ist der angezeigte SOC (fast) egal. Ich benutze den Load_to_SOC_Reset auch nicht zu diesem Zweck. Da ich die Spannungen möglichst niedrig halten möchte, muss ich aber hin und wieder auf mindestens 3,47V laden, damit sich unbalance überhaupt deutlich zeigt und bearbeitet werden kann. Würde man daas nicht machen, würde sich die unbalance so weit aufsummieren, dass schon bei recht geringem SOC eine Zellenspannung auf über 4,45V steigen würde. Das dann regelmäßig und für eine große Zeitspannen. Die Anzahl der Batterien und der Strom im Batteryaggregator stimmen jetzt übrigens. Pulquero hat mich drauf gebracht: Ich hatte den Text ohne geschweifte Klammern in die Datei geschrieben.

Das eigentliche Problem kann man so sehen: Zwei parallel geschaltete Bleibatterien mit je einem Stromsenssor werden von einem Ladegerät geladen. Ist die Spannung von xxV erreicht und der Strom ist auf einen definierten Wert gefallen, dann darf das Ladgerät noch nicht auf Float umschalten. Es muss auch bei der zweiten Batterie der Strom auf den definierten Wert gefallen sein. Sonst ist diese Batterie nicht richtig geladen. In meinem Fall wäre nur ein der Batterien fertig balanciert.

[ogurgurpv]

Das eigentliche Problem kann man so sehen: Zwei parallel geschaltete Bleibatterien mit je einem Stromsenssor werden von einem Ladegerät geladen. Ist die Spannung von xxV erreicht und der Strom ist auf einen definierten Wert gefallen, dann darf das Ladgerät noch nicht auf Float umschalten. Es muss auch bei der zweiten Batterie der Strom auf den definierten Wert gefallen sein. Sonst ist diese Batterie nicht richtig geladen. In meinem Fall wäre nur ein der Batterien fertig balanciert.

Korrekt. Der Übergang in den Float Mode sollte nicht nach dem Stromabfall erfolgen.

Die BatteryAggregator und Dbus-serialbattery sind sehr gute Lösungen. ... werde nich müde an die Jungs den Lob und Dank zu richten.

Wenn ich die Abläufe richtig deute. Das ESS System kontrolliert die Ladegäte (external Control) und teilt an sie die resultierende CVL aus.

Die resultierende CVL kommt (bei einer Baterie) direkt von Batterie CVL (wenn über CAN) oder dem dbus-seirailbattery. In Falle von N- Batterien übernimmt BatteryAggregator die Aufgabe aus mehreren Quellen den System CVL zu aggregieren.

Jede Batterie mit ihrer Treiber- Instanz ist für sich selbst zuständig. Sobald die Bedingungen zum Absolvieren der Absorbtion Phase in einer Batterie erfüllt sind, beginnt der Float Mode. Das wird nach außen durch eigenen CVL und eigenen Status signalisiert.

Bei mehreren Batterien in Parallel startet der Absorption Modus ungefähr zur selben Zeit. In der Absorption Phase sinkt der Strom ab.

Im dbus-serialbattery gelten die Bedingungen für den Übergang in Float a) das Erreichen und erhalt (Dauer- MAX_VOLTAGE_TIME_SEC) einer bestimmten Spannung und b) dass die Differenz der Spannung zwischen Cellen innerhalb eines Wertes verbleiben.

Je nach Wetterlage, aktuellen Verbrauch und PV - Größe variiert sich in der Relegen das Dauer der Absorption. In der Regel sieht man auf einer Grafik wie lange das dauert.

Kann man bei Dir auf der Grafik diese Abschnitte erkennen ? Geht das System tatsächlich in Folat Mode hierüber sobald der Strom an einer Batterie abnimmt ?

[r-l]

Geht das System tatsächlich in Folat Mode hierüber sobald der Strom an einer Batterie abnimmt ?

nein, es gibt noch eine Wartezeit, die erst ablaufen soll. Es wurde dazu geraten diese Zeit zu verlängern. Das ist aber nicht die Ursache. Ich habe ein issu bei Pulquero geöffnet: select the highest CVL in Multible Batterie Systems · Issue #56 · pulquero/BatteryAggregator · GitHub

Mein Englisch ist nicht ausreichend. Hälst du das für verständlich?

[r-l]

An deiner Ladekurve trennen sich die Ladeströme um ca. 7:45Uhr. kann es möglich sein, dass gurgur-2 ab da balanciert hat? Der Ladestrom dürfte zu der Zeit wohl bei 25A pro Batterie gelegen haben. Wenn ungleichmäßige Innenwiderstände plus Übergangswiderstände für genügend Spannung gesorgt haben, könnte das unberechtigter Weise stattgefunden haben. Und es führt am Ende dazu, dass das mit erhöhter Stromaufnahme am Ende der Ladung wieder rückgängig gemacht werden muss. Wie hoch hast du die Startspannung und die Differenzspannung eingestellt?

[ogurgurpv]

... ich hatte die KI ein wenig angestrebt, sie/es/er schägt gute Formulierung vor:

Ist es nicht der Parameter was hier beschrieben ist ?

GitHub - pulquero/BatteryAggregator

Die Variante der Anfrage:

Der von dir beschriebene Beitrag ist größtenteils verständlich, jedoch könnte die Formulierung etwas klarer und präziser sein, um Missverständnisse zu vermeiden. Der Satz „because I want to reduce the Voltage as much as possible“ scheint etwas deplatziert, da das Hauptziel des Beitrags die Anpassung der Auswahl der Batteriespannung durch den Batteryaggregator ist, nicht unbedingt die Reduzierung der Spannung an sich.

Hier ist eine alternative Formulierung, die etwas klarer sein könnte:

---

RPi 4 Setup: DVCC? Yes

I am currently using a setup with three 24V/300Ah battery banks equipped with JK-BMSes, all connected in parallel. My primary goal is to ensure that all batteries can complete absorption, balancing, or reach the Load_to_SOC_reset state effectively. Currently, the Batteryaggregator selects the lowest CVL (Charge Voltage Limit) from the batteries, which might not be optimal for my system.

Could it be possible to introduce a switch or setting in the Batteryaggregator that allows for the selection of the highest CVL instead? This change would help in making sure all batteries are adequately managed during their charge cycles.

---

Diese Formulierung präzisiert, was geändert werden soll (Auswahl der höchsten statt der niedrigsten CVL) und warum diese Änderung benötigt wird (um sicherzustellen, dass alle Batterien ihre Ladezyklen effektiv abschließen können). Es entfernt auch den etwas verwirrenden Teil über das Reduzieren der Spannung, was den Fokus klar auf die Funktionalität des Batteryaggregators legt.

4

[ogurgurpv]

[quote data-userid="31317" data-postid="212546"]
An deiner Ladekurve trennen sich die Ladeströme um ca. 7:45Uhr. kann es möglich sein, dass gurgur-2 ab da balanciert hat? Der Ladestrom dürfte zu der Zeit wohl bei 25A pro Batterie gelegen haben. Wenn ungleichmäßige Innenwiderstände plus Übergangswiderstände für genügend Spannung gesorgt haben, könnte das unberechtigter Weise stattgefunden haben. Und es führt am Ende dazu, dass das mit erhöhter Stromaufnahme am Ende der Ladung wieder rückgängig gemacht werden muss. Wie hoch hast du die Startspannung und die Differenzspannung eingestellt?

[/quote] ... ich prüfe, welche Werte sind bei mir eingestellt. Die unterschiedliche Ströme an der Stelle sind erklärbar dass in der Tat die Batterien nicht 100% identische Innenwiderstände haben und dem entsprechend Kapazität. In der Theorie haben sie gleiche Parameter, in der Realität unterscheidet sich jeder Akkupack von den anderen. Das ist auch meiner Sicht unbedenklich. Die Werte in BMS checke ich heute Abend ...

[r-l]

Danke, das hört sich viel besser an. Ich hänge es dort mal an!

[ogurgurpv]

so sehen die für Balance relevanten Einstellungen bei mir aus.

[r-l]

Deine Start Balance Voltage ist viel zu niedrig eingestellt. Selbst wenn die Batterien schlecht balanciert sind kann da überhaupt keine Spannungdifferrenz entstehen, die allein vom SOC abhängt. Ich habe festgestell, dass es in dem Bereich fast ausschließlich stromabhängige Spannungen von Innenwiderständen und Übergangswiderständen sind. Die fallen natürlich verschieden aus und lassen den Balancer aktiv werden. Insbesondere bei den höheren Entladestömen passiert das auch! Als ich die Grafik genauer angeschaut habe, hab ich sogar auf diesen niedrigen Wert getippt. Bei mir sank der Ladestrom immer ab, sobald eine Batterie voll war. So haben sie sich nie angeglichen. Dann ist mir klar geworden, dass Serialbattery die Spannung senkt um die Differenz der Zellen zu begrenzen. Dabei wurde dann die Zeit erreicht um auf "Float " zu reduzieren. Aber auch eine Größere Zeitspanne war dafür nicht Zielführend, weil der Vorgang nicht durch Entladung unterbrochen werden soll. Und dann kommt die Dämmerung dazwischen. Dann habe ich das mal genauer bei sehr geringen Ladeströmen (wetterbedingt) untersucht als die Batterien annähernd voll waren. Die Spannungen laufen erst bei einer Spannung von 3,47V so deutlich auseinander, dass Spannungen durch Innenwiderstände bei Strömen bis etwa 15A nicht mehr dominieren. Serialbattery versucht, die Zellendifferenz auf unter 10mV zu bringen. Das setzt natürlich voraus, dass schon bei einer Zellendifferenz von 5mV balanciert werden muss. Die hatte ich vorher wegen der stromabhängigen Spannungen wesentlich höher gestellt. Der Balanciervorgang läuft natürlich nicht verlustfrei ab. Deshalb waren die Ladeströme der Batterien am Ende auch so verschieden. Das ist jetzt viel besser geworden.

[ogurgurpv]

@r-l hier sind viele Dinge durcheinander gemischt.

dass Serialbattery die Spannung senkt um die Differenz der Zellen zu begrenzen

• dbserial-buttery reduziert CVL im (beim lineal mode) im Absorption, nur wenn er merkt dass die Spannung der einzelnen Zellen dem maximalen eingestellten Wert übersteigt. Nur diese übersteigende Deltas werden aufsummiert (siehe penalty voltage im code) und um diesen Wert wird CVL reduziert. Das ermöglicht eine schonende Absorption für Batterie.

Sehr gute andere Frage, ob so etwas Ähnliches in den Hersteller BMS Treibers wie z.B. beim neuen JK BMS Inverter umgesetzt ist. Das ist eine Alleinstehendes Merkmal des Treibers. 😍

• Start Balance Voltage - hier spielt es keine signifikante Rolle wann der Balancer beginnen soll. Zu einem es ist nicht schädlich und zum anderen, wenn die Zellen gleiche Spannungen haben, dann hat er auch nichts zu tun. Dieser Vorgang von Energie- Mengen, welche zwischen den Zellen geschoben werden steht in keinem Vergleich, wenn die Lasten im Haus angehen oder die Sonne kommt und geht. Das sind zwei absolut unterschiedliche Faktoren.
• Die Bedingungen, wann die Float Phase beginnt hatten wir oben früher schon genannt. Das ist wichtig zu verstehen und auseinander zu halten. a) bestimmter CVL Level erreicht, b) Zellenspannungdifferenz liegt im vorgegeben Bereich, c) dieser Zustand konnte über vorgesehene Zeit aufrechterhalten werden. Dann beginnt der Übergang ins Float (auch sanfte Absenkung von CVL auf Float Spannungswert um höhe unnötig Ströme zu vermeiden)

Die Spannungen laufen erst bei einer Spannung von 3,47V so deutlich auseinander

Viele von uns begrenzen dem MAX_CELL_VOLTAGE auf ca. 3.45 um die Batterie möglichst lange betreiben zu können. In den Hersteller- Grafen der Spannungen ist es schon ausserhalb des flachen Bereichs. Also das ist schon ein Grenzbereich. Für PV Anwender gibt es keine Notwendigkeit noch höher zu laden. Die Energiemenge, welche dabei ins Akku geladen wird liegt im Promillen- Bereich. Schonung der Batterie ist wichtiger. Im einem Camper oder einem Boot gelten andere Prioritäten und Gegebenheiten. Dort Lebenszeit der Batterie hat ehe sekundäre Bedeutung.

Serialbattery versucht, die Zellendifferenz auf unter 10mV zu bringen

... tut er nicht, er lässt Zeit damit das Balancer tut, oder die Zellen sich ausgleichen, so etwas kann der Treiber auch nicht. :) /p>

Das Thema ist sehr interessant und spannend. Um Überblick im Auge zu behalten, kann man ein Aspekt auswählen, formulieren was der Umstand ist und was das Ziel ist. Dann strukturiert findet sich die Lösung fast von alleine.

[strex]

Start Balance Voltage - hier spielt es keine signifikante Rolle wann der Balancer beginnen soll. Zu einem es ist nicht schädlich und zum anderen, wenn die Zellen gleiche Spannungen haben, dann hat er auch nichts zu tun. Dieser Vorgang von Energie- Mengen, welche zwischen den Zellen geschoben werden steht in keinem Vergleich, wenn die Lasten im Haus angehen oder die Sonne kommt und geht. Das sind zwei absolut unterschiedliche Faktoren.

Das sehen andere Leute anders..: Link entfernt

youtube video: Exg6nqsRvlw

[ogurgurpv]

@strex jawohl, ich kenne die Videos vom Andy und finde sie sehr good, sehr cool und sehr informativ. Lob und Respekt. Dort vertritt er die Meinung dass es gut ist wenn Balancing im oberen Bereich stattfindet. Einer der Hauptargumenten dort ist dass im flachen Bereich die Spannung einer Celle wenig über den Ladezustand sagt, da (eben die Spannungskurve flach ist) und dass es dort kaum Sinn macht.

Ich sehe keinen Widerspruch zu dem dass es nicht schädlich wenn Balancing früher startet. Ich konnte keine Argumente finden, wo das nachteilig wird.

Desweiteren, werden die Tests unter Laborbedingungen durchgeführt, sprich während diesen Experimenten erfolgen keine signifikanten Entladeströme vor, wenn die Lasten zu- oder abschalten werden( mehrere kWatts ) oder die Ladeströme wo die Sonne kommt und geht. Wenn man sich die Daten unter diesen Bedingungen einsammelt und analysiert so kommt das Verständnis dass es nicht so wichtig ist, ab welchen Wert Balancing startet. Balancing gleicht die Spannungen der Zellen, nicht deren Ladezustand.

Nur so, um die Enegriemengen zu verstehen. Nehmen wir an, dass unsere Absorption Phase eine Stunde dauert, und auch dass in unseren Pack nur eine einzelne Zelle aubalanziert wird. Dann am ender der Absorption Phase haben wir (beim 2A Balancer) ganzen 2 A Stunden zu diese Zelle übertragen haben. Ist es viel ? bei 280 ah Gesamtkapazität der Celle.

[r-l]

Balancing gleicht die Spannungen der Zellen, nicht deren Ladezustand.

Wenn dort aber stromabhängige Spannungsdifferenzen auftreten, wird verucht, diese auszugleichen. Dabei ändert sich der SOC, obwohl er nicht zu besanstanden war. Dabei können auch mehrere Amperestunden zusammenkommen.

[ogurgurpv]

Das VRM Portal hilft ganz gut zu visualisieren, wie viele Amperstunden während Absorption Phase noch in die Batterie dazukommen.

In Advanced -> Battery Consumed Amphours

So hat es in meiner installation ausgesehen:

Welche Werte kannst Du bei Deiner Installation sehen ?

Eigentlich das ist ganz schon faszinierend, zu sehen, da werden Zellen ausgeglichen (Spannungen) Die Batterien sättigen sich und dann kommt das System ins Float ....

Das System nährt sich der Spannung 55.2 V, verlangsamt die Steigung, da ein Paar wenigen Zellen dem Max von 3.45 V übersteigen würden, lässt dem Balancer Zeit seine Arbeit zu verrichten und wärend die Zellen ausgegliechen werden steigt langsam Spannung des Systems auf 55.2V. Wenn jetzt Alles in Ordnung ist, dann wird Float eingeleitet (Wenn man das bei LiFePo unbedingt möchte)

[r-l]

Das sieht bei mir ganz ähnlich aus. Jetzt stehe ich aber erst mal vor dem Problem, das der Shunt in Batteryaggregator als Batterie betrachtet wird. Mit dbus-spy konnte ich sehen, dass er sich am Ende ttyUSB2 nennt also habe ich eine

/data/setupOptions/BatteryAggregator/config.json

angelegt und

{
"excludedServices": ["com.victronenergy.battery.ttyusb2"]
}

eingetragen. Das hat erst gar nicht funktioniert. Es lag wohl daran, dass ich keine geschweiften Klammern eingegeben hatte. Das nächste Problem war, dass der Raspberry beim reboot andere Ports zuweisen kann. Dann war es "ttyUSB4" oder "ttyUSB3". Das lässt sich wohl nur schwer lösen. Aber dann hat Pulquero die neueste Version mit

"cvlMode": "max_always"

ergänzt. Wenn ich das mit in die Datei schreibe, wird trotzdem die niedrigste CVL übernommen. Dann habe ich es ebenfalls mal mit geschweiften Klammern probiert. Aber ohne Erfolg. Was bei allen Versuchen gemeinsam war: Die Anzahl der Batterien stimmte dann wieder nicht. Der "ExcludedServices" wurde ignoriert. Weißt du, ob ein bestimmter Syntax eingehalten werden muss?

[ogurgurpv]

@r-l beachte bitte dort die Groß und Kleinschreibung es wird mit "excludedServices": ["com.victronenergy.battery.ttyS5"] - hier bitte Deinen Wert eintragen

Etwas ungewöhnlich dass SmartShut bei Dir mit "...USB..." genannt wird. Wenn er über ve.direct angeschlossen ist, sollte glaube ich wie ein terminal sein. Prüfe das bitte noch mal

[r-l]

Etwas ungewöhnlich dass SmartShut bei Dir mit "...USB..." genannt wird

Das hängt wohl davon ab, an welches Gerät er angeschlossen ist. Bei mir ist es ein Raspberry4 mit einem VE.direct to USB Interface Kabel (original Victron). Ich hab das Interface mal ausgelesen. Es ist ein "VE Direct cable" und passt zu folgender Zeile aus udev:

ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="VE_Direct_cable", ENV{VE_SERVICE}="vedirect"

[endurance]

Bei mir, aber ein Cerbo, sieht das so aus

{
"auxiliaryServices": ["com.victronenergy.battery.socketcan_can0_vi0_uc288664"],
"logLevel": "DEBUG"
}

Der Shunt via CAN war einer der wenigen Gründe weshalb ich einen Cerbo genommen habe, hatte keine Lust mit CanHat etc. was zu bauen. Nachteil, der Cerbo könnte mehr Rechenpower haben. Alles was Node-Red ist werde ich wohl getrennt laufen lassen.
Der BatteryAggregator ist die letzten Tage einige Versionsnummern hoch gegangen, weil ich einiges genau zum Hin und herschalten zum auxservice mit dem Author getestet habe. Ich hoffe die fixes kommen allen zu gute und verschlimmbessern nichts für andere Szenarien.

Was ich vermisse wäre so etwas wie einen Configfilechecker - werde ich mal anregen - da sobald ein Fehler drin ist alles auf default geht.

[r-l]

Bei mir, aber ein Cerbo, sieht das so aus

Das war der entscheidende Hinweis für eins der Probleme: Die zweite Option muss mit in die geschweiften Klammern und nach einem Komma eingefügt werden! So sieht das jetzt aus und scheint zu funktionieren:

{
"excludedServices": ["com.victronenergy.battery.ttyUSB3"],

"cvlMode": "max_always"

}

Das Problem mit der wechslenden USB-Nummer besteht natürlich noch

[ogurgurpv]

@r-l ich hatte das selbst nicht geprüft, jedoch scheint die Antwort in die richtige Richtung zu zeigen. Ich poste das einfach hier weiter:

Das Problem, dass angeschlossene Geräte über USB auf einem Raspberry Pi mit Venus OS nach einem Neustart andere Bezeichnungen erhalten, kann tatsächlich ziemlich störend sein, insbesondere wenn es um konsistente Gerätekonfigurationen und -verwaltung geht. Dies geschieht, weil die Zuweisung der Gerätebezeichnungen (ttyUSB0, ttyUSB1, etc.) durch das Betriebssystem bei jedem Boot-Vorgang dynamisch erfolgt, basierend auf der Reihenfolge, in der die Geräte erkannt werden.
Eine Möglichkeit, dieses Problem zu adressieren, ist die Verwendung von UDEV-Regeln, um persistente Namen für USB-Geräte zu erstellen. Hier sind Schritte, wie du das einrichten kannst:

Schritt 1: Identifiziere die Geräte

Zuerst musst du die eindeutigen Identifikatoren deiner Geräte herausfinden. Dies kannst du tun, indem du die Details der angeschlossenen USB-Geräte mit dem Befehl lsusb anschaust und dann weitere Details mit udevadm abrufst:

lsusb
udevadm info -a -n /dev/ttyUSB0

Suche nach eindeutigen Attributen wie idVendor, idProduct, und serial.

Schritt 2: Erstelle UDEV-Regeln

Erstelle eine UDEV-Regel, um jedem Gerät basierend auf seinen eindeutigen Eigenschaften einen festen Namen zu geben. Erstelle dafür eine Datei in /etc/udev/rules.d/, z.B. 99-usb-serial.rules, und füge Regeln hinzu, die wie folgt aussehen könnten:

SUBSYSTEM=="tty", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="YYYY", ATTRS{serial}=="ZZZZ", SYMLINK+="battery1"

Ersetze XXXX, YYYY, und ZZZZ mit den tatsächlichen Werten für dein Gerät. SYMLINK+="battery1" erstellt einen symbolischen Link /dev/battery1, der immer auf das spezifische Gerät zeigt, unabhängig davon, wie es von ttyUSB nummeriert wird.

Schritt 3: Ändere deine Konfigurationsdatei

Nachdem du persistente Namen für deine Geräte erstellt hast, musst du die Konfigurationsdatei für deine Anwendung ändern, um diese Namen zu verwenden:

{
"excludedServices": ["com.victronenergy.battery.battery1"],
"cvlMode": "max_always"
}

Ersetze "ttyUSB3" durch den persistenten Namen, den du über UDEV Regeln definiert hast, z.B. "battery1".

Schritt 4: Lade UDEV-Regeln neu

Nachdem du die UDEV-Regeln erstellt hast, lade sie neu, um sie zu aktivieren:

sudo udevadm control --reload-rules
sudo udevadm trigger

Schritt 5: Teste die Konfiguration

Starte dein System neu und überprüfe, ob die Geräte korrekt mit den neuen Namen erkannt werden. Du kannst dies überprüfen, indem du nachsiehst, ob die symbolischen Links korrekt in /dev/ erstellt wurden.
Durch diese Änderungen sollten deine USB-Geräte nun konsistente Namen über Neustarts hinweg erhalten, was die Verwaltung und Konfiguration erheblich vereinfacht.