AHED_BMS: Nutzerfeedback & Musteranfragen (2)

Vielen Dank für Dein erneutes Feedback.

Das setzen auf 2 % bei ~ 3.0 V ( die genaue Schwelle hängt von der Höhe des Entladestroms ab ) habe ich so gewählt, damit regulär keine negativen SOC-Werte vorkommen, da diese über das Pylontech/SMA CAN-Protokoll nicht sauber kommuniziert werden können.

In den Spannungskurven oben liegt die maximale Zellspannung nur ganz knapp über 3.4 V. Da könnten 10 mV schon > 1 Ah bedeuten. Ich würde empfehlen, dass die durchschnittliche Zellspannung beim Balancing bei mindestens 3.42 V liegt und würde dem BMS dann bei Gelegenheit mal die Chance geben bis auf 5 mV Delta anzugleichen.

Wie stellt Du Dir den die Verwendung eines solchen Gerätes vor.

Meine Einschätzung ist, dass, wenn man wirklich ordentliche Ergebnisse haben will, ein Coloumb-Counter direkt an der Batterie ( also quasi noch vor dem BMS ) hängen muss, damit der Eigenverbrauch des BMS mitberücksichtigt wird. Macht man dies nicht, muss man Krücken wie “Charge efficiency factor“ nutzen, die dann mehr oder weniger nach Bauchgefühl gesetzt werden.

2 „Gefällt mir“

In Deiner Anleitung zu Settings des BMS schreibst Du:

“Manche Werte sind entweder reine Statuswerte ( read only ) oder ein Schreibzugriff ist momentan
noch nicht freigegeben. Diese nicht editierbaren Felder werden grau angezeigt.”

Das trifft bei mir für den Wert auf 3,40 Volt eingestellten Wert für “Vcell start” zu.

Könnte ich von Dir, zur Veränderung des Wertes, bitte eine Freigabe und kurze Anleitung per PN oder E-Mail erhalten. Danke.

Hier ein Detail zu dieser Zeit.

Da sich die Min-/Max- Werte nicht annähern bin ich nicht sicher, ob hier überhaupt gebalanced wurde. Ich war nicht vor Ort. Die Werte stammen aus der Fernübertragung.

Die Werte für das Balancing sind noch unverändert. Also Balancing ab 3,40 Volt,

Vcell delta target ist auf 5 mV eingestellt, Balancing Mode Top&Night Balancing.

Ich bin mir ziemlich sicher dass Du diesen Wert nicht verändern möchtest.

( Wenn man diesen Wret verändern würde, müßte man auch zahlreiche andere Werte anpassen, davon angesehen kann ich mir nicht vorstellen, dass es bei LFP Chemie Sinn machen würde, diesen Wert nennenswert zu verändern )

Was möchtest Du konkret erreichen?

FYI: Die 3.4 V bedeuten nicht, dass alle Zellen über 3.4 V liegen müssen, damit das Balancing startet!

Ob gebalanced wurde, kannst Du an der Balancing-Statistik nachvollziehen. Ich bin mir aber ziemlich sicher, dass gebalanced wurde.

Das Problem dürfte sein, dass Du noch von der Inbetriebnahme eine Imbalance von mehreren 100 mAh vor Dir herschiebst und diese über den Winter noch weiter zugenommen hat.

Dass es so wirkt, als ob keine Angleichung stattfindet wird daran liegen, dass der Balancer gegen die Relaxation der Zellen arbeitet. (Meiner Erfahrung nach gibt es eine Korrelation zwischen erhöhter Selbstentladung und stärkerer Neigung zum Relaxieren.) Es kann im Extremfall sogar so sein, dass die Zellspannungen erst für ein paar Stunden weiter auseinanderlaufen obwohl der Balancer arbeitet.

Für den Bereich ganz nahe bei 3.4 V habe ich im Moment noch keine Schätzung der Ladungsunterschiede und darauf basierend einen weiteren Ausgleich auch nach Absinken der Zellspannungen unter 3.4 V eingebaut.

Das liegt schlicht daran, dass dies typischerweise nur bei Inbetriebnahme des Packs wirklich relevant ist, weil danach ( im Zweifelsfall mit Kompensation der Selbstentladungsunterschiede durch das BMS ) die gesamte notwendige Balancingzeit pro Jahr bei eher < 10 h ( <=> ~ 1 Ah ) liegt.

Das ist also im Moment noch eine gewisse Einschränkung dass, man nach der Inbetriebnahme einmalig relativ viel Zeit für das initiale Angleichen geben muss, wenn die Zellen nicht bereits sehr ausgeglichen geliefert wurden.

Wenn eine Zelle den anderen hinterherläuft ( typisch bei leicht erhöhter Selbstenladung ) müssen alle anderen durch den Balancer entladen werden. Für dieses Szenario läuft das bei meinem BMS mit ~ 90 mAh. Dass heißt es würden für 1 Ah dann > 11 h benötigt.

Im Beispiel oben dürften nur ~ 140 mAh ausgeglichen worden sein.

Ich würde Dir also empfehlen, bei den nächsten sonnigen Tagen mal so lange zu Balancen, bis das BMS das Balancing selbstständig beendet, auch wenn es 10 h dauert. Das kann problemlos auch gestückelt an meheren Tagen passieren. Wenn du den Deye durch das BMS steuern lassen würdest, würde das sogar automatisch geschehen.

Außerdem noch einmal der Hinweis, dass die Ladespannung sehr niedrig gewählt ist, ich würde mindesten 10 mV mehr pro Zelle erlauben. Selbst 3.42 V ist im Vergleich dazu wie in vielen Anwendungen LFP Zellen geladen werden noch ein sehr konservativer Wert.

Das hatte ich missverstanden und darin die Balancingschwelle reininterpretiert.

Ich hatte ohnehin vor deinen Empfehlungen zu folgen und die anstehenden sonnigen Tage für das vollständige “nachträgliche” Initial-Balancing zu nutzen.

Super Darstellung. Das entspricht genau dem von Dir beschriebenen erwartbaren Verlauf. DANKE.

Das ist schon ein wirklich cooles Projekt !

Ich hätte glatt Lust das selbst einzusetzen.

Denke bitte an unser Forum falls du mal eine Kleinserie herstellen möchtest.

Ich hätte da interesse daran ich betreibe aktuell3 Akku Packs mit je einem JBD-BMS mich stört ds das BMS einmal nicht mit dem Deye komunizieren kann , und auch die SOC berechnung ist eher dürftig, kann man dein BMS mit rs485 auslesen? gibt es da Dten dazu warum frage ich ich betreibe nebnbei die Solaranzeige und visualisiere in Grafana alle meine Daten so sehe und dokumentiere auch den verlauf ect. Warum ich JBD BMS habe mir geällt die Hardware mit dem echten Relais wenn also Fehler auftreten wird der Akku Pack auch hardware technisch getrennt.

Ich würde dich da gerne unterstützen und hier meine Akku Packs sofern sie dann noc auslesbar sind gerne mit Daten zuverfüung stellen, welche Akkus habe ich 2 x 16s mit jeweils 280 ah und ca 300 ah und eimal einen 2p16s also 32 zellen 2 Parallel als 16s dieser hat nachweislich 666ah leider kann ich in den JBD BMS nur maximal 635ah angeben mehr gibt die Software nicht frei, was SOC mässig auh nicht passt. wenn du also interesse hast sag bescheid.

Die neuste Variante hat zwar optional auch einen zusätzlichen RS485-Anschluss, den habe ich aber selber noch nicht in Betrieb genommen. Es gibt aber bereits eine gute Alternative: Für die Kommunikation zum Deye bietet sich CAN an. Das nutze ich hier in einer Testanlage auch genauso. An den CAN-Bus kann man sich dann z.B. mit einem CAN-USB oder CAN-Ethernet Adapter zusätzlich dranhängen und hat dann Zugriff auf alle Daten aller BMS-Instanzen. Dafür habe ich in den letzten Monaten ein Python Skript erstellt, dass die Daten dann nach MQTT bridged. Mit MQTT sollten die Daten praktisch in jedem EMS Kontext nutzbar sein.

Die Daten über MQTT sehen dann z.B bei 3 Packs so aus: ( BMS_1-3 sind die eigentlichen Packs und BMS_0 aggregierte Daten )

{"BMS_1": [{"ts": 1773837723803, "values": {"V": 53.8, "I": 8.61, "V1": 3.358, "V2": 3.356, "V3": 3.358, "V4": 3.358, "V5": 3.358, "V6": 3.357, "V7": 3.358, "V8": 3.36, "V9": 3.357, "V10": 3.357, "V11": 3.358, "V12": 3.357, "V13": 3.356, "V14": 3.358, "V15": 3.357, "V16": 3.359, "Ti": 31.0, "Tf": 26.5, "Ts": -35.0, "T1": 27.3, "T2": -35.0, "T3": -35.0, "T4": -35.0, "flags": "0x0000", "SOC": 84.864}}]}
{"BMS_2": [{"ts": 1773837723803, "values": {"V": 53.696, "I": 7.02, "V1": 3.354, "V2": 3.353, "V3": 3.354, "V4": 3.354, "V5": 3.353, "V6": 3.354, "V7": 3.354, "V8": 3.353, "V9": 3.351, "V10": 3.353, "V11": 3.353, "V12": 3.353, "V13": 3.353, "V14": 3.352, "V15": 3.352, "V16": 3.352, "Ti": 30.5, "Tf": 25.3, "Ts": 24.8, "T1": 24.5, "T2": -35.0, "T3": -35.0, "T4": -35.0, "flags": "0x0000", "SOC": 72.576}}]}
{"BMS_3": [{"ts": 1773837723804, "values": {"V": 53.794, "I": 8.26, "V1": 3.358, "V2": 3.356, "V3": 3.358, "V4": 3.358, "V5": 3.358, "V6": 3.357, "V7": 3.358, "V8": 3.36, "V9": 3.357, "V10": 3.357, "V11": 3.358, "V12": 3.357, "V13": 3.356, "V14": 3.358, "V15": 3.355, "V16": 3.359, "Ti": 28.3, "Tf": 23.8, "Ts": -35.0, "T1": 23.3, "T2": -35.0, "T3": -35.0, "T4": -35.0, "flags": "0x0000", "SOC": 75.917}}]}
{"BMS_0": [{"ts": 1773837723853, "values": {"V": 53.8, "I": 23.89, "V1": 3.359, "V2": 3.356, "V3": 3.358, "V4": 3.358, "V5": 3.359, "V6": 3.357, "V7": 3.358, "V8": 3.36, "V9": 3.358, "V10": 3.357, "V11": 3.358, "V12": 3.357, "V13": 3.357, "V14": 3.358, "V15": 3.357, "V16": 3.359, "Ti": 31.0, "Tf": 26.5, "Ts": -35.0, "T1": 27.3, "T2": -35.0, "T3": -35.0, "T4": -35.0, "flags": "0x0000", "SOC": 77.515}}]}

Das läßt sich aber auch recht einfach für andere Formatierungen der Daten anpassen.

Wenn Du Interesse an dem BMS hast, müßte ich wissen, welche maximalen Stromstärken bei Dir benötigt werden. Für zwei parallele Zellen der 300 Ah Klasse, bei denen man typischerweise ein BMS der 300 A Klasse verwendet würde, habe ich im Moment keine Variante.

Würdest Du mein BMS parallel zum JBD installieren oder das JBD ersetzen wollen?

Ich würde es ersetzen wollen, und ich frage deswegen wegen den rs485 anschluss da ich die jetzigen bms mit der solaranzeige über rs 485 auslese und in grafana visualisiere die CAn komunikation würde dann mit dem deye statt finden, ja 300A sollten es schon seinda ich eben einen deye 20K betreibe der bis zu 350 kann ja die werte teilen sich auf das ist richtig nur wenn ich 2 Akkus mal weg nehme kommen da schonmal bis zu 250 Ampere zusammen. Ach ja und ich bräuchte 3 BMS da ich 3 Akkus habe, können deine BMS auch untereinander komunizieren? Das mit dem Pythonscript ist sehr interesannt.

Mit großer Wahrscheinlichkeit wird das über MQTT ganz ähnlich möglich sein.

Klar, grundsätzlich können bis zu 16 Packs ( getestet bis jetzt bis 8 ) über den CAN-Bus verbunden werden. Eines wird als Master ernannt und aggregiert die Daten aller BMS auf dem Bus. Diese aggregierten Daten werden dann auch gemäß Pylontech-Protokoll einem WR ( z.B Deye) am selben CAN-Bus zur Verfügung gestellt und alle Daten auf dem CAN-Bus können zusätzlich noch über ein z.B. CAN-USB Adapter mittels des Python-Skriptes für Datenauswertung/Logging über MQTT bereit gestellt werden.

Wenn Du ein BMS benötigst, das alleine ( also nicht im Verbund ) 300A Dauerstrom kann, ist meine HW im Moment nicht geeignet. Die größte Version kann ~ 200 A, wenn mit einem Lüfter ausreichend gekühlt wird.

Für den 2p Pack mit > 600 Ah ist das sicherlich grundsätzlich kein Problem, für eine einzelne Zelle der 300 Ah Klasse aber arg viel. Wenn man die Kommunikation zwischen BMS und WR nutzt, sollten solche Ströme aber gar nicht für mehr als ein paar Sekunden vorkommen, weil das BMS automatisch den maximal erlaubten Entladestrom reduziert, wenn einzelne Packs abgeschaltet sind.

Nein 300A Dauerstrom gehen ja auch nicht dauerhaft aus den Akus raus aktuell komme ich gesammt auf ca 220mpere Ladeleistung also bei allen 3 Akkus, im grossen Akku waren es bis jetzt mal 150 Ampere was maximal rein geflossen ist.

Ziel ist es ja auch nicht immer wieder die Akkus zutrennen, sondern die sollen schon zusammen bleiben, Du sagt das bei 200 Ampere ausreichend gekühlt werden muss, schalten da die Lüfter oder der Lüfter sich selbst ein oder sind eventuell sogar drehzahlgesteuert?

Das mit dem Datenbus ist natürlich sehr interesannt und wäre für den Deye sehr gut geeignet , den aktuell fahre ich ja rein nur über die Spannung, die Ladeleistung also bis wohin entladen werden darf und wann schluss ist.

Was die bis zu 16 Packs angeht das wäre ebenfalls mal für später auch noch eine Option den mein Akku wird definitiv noch wachsen spätestens wenn das E Auto kommt.

Zur Not knn ich ja die Ampere auch Begrenzen sollte der Fall mal eintreten das eben nur 1 Pack vornden wäre , das ist aber eben nicht beabsichtigt.

1 „Gefällt mir“

Bei der etwas älteren Version, von der ich noch Muster habe, leider nicht.

Die neuste Version ist mit einem Lüfteranschluss für aktive Kühlung vorbereitet.

Man sollte dabei immer folgendes im Kopf haben: Ein BMS das z.B. für maximal 200A ausgelegt ist, hat bei ~ 140 A weniger als die Hälfte der maximalen Verlustleistung, so dass dabei die Temperatur noch ziemlich unkritisch bleibt. Erst darüber nimmt die Temperatur dann stark zu. Aktive Kühlung ist also nur relevant wenn man an die Grenzen der Dauerleistung gehen will.

Ich habe so etwas bei meinem BMS bis jetzt nur zu Testzwecken mit Messequipment ( bidirektionale Labornetzteile ) gemacht. Ich würde eine Batterie nie so auslegen, dass das BMS regelmäßig im Grenzbereich arbeitet.

Ich würde vorschlagen, ich schicke Dir ein Muster meiner stärksten BMS-Variante und Du schaust dann mal, wie das für dich passt. Das BMS überwacht sowieso die Shunt- und MOSFET-Temperatur, so dass man ganz bequem kontrollieren und protokollieren kann, in welchem Bereich man arbeitet. Da Du sehr wahrscheinlich keine PH-Kontakte crimpen kannst, muss ich die Kabel BMS-seitig vorbereiten. Reichen Dir 75 cm für die Balancing-Anschlüsse? Was benötigst Du an Kabeln für den CAN-Bus? Einmal zum Anschluss an den Deye mit RJ45 ( wie lang), und dann ein weiteres zum Anschluss eines CAN-USB-Adapters?

Möchtest Du dann auch ein Display dazu?

Ja 75 cm Langen can und rs485 sofern vorhanden reichen 2 draht vollkommen aus hier darfs gerne 150 cm sein , ein Display wäre Super

Für die CAN-Verkabelung verwende ich normalerweise RJ45 Kabel als Grundlage. Wenn ein Deye-angeschlossen werden soll, bietet es sich dann an, die Belegung so zu wählen, dass man an einer Seite den RJ45 Stecker direkt nutzen kann.

RS485 unterstützt diese BMS-HW,

von der wir hier reden, wie gesagt leider noch nicht.

Hast du bei Dir in CAN-Reichweite der Batterien irgendeinen Rechner ( z.B. Rpi ) )?

Du könnest von mir so einen galvanisch getrennten CAN-USB Adapter bekommen.

Zusammen mit dem Python-Skript kommst du dann an alle Daten ran. Falls es zur Anbindung an Solaranzeige notwendig sein sollte, die MQTT Daten anders zu formatieren, könnte ich Dich dabei auch unterstützen.

Schicke mir dann bitte Deine Adresse bei Gelegenheit per PM.

Ja die Solaranzeige läuft auf einem Pi und die Hilfe nehme ich she rgerne an.

Hast Du für Solaranzeige schon mal Daten per MQTT bereitgestellt?

Läuft auf Deinem Pi schon ein MQTT Broker wie Mosquitto?

Könntest Du in Erfahrung bringen, was bei MQTT und Solaranzeige im Detail berücksichtigt werden muss, z.B. welche(r) Topic(s) werden genutzt, wie werden Devices erkannt/angelegt?

1 „Gefällt mir“

Ja das funktioniert ein MQTT Broker ist da auch instaliert anbei hab ich die dokumentation mal mit geschickt.

MQTT Informationen zur Solaranzeige.pdf (194,0 KB)

Eigentlich würde sich die Gerätenummer zur Unterscheidung verschiedenen BMS Instanzen anbieten. Dies hier klingt aber problematisch:

"Bei der Single-Geräte Version ist die Gerätenummer immer 1, bei der Multi-Regler-Version kann die Gerätenummer 1 bis 6 sein."

Wenn man also z.B. bis zu 10 Batteriepacks abbilden möchte, sehe ich eigentlich nur diese Option:

Aggregierte Daten / Daten für die gesamte Batteriebank:

Strangspannung:
"solaranzeige/anzeige/1/BMS0_V"

Gesamtstrom:
"solaranzeige/anzeige/1/BMS0_I"

Zellspannungen ( typ. max/min über jeweilige Zelle der Packs für hohen/tiefen SOC ):
"solaranzeige/anzeige/1/BMS0_V1"
...
"solaranzeige/anzeige/1/BMS0_V16"

Daten vom ersten Pack:

Packspannung:
"solaranzeige/anzeige/1/BMS1_V"

Packstrom:
"solaranzeige/anzeige/1/BMS1_I"

Zellspannungen:
"solaranzeige/anzeige/1/BMS1_V1"
...
"solaranzeige/anzeige/1/BMS1_V16"

Daten vom zweiten Pack:

Packspannung:
"solaranzeige/anzeige/1/BMS2_V"

....

Wie siehst Du das?

PS: Du müßtest das auch bereits ohne BMS HW mit einfachen Befehlen auf der Konsole testen können, z.B.:

mosquitto_pub -h localhost -t solaranzeige/anzeige/1/BMS0_V -m "54.1"

Ja muss ich probieren habe aber die Multiregler version da ich ja mehr wie ein gerät auslese.