JBD-BMS in VENUS-OS in fünf Minuten einbinden per dbus-serial-battery und aggregate-batteries

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Heute mal ein Inhalt, auf den sicherlich schon einige Leser des Blogs warten. Es geht darum, wie man einen oder mehrere Batteriepacks sinnvoll in Venus OS nutzen kann, welche per JBD-BMS und RS-485-USB-Adapter angebunden sind.

Im Rahmen der nachfolgenden Schritt-für-Schritt-Videoanleitung sollte es eigentlich jedem Anwender möglich sein das Ganze in wenigen Minuten nachzuvollziehen und selbst umzusetzen. Viel Spaß damit!

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube-Direktlink

Alle Links und Terminalbefehle aus dem Video:

00:00:15
JiaBaiDa Smart BMS JBD-AP20S006/AP21S002 LiFePo4 200A
JBD-UART-RS485 Adapter

00:00:32
Operation Hausspeicher – Stückliste und Bezugsquellen immer aktuelle Links

00:00:56
Louisvdw / dbus-serialbattery (GitHubLink)

00:01:12
Dr-Gigavolt / dbus-aggregate-batteries (GitHub-Link)

00:01:45
Operation Hausspeicher – LiFePo4-Zellen und die richtigen Spannungseinstellungen

00:02:04 ssh-Login

ssh root@IP-DES-VENUS-OS-DEVICE

00:02:09
Venus OS Large auf dem Raspberry Pi installieren v2

00:02:15 Installscript von dbus-serialbattery herunterladen

wget https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/install.sh

00:02:18 Installscript ausführen

sh install.sh

00:02:22 Konfigurationsdatei öffnen

nano /data/etc/dbus-serialbattery/utils.py

00:02:32
AX_BATTERY_DISCHARGE_CURRENT = 100.0
MAX_BATTERY_CHARGE_CURRENT = 100.0

UPDATE VOM 12.07.2023: Mittlerweile werden die Config-Einstellungen über zwei Dateien “gepflegt”. Die Standardsettings werden in /data/etc/dbus-serialbattery/config.default.ini aufgelistet und die Anpassungen können in der Datei /data/etc/dbus-serialbattery/config.ini gepflegt werden.

nano /data/etc/dbus-serialbattery/config.ini

UPDATE ENDE

00:02:37
STRG + O (Speichern) …. STRG + X (Schließen)

00:02:38 System neustarten

reboot

00:03:05 dbus-aggregate-batteries Dateien herunterladen

wget -P /tmp/ https://github.com/Dr-Gigavolt/dbus-aggregate-batteries/archive/refs/heads/main.zip

00:03:09 Dateien entpacken

unzip /tmp/main.zip -d /data/

00:03:14 Dateien verschieben

mv /data/dbus-aggregate-batteries-main /data/dbus-aggregate-batteries

00:03:18 Dateiberechtigungen setzen

chmod 744 /data/dbus-aggregate-batteries/service/run

chmod 744 /data/dbus-aggregate-batteries/restart

00:03:24 Konfigurationsdatei öffnen

nano /data/dbus-aggregate-batteries/settings.py

00:03:28
NR_OF_MPPTS = 0

00:03:36
CURRENT_FROM_VICTRON = False

00:03:46
OWN_SOC = True

00:04:00
CHARGE_VOLTAGE = 3.4
MAX_CELL_VOLTAGE = 3.45
DISCHARGE_VOLTAGE = 2.9
MIN_CELL_VOLTAGE = 2.7

00:04:24
MAX_CHARGE_CURRENT = 100
MAX_DISCHARGE_CURRENT = 100

00:04:28
STRG + O (Speichern) …. STRG + X (Schließen)

00:04:32 Erweiterte Konfigurationsdatei öffnen (hier nicht notwendig)

nano /data/dbus-aggregate-batteries/charge

00:04:40 rc.local-Datei öffnen

nano /data/rc.local

00:04:46
In neuer Zeile ergänzen:
ln -s /data/dbus-aggregate-batteries/service /service/dbus-aggregate-batteries

00:04:47
STRG + O (Speichern) …. STRG + X (Schließen)

00:04:48 System neustarten

reboot

00:04:59 Logdatei von aggregate-batteries einsehen

nano /data/dbus-aggregate-batteries/aggregatebatteries.log

00:05:54 Aggregate-Batteries-Dienst neustarten:

sh /data/dbus-aggregate-batteries/restart
116 Kommentare
  1. Hi,
    Ich habe diese Fehler mit 3 Daly BMS
    INFO:dbusmonitor:Found: com.victronenergy.battery.ttyUSB1, scanning and storing items
    INFO:dbusmonitor: com.victronenergy.battery.ttyUSB1 has device instance 295
    INFO:dbusmonitor:===== Search on dbus for services that we will monitor finished =====
    INFO:root:2023-04-19 10:18:26.547891: Searching batteries: Trial Nr. 1
    INFO:root:2023-04-19 10:18:26.549797: SerialBattery(Daly) found.
    INFO:root:2023-04-19 10:18:26.550278: SerialBattery(Daly) found.
    INFO:root:2023-04-19 10:18:26.550660: SerialBattery(Daly) found.
    INFO:root:2023-04-19 10:18:26.551069: 3 batteries found.
    ERROR:root:2023-04-19 10:18:27.552452: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 1
    ERROR:root:2023-04-19 10:18:28.553429: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 2
    ERROR:root:2023-04-19 10:18:29.553733: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 3
    ERROR:root:2023-04-19 10:18:30.554416: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 4
    ERROR:root:2023-04-19 10:18:31.555305: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 5
    ERROR:root:2023-04-19 10:18:32.556223: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 6
    ERROR:root:2023-04-19 10:18:33.556414: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 7
    ERROR:root:2023-04-19 10:18:34.556607: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 8
    ERROR:root:2023-04-19 10:18:35.557014: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 9
    ERROR:root:2023-04-19 10:18:36.557564: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 10
    ERROR:root:2023-04-19 10:18:37.557944: Error: ‘>’ not supported between instances of ‘NoneType’ and ‘float’. Read trial nr. 11

    Kannst du damit was anfangen?

    1. Spontan leider nicht. Anscheinend hat jemand anderes auch das selbe Problem… Siehe hier in der Issues-Sektion beim offiziellen GitHub-Repo: https://github.com/Dr-Gigavolt/dbus-aggregate-batteries/issues/32

      Hoffe das Problem wird bald gelöst, damit du das auch nutzen kannst…

      Viele Grüße
      Jörg

    2. Wie sind die Dalys angeschlossen? Per UART->USB oder RS485->USB Adaptern?
      Letzteres macht Probleme und funktioniert nicht richtig!

  2. Hallo Jörg. Hallo Zusammen.

    Ich habe nun auch die Version 2.3 installiert. Bei mir ist es so, wenn ich OWN_SOC auf True setze, dann zeigt mir AggregateBatteries 60% an und bei False 21%.
    Die einzelnen Akkus sind aber beide bei 41%.
    Die Version 2.1 hatte ich leider nicht gesichert.
    Kann man Vorgängerversionen irgendwo runterladen?
    Oder kannst du mir oder sonst wer die Vorgängerversion zur Verfügung stellen?
    Oder ist das jetzige Problem nur eine Einstellungssache?
    Gruß Arndt

  3. Hallo Jörg
    Obwohl ich “ MAX_CHARGE_CURRENT = 100” gesetzt habe, werden die batteries bei Auswahl von xdbus-serial-Batterie mit Max 10A geladen. wenn ich einen einzelnen Akku auswähle lädt er mit dem Max was ich gesetzt habe – z.B. 32A.
    Irgendeine Idee was den Wert überschreibt?
    Unter der citron Konsole unter serial Batterie, Parameter wird aus 10A CCL angezeigt – sollte da nicht 100 stehen?
    VG Dirk

    1. kann es an den folgenden Parametern liegen:

      MAX_CHARGE_CURRENT_ABOVE_CV1 = 20 # Reduction of charge current if the max. cell voltage reaches CV1
      CV1 = 2.35
      MAX_CHARGE_CURRENT_ABOVE_CV2 = 10 # Reduction of charge current if the max. cell voltage reaches CV2
      CV2 = 2.37

      Falls ja, welche Werte wären nach deinem Beispiel hier anzugeben?

    2. hat sich erledigt – ich hatte irgendwie nicht mitbekommen, das es mitlerweile eine neuere version gibt, in der diese Parameter nicht mehr existieren.

  4. Bei OWN-SOC True ist der Initial Charge unter /data/dbus-aggregate-batteries/charge der Startwert der Kalkulation und das PlugIn zählt dann selbst. Der Mittelwert aus den BMS SOC Daten wird mit False gebildet. Das habe ich eben nachgestellt und konnte es reproduzieren.

    Da ich grade mit 2 Packs fahre ist das sehr einfach nachzuvollziehen gewesen.

    Grüße

  5. Hallo zusammen, ich habe Probleme mit dem Download
    wget https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh
    00:02:18 Installscript ausführen
    sh installrelease.sh

    Ich erhalte als root angemeldet immer ein Connecting to raw… dann Error 404 : Not Found…. Der “Rest” mit Venus OS , VRM , remote funktioniert, aber…
    Hat jemand einen Tip für mich? Vielen Dank.

    p.s. Wie gewohnt eine tolle Anleitung, da kann man eigentlich nicht scheitern…

    An dieser Stelle vielen Dank an Jörg

    VG André

    1. Hi Andre, evtl copy paste Fehler?

      einfach in der cli session:

      wget https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh

      eingeben.

    2. Klappts mittlerweile? Was ist, wenn du bspw. “ping www.google.de” (ohne Anführungszeichen) in die Konsole eingibst? Hat dein Venus-OS-System Internetzugriff?

      Viele Grüße
      Jörg

    3. Also die URL hat sich wohl vor einigen Tagen geändert. Habe diese eben im Blogpost angepasst… Sollte also wieder funktionieren.

  6. Hallo,
    erstmal ein großes Lob für deinen Blog.

    Bei mir funktioniert es auch. Wenn ich wget https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh

    kommt

    –2023-05-08 13:08:21– https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh
    Resolving raw.githubusercontent.com… 2606:50c0:8001::154, 2606:50c0:8003::154, 2606:50c0:8000::154, …
    Connecting to raw.githubusercontent.com|2606:50c0:8001::154|:443… connected.
    HTTP request sent, awaiting response… 404 Not Found
    2023-05-08 13:08:21 ERROR 404: Not Found.

    bei den google ping erhalte ich folgende Antwort:

    ping: bad port spec ‘http://www.google.de’
    root@raspberrypi2:~# wget https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh
    –2023-05-08 13:11:17– https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/installrelease.sh
    Resolving raw.githubusercontent.com… 2606:50c0:8001::154, 2606:50c0:8003::154, 2606:50c0:8000::154, …
    Connecting to raw.githubusercontent.com|2606:50c0:8001::154|:443… connected.
    HTTP request sent, awaiting response… 404 Not Found
    2023-05-08 13:11:18 ERROR 404: Not Found.

    Wenn ich den Link hier direkt anklicek kommt auch die Meldung not found.

    Wäre für einen Tip dankbar.

    1. Hab kurz auf der neuen Wikiseite (externer Link) nachgeschaut…

      Die URL hat sich in der Zwischenzeit minimal geändert -> https://raw.githubusercontent.com/Louisvdw/dbus-serialbattery/master/etc/dbus-serialbattery/install.sh (also “install.sh” und nicht mehr “installrelease”.sh am Ende). Habe ich im Blogpost soeben auch angepasst…

      Viele Grüße
      Jörg

  7. Hallo Jörg, vielen Dank und Respekt, wie Du den Blog betreust – schnelle Antwort, Anpassung – einfach prima !
    Bei der http://www.google.de erhalte ich ping: bad port spec , die neue, angepasste Verlinkung funktioniert auch nicht – ist seltsam, weil die anderen Dinge, auch venus OS flott installiert werden konnten. Wie kann ich die Internetfunktionionalität wieder herstellen ?
    Vielen Dank und Gruß aus Berlin

    1. Einfach nur “ping www.google.de” (ohne Anführungszeichen) ausführen – ohne das “http://” davor. Sonst kann es auch nicht klappen… Sehe gerade, dass der Blog automatisch http:// davorpackt… Grml… Update: Hoffe es ist jetzt gefixt…

  8. Hallo Jörg, danke für Deine Bemühungen. Ich habe den Rpi neu aufgesetzt, da lief es mit den abgeänderten Links durch…
    VG André

  9. Hallo Jörg, leider funktioniert “aggregate-batteries” bei mir nicht. Zur Zeit habe ich nur einen DIY-Akku der mit “dbus-serial-battery” eingebunden ist und funktioniert. Nach der Installation von “aggregate-batteries” verschwindet mein PV-Ladegerät von der “GUI” auf dem CerboGX. Ein Menupunkt für das Tool taucht auch nicht auf. Wenn ich es wieder deaktiviere wird wieder alles normal angezeigt. Ich habe einen MPPT RS450/200, 3xMP2/5000, GerboGX und SmartShunt.

    Hast Du eine Idee woran das liegen kann?

    Gruß Tommy

    1. Was sagt das Logfile von aggregate-batteries? ->

      nano /data/dbus-aggregate-batteries/aggregatebatteries.log

      Viele Grüße
      Jörg

    2. Das Logging in der aktuellen Version von dbus-aggregate-batteries ist echt murksig programmiert.

      Fass mal die Datei “aggregatebatteries.py” an. Fast ganz unten (Zeile 628 bei mir) findest du die Zeile “logging.basicConfig(level=logging.INFO)”. Stell das auf DEBUG um. Dann stelle den Loglevel (in settings.py) auf 1 (NICHT 2) und starte den Prozess neu (“svc -i /service/dbus-aggregate-batteries” sollte funktionieren).

      Die aktuelle Logdatei findest du dann in /var/log/dbus-aggregate-batteries/current.

      Zum live-Verfolgen der Logdatei nimmst du am besten “tail -F”, zum Ansehen / Durchblättern “less”. Falls dein Venus kein “less” hat, ist “opkg update” und “opkg install less” dein Freund.

  10. Welche Version von “dbus-serial-battery” und “aggregate-batteries” ist installiert und welche VenusOS Version auf deinem CerboGX? Ich meine mich zu erinnern, dass es da vor einiger Zeit mal ne Änderung in Bezug auf die benötigten Versionsstände gab.

  11. Hallo, das Logfile wird nicht erstellt!

    @Marco
    Version CerboGX ist V2.94
    Version “dbus-serial-battery” ist v.0.14.3
    Version “aggregate-batteries” ist V2.3

    1. Hallo,

      ich habe den Fehler gefunden. Lag an mir, hatte einen Schreibfehler in der “rc.local”!

      Danke für die Hilfe und Danke für diesen Blog.

      Gruß Tommy

  12. Hallo, kurze Frage zum Soc in %.
    Im Venus Os werden 45% angezeigt und in der App vom BMS 27%. Muss dazu sagen, dass ich noch nicht den Treiber für das BMS im Venus installiert habe.

    1. Die Erweitetung aggregate-batteries ermittelt den SoC mittlerweile anhand dieses usable Ah-Wert des BMS – glaube ich zumindest. Habe ich mich aber noch nicht näher mit beschäftigt. Evtl. kann hier jemand Licht ins Dunkle bringen, der sich die Logik schon mal genauer angeschaut hat…

  13. Noch eine Frage.
    Auf was habt Ihr im ESS das Batterie laden stehen:
    Optimiert mit BatteryLife oder
    Optimiert ohne BatteryLife

    Nachteil bei Optimiert mit BatteryLife der MindestSOC Aktives SoC-Limit 65% wird selbstständig angehoben und ich kann ihn im Venus nicht verändern.

  14. Hallo Jörg,
    habe gerade nochmal mein System aktualisieren wollen und festgestellt das es scheinbar eine Neuerung im Ablauf gibt. Beim installieren des dbus-serialmasters kommt jetzt die Abfrage welche Version man installieren möchte. Bei Auswahl 1 (empfohlen) muss man im Anschluss nicht die utils.py editieren, sondern die “config .ini” (nano /data/etc/dbus-serialbattery/config.ini)
    Wichtig ist, das man das Semikolon vor der Kommando Zeile entfernt. Sonst passiert nichts.
    Originalzeile in der Config
    ; MAX_BATTERY_CHARGE_CURRENT = 50.0
    ; MAX_BATTERY_DISCHARGE_CURRENT = 60.0

    Editierte Zeile:
    MAX_BATTERY_CHARGE_CURRENT = 100
    MAX_BATTERY_DISCHARGE_CURRENT = 100

    Gruß
    Frank

    1. Hi Frank,
      danke für deinen Hinweis!

      Ja, da ändert sich öfter mal was von Update zu Update. Werde evtl. demnächst mal eine überarbeitete Anleitung liefern, wenn auch das neue Venus OS Userinterface aus der Beta raus ist…

      Viele Grüße
      Jörg

  15. Hallo Jörg,

    super Blog. Bei mir funktioniert soweit alles.

    Hatte heute einen zweiten Akkupack mit JK-BMS angeschlossen. Beide per Serialbattery angebunden. Der alte hat ein JBD-BMS. Beides 48V-Packs mit 280A.

    aggregate-Battery läuft auch und wird angezeigt.
    Allerdings wird im VRM-Portal nur ein Akku angezeigt. Und zwar nicht der von aggregate_batteries, sondern mein altes Pack mit JBD-BMS. Im DVCC ist allerdings richtig aggregate_batteries ausgewählt.

    Wie bekomme ich aggregate_batteries oder den zweiten Akkupack im VRM-Portal angezeigt?

    Grüße Willi

  16. Zur Erläuterung. Ich meine, dass im Dashboard nur das alte Akkupack angezeigt wird. Bei Advanced kann man sich die Kurven aller Packs ansehen und sieht auch aggregate_batteries. Ich hätte gerne im Dashboard aggregate_batteries oder noch besser beide Batterien.

  17. Ich empfehle jedem vorab immer die aktuellen Installationsanleitungen, FAQs etc. auf den entsprechenden Github-Seiten zu lesen. Zudem gibt’s immer ne schöne readme.md und ne changelog.md in den branches. wenn man die befolgt und alles richtig verkabelt ist, funktioniert es vermutlich in 9,9 von 10 Fällen 😉

    1. Ja. Das sollte man immer zuerst machen. Sofern es jeweils Doku dazu gibt. Habe ich in meinem Fall auch.

      Aber in meinem Fall hat es nichts gebracht. Es steht weder bei aggregate batteries noch bei serial battery im Github, etc. wie man mehrere Batteries im VRM erscheinen lässt. Victron schweigt sich auch aus.

      serial batteries hat generell eine gute Dokumentation. Bei aggregate batteries ist das leider nicht der Fall. Da sind die Kommentare in der Konfig fast besser als der Rest.

      Da ist der Blog von Jörg hier wirklich gut.

  18. Generell finde ich die Blogs von Jörg hier sehr gut. Er bietet viele Infos, die so einfach nicht in den Dokus stehen. Großes Lob an Jörg.

  19. Hallo,

    ich nutze zwar ein Seplos BMS, was ich mit dbus serialbattery angebunden habe, die Frage ist aber unabhängig vom BMS.

    Ich habe das Problem, dass der Multiplus II nicht von Absorption nach Float wechselt.. DVCC ist aktiviert. Seitens dbus serialbattery kommt nach Erreichen der Absorption-Spannung (55,2V) die Spannungsreduktion auf die Float-Voltage (54V).. das passiert ca. nach 15 – 20min. Der Victron folgt dem auch, bleibt aber auch bei Erreichen von 54 V auf Absorption.. muss man sich da sorgen machen?..

    Beim Victron selbst sind die Spannung via Victron Connect auf die gleichen Werte eingestellt, was irrelevant sein sollte. Zudem habe ich mal auf adaptive Absorption gestellt, die auch nach spätestens 1h beendet sein sollte.. gleiches Ergebnis.

    1. Puh, da bin ich kein Profi, sorry. Hast du mittlerweile weitere Erkenntnisse sammeln bzw. das “Problem” – wenn es denn wirklich eines ist – eingrenzen können?

      Viele Grüße
      Jörg

  20. Welche VenusOS Version hast Du installiert? Ich hatte das gleiche Problem bis zur Version v3.10~8, habe hin und her getestet, nix zu machen… Nach nem Update auf die VenusOS Version v3.10~9 liefs dann plötzlich wie gewünscht. KEINE Ahnung wo dem da der Schuh drückte… Jetzt mit der v3.10~11 und dem latest Dev-Build von SerialBattery läufts noch immer. ich würde es an deiner Stelle einfach mal versuchen 🙂

    1. Ich bin noch auf v3.00, da glaube ab v3.10 der Wechsel von mosquitto MQTT Broker nach FlashMQ gemacht wurde und mein Grid Meter (via dbus-mqtt-devices) nicht mehr funktioniert.. habe aber noch keine Zeit gefunden, mich genauer damit zu befassen.

    2. Oha, danke für deinen Hinweis Stefan.

      Habe selbst auch noch eine ältere Version am Start. Aber gut zu wissen, dass es bei den nächsten Updates irgendwann softwareseitig “krachen” wird und man wieder etwas umbiegen muss.

      Viele Grüße
      Jörg

    3. Laut Post im Modification-Space der Victron Community erfolgt der Wechsel mit der neuen 3.10~12.

      Changelogs hier: https://community.victronenergy.com/questions/216297/venus-os-v31011-available-for-testing.html

    4. Ok, danke für die Info. Bin ich mal gespannt, wie man dann an die Daten kommt bzw. was man konkret anpassen muss.

    5. Bei mir läuft alles wie bisher (zwei MPPTs, EM540, 2x Daly BMS per Serial Battery, 1x Shelly fürs BKW per MQTT und das GX-Gerät) landet brav in der InfluxDB und wird auch problemlos von Grafana dargestellt.

  21. Hallo,

    Ich hab hier folgendes Problem, meine Daly BMS funktioniert soweit ganz gut,
    nur wenn der Akku ziemlich leer ist so bei 40% und der MPPT mit über 60 Ampere rein lädt, bricht die Kommunikation zum Raspi (venus-OS) zusammen.
    Dann dauert es 2-3 Minuten und die Daly ist wieder da.
    beim Entladen habe ich dieses Problem nicht, da ist egal wieviel abgenommen wird

    1. Was für ein Daly? Wie sind die Einstellungen für die Lade- und Entladeströme im Daly als auch im Serial Battery Treiber? Welche VenusOS als auch Serial Battery Version? Ohne weitere Angaben ist es stochern im Nebel. Hast Du die Möglichkeit mal den vom Daly gemessenen Strom während Last zu beobachten? Je nach Firmware-Version spinnt die Messung seitens des Dalys und springt fröhlich weit nach oben und unten, egal wie konstant der entnommene Strom gerade ist (lässt sich durch nen Firmwareupdate beheben) und es schaltet dann ganz gerne mal ab, obwohl real alles OK ist.

  22. Daly 48/250A, eingestellt im Treiber ist 100-100 wie oben beschrieben und in der Daly hab ich 250-250A eingestellt. Firmware ist die 1.0.20230531, Venus Os3.00, der Strom passt ungefähr zu dem vom Shunt

    1. Kann es sein, dass der Treiber die Charge und dc Werte nicht benutzt, wenn man ins Netz einspeist?
      Die Daly schaltet nur weg beim Laden über 70A, beim entladen nicht

  23. Hey, Ich habe mein System heute leider neu aufsetzen müssen (SD Kartenfehler), Es gab eine Änderung bei dem AggregateBatteries Script welche erfordert, dass man seine JBD Uart Adapter jetzt aktiv eingeben muss. (zumindest bei mir) nur mal als kleiner Hinweis

    1. Hi Daniel,
      danke für deine Info! Ja, muss da mal bei Gelegenheit ein Update liefern. Da wird ja softwareseitig “leider” so oft etwas geändert… 🙈

      Viele Grüße
      Jörg

    2. Hallo,
      ich bekomme keine Verbindung zwischen Venus 3.00 und JBD BMS AP21S002. Habe auch den Adapter von JBD… Bin der Anleitung vom Jörg komplett gefolgt nur leider ohne Erfolg.
      Ich glaube dieses Problem mit der manuellen Eingabe auch zu haben. Leider weiss ich nicht wo und wie ich das eingeben muss. Falls jemand eine Anleitung hat, gerne her damit :).

  24. Habe ein JK BMS und ein JBD-BMS. NAch Upgrade auf die 1.x Version von Serialbattery wurde das JBD nicht mehr erkannt. JK BMS aber.

    Bin dann zurück zur Version 0.14.3 . Die funktioniert auch mit meinem JBD. Gibt bei Github Diskussionen dazu. Kommt auf das JBD an. Die haben viele verschiedene mit unterschiedlicher Firmware.

  25. Hallo
    ich habe drei MP5000 und steuer das ganze über einen Serbo GX. BMS VON JBD die neuere Version mit dem eckigen Schütz. Jetzt habe ich zwei Batteriepacks mit SerialBatteri und AggregateBatteries über RS 485 USB angeschlossen. Seit dem ist das System träge. Es kommt öfter die Meldung: System stark ausgelastet. Datenaufzeichnung wird beendet. Außerdem kommen nicht immer Daten vom BMS dann stehen bei SerialBatteri einfach nur Striche in der Remoud Konsole.
    Wie kann man die Kommunikationprobleme beheben?
    Zweites Problem AggregateBatteries zeigt nichts an.
    VG Hartmut

    1. Ohne weitere Infos ist es schwierig das festzustellen. Kann viele Gründe haben. Probleme mit der RS485-Verkabelung. Probleme von Serialbattery mit der JBD-Firmware. Oder etwas ganz anderes.

      Habe kein Cerbo GX, sondern Raspberry Pi mit Venus OS. Ich würde an Deiner Stelle schrittweise vorgehen (daher können nachfolgende Pfade unterschiedlich sein):
      -1- aggregate-batteries wieder deaktivieren
      -2- Probleme von Serialbattery lösen:
      – Per ssh auf Dein Cerbo-System und die Logs von Serialbattery prüfen.
      (z.B. /var/log/dbus-serialbattery.ttyUSB0/current, etc.). Wie die Devices bei Dir heißen, per “ps|grep serialbattery” prüfen.
      – Wenn Du hier Probleme erkennst, diesen nachgehen. Wenn das nicht klappt, testweise auf eine andere Version von Serialbattery z.B. 0.14.3 . Wie oben geschrieben läuft mein JBD nicht mehr richtig mit den Versionen 1.x .
      -3- aggregrate-batteries aktivieren und prüfen, was in den Logs reingeschrieben wird. Insbesondere was in “/data/dbus-aggregate-batteries/aggregatebatteries.log” geschrieben wird.
      -4- Sofern es dann noch Probleme mit der Systemauslastung gibt: Mit top prüfen, welche Prozesse viel CPU brauchen.

      Ja, ich weiß. Ist alles nicht so einfach. Die einfache Lösung wäre ein BMS einzusetzen, das von einem Hersteller mit VenusOS offiziell unterstützt wird. ISt aber vermutlich nicht Deine Lösung…..

    2. Jo,
      würde es auch so machen, wie Willi sagt.

      Am besten erstmal allen “Zusatzballast” aka dbus-serialbattery und dbus-aggregate-batteries deinstallieren und als Battery Monitor mal die Multiplus auswählen. Wenn das funktioniert, dann schrittweise die Erweiterungen installieren und testen bis du wieder in den Fehler läufst…

  26. Hallo,
    Ich habe eine Anfängerfrage.
    habe gestern dbus-serialbattery neu aufgespielt, nur für eine Batterie. Den Ladestrom konnte ich hochstellen. Welchen Befehl muss ich für die Konfigurationsdatei eingeben?

    Viele Grüße Gerson

  27. Moin, ich versuche verzweifelt mein zweites Akkupack im Venus zu integrieren.

    Beide Packs sind mit RS485 über Serial Battery (neuste Version) angebunden und werden auch korrekt angezeigt.

    Mit AggregateBatteries (neuste Version) werden die SOCs auch korrekt summiert. Leider wird bei mir immer nur ein BMS angesteuert. (immer das gleiche)

    Ich dachte eigentlich dass die Akkus Parallel einspeisen.

    Wenn ich in dem einspeisenden BMS per Bluetooth das Entladen verhindere, dann wird sofort auf den Zweiten Akku umgeschaltet, nur parallelbetrieb funktioniert nicht. Nach welcher Logik soll hier die Steuerung von 2 oder mehr Akkus ablaufen?

    Im Victron kann ich “Steuerndes BMS” angeben, sowie den “Batteriewächter” Ich habe schon etliche Kombinationen getestet, bekomme aber nie beide BMS gleichzeitig zum Laden bzw. Entladen. Oder muss im BMS noch was speziell eingestellt werden?

    1. Vermutlich ist bei dir das Problem, dass du erst das Relais beider Batteriepacks zum “Durchschalten” bewegen musst. Das Batteriepack, welches nicht lädt und entlädt – das sieht du ja anhand der Ampere-Anzeige des BMS -, musst du einmal abkoppeln und ein Ladegerät alleine an dieses Batteriepack ankoppeln, welches 2-3V mehr Spannung bereitstellt als das Batteriepack gerade hat. Nach einer Sekunde solltest du dann ein “Klack” hören und das Relais/Schütz schaltet durch.

      Dann dieses Batteriepack wieder mit deinem Gesamtsystem “verheiraten”. Dabei darauf achten, dass die Battierpackspannung max. 1-2V ober bzw. unterhalb der Gesamtpackspannung ist. Sonst fließen u.U. schnell zu große Ausgleichsströmungen und das BMS schaltet gleich wieder ab.

      Viele Grüße und Erfolg
      Jörg

      PS: Würde mich echt interessieren, ob es dieses Problem bei dir war…

    2. Hi, wir haben aktuelll genau das gleiche Problem. 2x 16S Akku mit 2x JBD BMS AP21S002.
      Beide Relais sind geöffnet. An der Busbar hängen noch 3x MP2 5000. Wenn wir einen Akku abkoppeln entläd er über das andere und umgekehrt aber nie gleichzeitig. Hat hierzu jemand eine Idee?

    3. Hi Jörg,

      so wie du es beschrieben hast funktioniert es. Komplett abkoppeln, Ladegerät mit 2-3V mehr Spannung anschließen, Relais klackt und öffnet. Jetzt muss es mit geöffnetem Relais an die Busbar angeschlossen werden. Das ganze Prozedere mit jedem Pack.
      Dann laden/entladen die Multiplus in jedes Pack gleichzeitig und alles funktioniert.

      Ist jedoch mega nervig jedes Mal die Packs von der Busbar abzukoppeln um das Relais zum Durchschalten zu bewegen. Gerade im Prozess des von dir beschriebenen seriellen Topbalancings.
      Wie machst du das @Jörg, hast du noch Schalter dazwischen?

    4. Hallo Jörg,
      bei mir laufen 3 x 16S Akkus jeweils auch mit JBD BMS AP21S002.
      Alle Akkus und die 3 x Multiplus 5000 hängen parallel an den Busbars.
      Ich hatte jetzt auch mehrmals das Problem, dass nur ein Akkupack geladen wird,
      obwohl laut XiaoxiangBMS-App alle Lade- und Entladeports durchgeschaltet sind.
      Durch die bereits beschriebenen Maßnahmen lassen sich die Akkupacks doch zum Laden zu bringen. Ich konnte aber auch schon beobachten, dass plötzlich ein BMS durchschaltete, also dann zwei Akkus liefen und dann fast 100 A Ausgleichsströme flossen. Das ist alles andere als optimal und stresst die Akkus total unnötig. Auch steht dann nur ein Drittel meiner Kapazität zur Verfügung. Ich hatte seit Anfang Dezember mehrere Wochen problemlosen Parallelbetrieb, seit drei Tagen läuft nur ein Akku.
      Während des parallelen Betriebs waren immer mal ein paar Abweichungen von ein paar % beim SOC zwischen den Akkupacks, das mag ja eventuell an abweichenden Innenwiderständen liegen.
      Ich hätte nur zu gerne gewußt warum die BMS manchmal nicht durchschalten. Bei einer DIY Lösung möchte ich eigentlich alles unter Kontrolle haben…

      Ansonsten weiter so, ist eine super Lösung!

      Grüße,

      Jens

    5. Tachchen!

      Wenn die Batteriepacks korrekt eingerichtet und eingebunden sind (Relais geschlossen), läuft es UNBEGRENZT lange einfach stressfrei durch. Bei mir nun seit fast einem Jahr am Stück ohne jeden Ausfall. Lediglich bei einem Hardcore-Entladetest bis runter auf 2,5V (niedrigste Zelle) haben die BMS abgeschaltet. Aber genau das wollte ich in diesem Fall auch erzwingen.

      Man muss eben darauf achten, dass die Parameter so gewählt sind, dass das BMS nur im Notfall trennt und die Lade-/Entladeregelung auf Victron-Seite per DVCC früh genug drosselt, sodass es bspw. keine Über- bzw. Unterspannung auf Zellebene gibt, sodass das BMS gar nicht erst abschaltet (also im Normalbetrieb). Denn in diesem Fall muss der betroffene Pack – wie erläutert – erst wieder getrennt und kurz eine höhere Ladespannung angelegt werden, sodass das Relais des JBD-BMS wieder durchschaltet.

      Das finde ich ehrlich gesagt mittlerweile konzeptionell gesehen sogar ganz gut. Denn wenn das BMS abschaltet, sollte das eben nicht grundlos passieren und einen schwerwiegenden Grund haben. Und dann möchte ich vor dem Wiedereingliedern des Packs auch erstmal selbst analysieren, was da falsch gelaufen ist. Und dazu gehört es dann auch das Pack “physisch” zu untersuchen. Und da koppele ich es ohnehin vom Gesamtsystem ab.

      Wie gesagt, das Ganze läuft bei meinen 6 parallelen JBD-Packs absolut fehlerfrei – so hatte ich jetzt die letzten 3 Wochen, als wir im Urlaub waren, auch keine Bauchschmerzen das System “alleine” werkeln zu lassen.

      Zu den Spannungseinstellungen etc. habe ich noch weitere Inhalte (auch Videos) geplant, evtl. kann ich damit noch etwas mehr Input liefern, wie man die ganzen Komponenten am besten parametriert bzw. “synchronisiert”, sodass es problemlos im Dauerbetrieb läuft. Denn so mega trivial ist das alles nicht, das gebe ich zu. Musste ich auch erstmal Erfahrung sammeln und mit Werten spielen – die ich aber alle auch schon im Blog Kommuniziert habe.

      Und auf diese Xiaoxiang-Dingens-Smartphone-App, die sagt, ob das Relais nun geschlossen ist oder nicht, würde ich persönlich nichts geben. Diese Funktion ist irgendwie buggy – zumindest meine Erfahrung. Alles andere funktioniert in der App top, aber den “Relais-State” kann man knicken. Wer sich nicht sicher ist, ob das Relais nun durchschaltet oder nicht, sollte am besten per Multimeter direkt nachmessen.

      Viele Grüße und Erfolg bei der Umsetzung
      Jörg

  28. Ich hatte die Tage einen interessanten Fehler, der mich ca. 1 Woche abendliche Recherche gekostet hat um ihn zu lösen. Vielleicht hilft es jemandem, der vor dem gleichen Problem steht:
    Mein System 1*16s an MP2-5000 gesteuert über Raspberry lief seit 6 Monaten problemlos im WLAN, ich habe mir den em24 Zähler gespart, nutze den verbauten Solaredge Modbus Zähler, der über Modbus TCP die Werte an den Raspberry liefert.
    Nach Update des Solaredge WR fand es den Zähler nicht mehr, obwohl die Ports und Devicenummer weiterhin stimmten und Modbus TCP aktivierte war. Der Wechselrichter war weiterhin anzupingen, aber ich bekam keine Werte mehr. Komplette Neuinstallation des Systems änderte nichts, über Portscanner fand ich den WR.

    Die Lösung: Solaredge hat wohl mit der letzten Firmware Modbus TCP über WLAN gesperrt, ohne das in der Oberfläche des WR anzuzeigen. Nach anstöpseln eines LAN Kabels (D-Lan–>LAN) funktionierte hatte ich sofort wieder meine Zählerwerte.😜

    1. Hi Benedikt,
      danke fürs Teilen deiner Erkenntnisse. Echt schrecklich, wenn solche Änderungen einfach in einem Softwareupdate “eingeschoben” werden und dann gar nichts mehr funktioniert. Ging mir gerade erst so mit meinen ESP32, auf denen WLED läuft. Seit dem neuesten Fritzbox-Update läuft hier nichts mehr – die ESP32 rebooten alle 60s. Ultra ätzend, zumal eine wirkliche Lösung aktuell noch aussteht. Aber das ist wieder ein anderes Thema für sich…

      Viele Grüße
      Jörg

  29. Hallo Jörg, hallo zusammen.
    Ich habe mir heute gedacht, dass ich mal dbus-serialBattery und dbus-aggregate-batteries ein Update gönne.
    Dbus-serialbattery 1.0.20230531 läuft
    Dbus-aggregate-batteries 3.0 bekomme ich nicht ans laufen
    Ich habe es auf dem Cerbo GX und auf einem Raspberry nach Anleitung von Jörg installiert. Auf dem Cerbo GX wird es angezeigt (wahrscheinlich weil es dort schon mal lief) aber nur Striche bei den Werten. Am Raspberry wird es gar nicht angezeigt.
    Auf beiden ist Venus OS 3.10 installiert.
    Ich wäre für Hilfe sehr dankbar. Gerne kann man mich auch über arndt.broistedt@mail.de kontaktieren und ich würde mich dann telefonisch melden. Ist vielleicht einfacher.
    Gruß Arndt

    1. Bitte IMMER die aktuellen Installationshinweise aus dem Wiki des Treibers beachten! Hin und wieder gibt es da Änderungen. Probleme solcher Art konnte ich weder bei den aktuellen DEV- als auch den Master-Versionen beobachten und ich nehme da so ziemlich jede Version mit. Das ganze läuft auf nem GX-Device eines Easysolar II.

  30. Hallo Jörg,
    danke für deine Antwort.
    Ich habe schon im Vorfeld durch viel Rumtesten beide Packs parallel zum Betrieb bekommen.
    Ich kann leider nicht genau sagen wodran es nun genau lag. Ich habe auf jeden fall Beide Packs nacheinander wieder auf 100% SOC geladen und plötzlich waren beide BMS durchgeschaltet.

    Aktuell habe ich:
    DVCC aktiv
    SVS aktiv
    STS aktiv
    Temperatursensor = Aggregat Battery
    SCS deaktiviert
    Steuerndes BMS: 280Ah Pack

    Folgende Probleme habe ich noch:
    Im VRM Werden mir für die einzelnen Packs die Temperaturen nicht angezeigt.
    Dort steht nur: NaN:NaN
    Wenn ich als steuerndes BMS den AggregatBattery oder das 304Ah Pack wähle, wird mir “Batteriespannung niedrig Multiplus 2” als Störung angezeigt. Nur mit dem 280Ah als steuerndes BMS läuft es ohne Störung.

    1. Kann ich leider nichts zu sagen, sorry. Muss mal wieder nen Update machen – hinke bereits viele Versionen hinterher… 🙈

      Wobei das VRM habe ich bisher überhaupt nicht genutzt. Da bin ich voll raus…

      Viele Grüße
      Jörg

  31. Hallo Jörg,

    Erstmal danke für all deine Anleitungen!! Hat mir super geholfen beim Aufbau meines Systems.
    Ich habe 3 Multiplus 5000 und zwei batterien je 16 Zellen 280Ah mit JBD BMS.

    Serial batterie per ssh installiert und läuft problemlos.

    Nur beim Aggregate batteries habe ich das Problem, dass der Dienst zwar gestartet wird, jedoch zeigt es in der Console keine Werte an. sehe lediglich “— —”

    In den Log files lese ich heraus, dass die Batterien nicht gefunden werden.

    INFO:root:registered ourselves on D-Bus as com.victronenergy.battery.aggregate
    INFO:root:Tue Oct 31 10:34:39 2023: Initial Ah read from file: 169Ah
    INFO:root:Tue Oct 31 10:34:39 2023: Last balancing done at the 295. day of the year
    INFO:root:Tue Oct 31 10:34:39 2023: Starting battery monitor.
    INFO:root:Tue Oct 31 10:34:39 2023: Connected to DBus, and switching over to GLib.MainLoop()
    INFO:dbusmonitor:===== Search on dbus for services that we will monitor starting… =====
    INFO:dbusmonitor:Found: com.victronenergy.battery.aggregate, scanning and storing items
    INFO:dbusmonitor: com.victronenergy.battery.aggregate has device instance 0
    INFO:root:Tue Oct 31 10:34:40 2023: Searching Settings: Trial Nr. 1
    INFO:root:Tue Oct 31 10:34:40 2023: com.victronenergy.settings found.
    INFO:dbusmonitor:Found: com.victronenergy.settings, scanning and storing items
    INFO:dbusmonitor: com.victronenergy.settings has device instance 0
    INFO:dbusmonitor:===== Search on dbus for services that we will monitor finished =====
    INFO:dbusmonitor:Found: com.victronenergy.battery.ttyS6, scanning and storing items
    INFO:dbusmonitor: com.victronenergy.battery.ttyS6 has device instance 278
    INFO:dbusmonitor:Found: com.victronenergy.vebus.ttyS4, scanning and storing items
    INFO:dbusmonitor: com.victronenergy.vebus.ttyS4 has device instance 276
    INFO:root:Tue Oct 31 10:34:46 2023: Searching batteries: Trial Nr. 1
    INFO:root:Tue Oct 31 10:34:46 2023: 0 batteries found.
    INFO:root:Tue Oct 31 10:34:51 2023: Searching batteries: Trial Nr. 2
    INFO:root:Tue Oct 31 10:34:51 2023: 0 batteries found.

    Aggregate batteries Version 3.1
    kann es sein, dass in den Settings.py etwas falsch ist:

    BATTERY_SERVICE_NAME = ‘com.victronenergy.battery’ # Key world to identify services of physical Serial Batteries (and SmartShunt if available) >
    BATTERY_PRODUCT_NAME_PATH = ‘/ProductName’ # Path of Battery Product Name
    BATTERY_PRODUCT_NAME = ‘SerialBattery’ # Key world to identify the batteries (to exclude SmartShunt)
    BATTERY_INSTANCE_NAME_PATH = ‘/CustomName’ # if CustomName doesn’t exist, set ‘/ProductName’
    MULTI_KEY_WORD = ‘com.victronenergy.vebus’ # Key world to identify service of Multis/Quattros (or cluster of them)
    MPPT_KEY_WORD = ‘com.victronenergy.solarcharger’ # Key world to identify services of solar chargers
    SMARTSHUNT_NAME_KEY_WORD = ‘SmartShunt’ # Key world to identify services of SmartShunt

    Danke dir!
    Schöne Grüße Manuel

    1. ok mittlerweile werden die Batterien im ersten Anlauf entdeckt unter

      com.victronenergy.battery.ttyACM0 als Instanz 2
      com.victronenergy.battery.ttyACM1 als Instanz 1

      Das stimmt soweit auch…

      INFO:dbusmonitor:===== Search on dbus for services that we will monitor starting… =====
      INFO:dbusmonitor:Found: com.victronenergy.settings, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.settings has device instance 0
      INFO:dbusmonitor:Found: com.victronenergy.system, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.system has device instance 0
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyACM0, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyACM0 has device instance 2
      INFO:root:Wed Nov 1 08:46:43 2023: Searching Settings: Trial Nr. 1
      INFO:root:Wed Nov 1 08:46:43 2023: com.victronenergy.settings found.
      INFO:dbusmonitor:Found: com.victronenergy.vebus.ttyS4, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.vebus.ttyS4 has device instance 276
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyACM1, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyACM1 has device instance 1
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyS6, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyS6 has device instance 278
      INFO:dbusmonitor:Found: com.victronenergy.battery.aggregate, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.aggregate has device instance 0
      INFO:dbusmonitor:===== Search on dbus for services that we will monitor finished =====
      INFO:root:Wed Nov 1 08:46:48 2023: Searching batteries: Trial Nr. 1
      INFO:root:Wed Nov 1 08:46:48 2023: 0 batteries found.

      Im weiteren Verlauf werden die Batterien dann aber nicht explizit gefunden…

    2. Hallo!
      Hast du schon eine Lösung des Problems? Ich habe heute wegen eines größeren Systemupgrades nach knapp einem Jahr ohne Update SerialBattery von 0.14 auf 1.02 und AggregateBattery von 2.2 auf 3.1 (3.0 auch schon probiert) aktualisiert.

      SerialBattery läuft einwandfrei, AggregateBattery findet keine Batterien. Genau so wie bei dir oben: die Instanzen selber werden beim Start gefunden, dann aber nicht angebunden:

      INFO:root:registered ourselves on D-Bus as com.victronenergy.battery.aggregate
      INFO:root:Thu Nov 2 19:15:59 2023: Initial Ah read from file: 317Ah
      INFO:root:Thu Nov 2 19:15:59 2023: Last balancing done at the 175. day of the year
      INFO:root:Thu Nov 2 19:15:59 2023: Starting battery monitor.
      INFO:root:Thu Nov 2 19:15:59 2023: Connected to DBus, and switching over to GLib.MainLoop()
      INFO:dbusmonitor:===== Search on dbus for services that we will monitor starting… =====
      INFO:dbusmonitor:Found: com.victronenergy.settings, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.settings has device instance 0
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyACM0, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyACM0 has device instance 2
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyACM1, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyACM1 has device instance 3
      INFO:dbusmonitor:Found: com.victronenergy.battery.ttyACM2, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.ttyACM2 has device instance 4
      INFO:dbusmonitor:Found: com.victronenergy.vebus.ttyUSB0, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.vebus.ttyUSB0 has device instance 288
      INFO:dbusmonitor:Found: com.victronenergy.battery.aggregate, scanning and storing items
      INFO:dbusmonitor: com.victronenergy.battery.aggregate has device instance 0
      INFO:dbusmonitor:===== Search on dbus for services that we will monitor finished =====
      INFO:root:Thu Nov 2 19:16:00 2023: Searching Settings: Trial Nr. 1
      INFO:root:Thu Nov 2 19:16:00 2023: com.victronenergy.settings found.
      INFO:root:Thu Nov 2 19:16:05 2023: Searching batteries: Trial Nr. 1
      INFO:root:Thu Nov 2 19:16:05 2023: 0 batteries found.
      INFO:root:Thu Nov 2 19:16:10 2023: Searching batteries: Trial Nr. 2
      INFO:root:Thu Nov 2 19:16:10 2023: 0 batteries found.
      INFO:root:Thu Nov 2 19:16:15 2023: Searching batteries: Trial Nr. 3
      INFO:root:Thu Nov 2 19:16:15 2023: 0 batteries found.
      INFO:root:Thu Nov 2 19:16:20 2023: Searching batteries: Trial Nr. 4
      INFO:root:Thu Nov 2 19:16:20 2023: 0 batteries found.

    3. Lösung gefunden. In der settings.py muss folgendes verändert werden:

      BATTERY_PRODUCT_NAME = ‘JBD-AP21S002-L21S-200A-B-U-R-C’

      Ich habe heute mal zum ersten mal Python angefasst… Aber wenn man C kann, kann man (nahezu) alles andere 😉

  32. Leider nein. Habe das ganze system mehrmals auf werkseinstellungen zurückgesetzt und mehrfach alles neu installiert, teilweise die skripts umgeschrieben… immer mit dem selben ergebnis… ich komm nicht drauf. Mittlerweile auch ratlos dazu. Aktuell wird das system über eines der beiden bms gesteuert. Mal schauen ob das halbwegs funktioniert… leider wird dann halt die ladekennlinie der zweiten batterie nicht berücksichtigt…

    1. Schau mal hier am untersten Teil des Beitrags….
      Ich hatte das selbe Problem seit dem Update.

      https://github.com/Dr-Gigavolt/dbus-aggregate-batteries/issues/45

  33. Versucht mal den Battery Aggregator von Pulquero. Läuft bei mir deutlich besser und findet bis heute problemlos meine beiden Dalys. Firmware ist die aktuelle 3.20~14. Lediglich das ignorieren des Smartshunt hat mich anfangs etwas Nerven gekostet, ist aber Easy wenn man weiss wie. Steht dort auch in seiner Doku.

    https://github.com/pulquero/BatteryAggregator

  34. Ich habe einen Multiplus II GX also ein integriertes GX.
    Hat schon mal jemand die Software für die JK-BMS Kopplung darauf installiert?
    Falls ja, gibt es eine kleine Anleitung? Habe so Fragen wie, welche IP? User/PW?

    Grüße Jo

    1. Funktioniert dort genau so wie bei nem GX-Gerät ala Cerbo GX usw. Ist alles ausführlich im GIT von Serial Battery beschrieben. Zudem gibt es dutzende Videos dazu auf YouTube. Es selbst hinzubekommen begünstigt zudem das “wie funktioniert das eigentlich und was passiert da”-Verständnis. Es hier jetzt nochmal durchzukauen ist nicht notwendig.

    2. Das Vorgehen ist bei jedem Venus-OS-Device gleich – egal ob Raspberry Pi oder GX. dbus-serial-battery versteht sich auch mit den JK-BMS, die per USB angeschlossen sind..

      Viele Grüße und Erfolg
      Jörg

  35. Gibt es mittlerweile die Möglichkeit, dass bei einem Neustart von SerialBattery die einzelnen Akkus im Namen erhalten bleiben (also z.B. Akku1, Akku2 usw.)?
    Gruß Arndt

    1. Würde mich auch brennend interessieren, zumal der korrekte Name ja ohnehin unter “Device” -> “Product” angezeigt wird. In meinem Fall also bspw. “Hallbude-5”. Vielleicht weiss ja jemand, wie man das hinbekommt…

      Viele Grüße
      Jörg

  36. Schaut mal im aktuelle DEV-Build (das aktuelle Stable hab ich noch nicht getestet) von SerialBattery in Zeile 248:

    ; Enter custom battery names here or change it over the GUI
    ; Example:
    ; /dev/ttyUSB0:My first battery
    ; /dev/ttyUSB0:My first battery,/dev/ttyUSB1:My second battery
    CUSTOM_BATTERY_NAMES = /dev/ttyUSB0:Joerg Ihm sein Akku

    Akku taucht nach nem Reboot mit dem festgelegten Namen auf. Bei nem zweiten Akku USB1 nehmen, bei nem dritten USB2 usw.

    Das korrekte Device könnt Ihr ggf. über die Remote Console im Untermenü des Akkus –> Device –> Connection sehen bzw. per SSH per dbus-spy auslesen.

    Beste Grüße aus dem Norden

  37. Hallo zusammen

    ich weiss nicht ob meine Frage hierzu passt. Ich habe das System hier nachgebaut. Echt super alles, und noch einmal 1000 Dank.
    Jetzt läuft es schon eine ganze Weile. Mir ist nur aufgefallen, dass die beiden Akkupacks ungleichmässig laden. Ein Block hat aktuell ca. 17% der andere ca. 25%; mit einer Spannungsdifferenz von ca 0,5 Volt. Geladen wird aktuell auch immer nur der vollere Akku. Ich dachte eigentlich dass die beiden Blöcke da parallel laden. Vielleicht hat jmd eine Idee.

    Danke

  38. Hallo Jörg,
    Vielen Dank für deine Super Videos.

    Hab das ganze nun zum laufen gebracht.

    Hab 2 Batteriepakete mit den gleichen JBD BMS´en.
    Beide haben die gleiche Konfiguration.
    Nur laufen mir mittlerweile beide SOC über 10% auseinander, obwohl die gleiche Spannung anliegt.

    Wenn ich beide neu über Bluetooth initialisiere, dann sind sie knapp 1% auseinander.
    ( Aber auch hier gibt es immer wieder probleme, dass die BMS wieder einschaltet. Nur wenn ein hoher Ladestrom fliesst schalten sie wieder ein)

    Hast du eine Erklärung dafür?

    Gruß,
    Stefan

  39. Hallo Jörg,
    vielen Dank für Deine ausführlichen Dokumentationen zum Aufbau eines ESS. Sehr hilfreich und das System wächst kontinuierlich!
    Aktuell installiere in Batteriepack 3 und 4. (Ziel 16s 4p)
    Interessanterweise hat sich vor 14 Tagen – vor dem “live” gehen von Pack3 Aggregate Batteries version 2.3 verabschiedet und war nicht mehr sichtbar.
    Egal denk ich mir – Version 3.1 wird es schon richten.
    Nix ist. Aggregate Batteries Version 3.1 ist ebenfalls nicht sichtbar. Im logfile ist ein Error, dass die Anzahl der Zellen falsch sei, obwohl
    ich NR_OF_CELLS_PER_BATTERY = 16 gesetzt habe. Wenn ich das rumgewürge in diversen Blogs sehe werde Pulquero ausprobieren.

    Hat jemand eine Idee, wie ich aggregate batteries sinnvoll deinstalliere? Dazu finde ich absolut nichts bei dr-gigavolt

    Tausen Dank!

    1. Bin ja mittlerweile auf “Battery Aggregator” umgestiegen. Läuft absolut stabil – anders als manche “Aggregate Batteries”-Varianten, die ich getestet habe. Dazu gibts in einigen Tagen ein neues Howto.

      Aggregate Batteries kannst du ganz easy deaktivieren…
      Einfach per ssh die Datei rc.local öffnen mit

      nano /data/rc.local

      Und den Eintrag
      ln -s /data/dbus-aggregate-batteries/service /service/dbus-aggregate-batteries
      mit einer führenden # versorgen… Also dass diese Zeile dann so aussieht:

      #ln -s /data/dbus-aggregate-batteries/service /service/dbus-aggregate-batteries

      Dann STRG + O (Speichern)… STRG + X (Schließen) und das System per “reboot” neustarten. Dann sollte Aggregate Batteries nicht mehr starten.

      Viele Grüße und Erfolg
      Jörg

  40. Moin Jörg,

    ich kann mich allen anderen hier nur anschließen, vielen Dank für deinen Blog und die Inspirationen, Anleitungen, Videos. Gerade was die letzten Tage als Content kam, echt super, vielen Dank!

    Ich habe mir auch ein Batteriepack mit 16 Zellen und nem JBD-BMS gebaut und war bis vor kurzem sehr zufrieden damit.
    Diese Woche habe ich festgestellt, dass das BMS den SoC nicht korrekt berrechnet, also Spannung und SoC passen nicht wie eingestellt zusammen. Das BMS scheint hier immer eigene Werte zu berechnen, was nicht besonders smart ist.
    Die Einstellungen im BMS habe ich mit der iOS-App “XiaoXiangElectric” (weißer Elefant auf hellblauem Hintergrund) vorgenommen, Vorteil bei der App ist, dass man die Kapazität “reseten” kann.
    Die Spannungen für den Soc habe ich aus dieser Tabelle entnommen:

    https://docs.google.com/spreadsheets/d/1SyzKUZ5_KxLB6megSLTXYv_1LlbcFqE4gxMgK8SrMvs

    Wie wirkt sich das aus: Nun, zum einen übermittelt das BMS bei einem Ladezustand von 30% schon die minimalen 10%, 20% der Batterie werden also nicht genutzt. Setze ich die Kapazität über die App wieder zurück, springt der SoC auf 30%, beim weiteren Entladen unterschreitet das Pack aber die Spannung von 48V (10%) und man muss manuell eingreifen oder auf die Sicherung im BMS warten, sonst werden auch die 2,9V pro Zelle unterschritten.
    Das Verhalten ist leider reproduzierbar, Akku laden auf 100% funktioniert, beim Entladen landen wir immer bei den 10% die eigentlich 30% sind.

    Hast Du oder die Community eine Idee, warum das BMS so arbeitet und wie ich das Problem lösen könnte?

    1. Hi Konsti!
      Ein echtes Problem und vieles davon im Netz. Ganz genau wirst du es nie hinbekommen. Häufige Losung: installierte und nutzbare Kapazität gleich groß eingeben statt der von der App vorgeschlagenen 80%.
      Oder :BMS anlernen durch Laden bis zum Ausschalten durch BMS und Entladen bis zum Abschalten.
      Andere haben auch die PC Version von Xiaoxiang genutzt, da soll es wohl einen Coloumb Zähler geben(?). Habe ich nie installiert und kann dazu auch nix weiter sagen.
      Ich für meinen Teil hab die nutzbare Kapazität auf 100%der installierten Leistung gepackt und die Entladung wird bei 48v gestoppt. So alarm habe ich wie Jörg auf 0%gepackt.die Alarme Nerven wirklich. Soc Ladezustand nimmst du deine Liste und passt diese sukzessive an. Durch die gerade Spannungslinie bleibt der Soc auf Volt-Basis leider ein Schätzwert.
      Solltest du die PC Version nutzen und dort den Coloumb (in etwa ein Ah Zähler) finden und erfolgreich nutzen können, freue ich mich über ein Update!!

  41. Moin Jörg,
    irgendwie habe ich bei der Installation von dbus, meine remote console abgestellt,… warum auch immer. W-lan ist leider auch aus, da ich habe nur noch zugriff per Bluetooth welches aber ja nur für die Ersteinrichtung ist. Gibt es noch ne Möglichkeit wie ich wieder zugriff bekomme? Ein display direkt anschließen würde wahrscheinlich gehen? Achso ist ein Cerbo kein Raspi,…
    vielen dank & grüße zwen

    1. Über Bluetooth und die Victron Connect App solltest Du das WLAN wieder aktivieren und dann über dein lokales Netz auf die Remote Console zugreifen können.

  42. Guten Tag, das Tool berechnet mir den SOC falsch 2 Akkus einer mit 89% der andere mit 95% das Tool sagt mir 55% ich denke das ist ein falscher Wert. Grüße René

    1. Ohne genauere Angaben zum System, verbaute BMS, Softwareversionen, wie angeschlossen etc. sind wir im Bereich des Kristallkugelreibens… Mit “mein Auto fährt nicht” kann einem auch kein Mechaniker etwas anfangen 😉

  43. Also 3 Phasenanlage Victron MP2 5000 Cerbo BMS wie Jörg nur die 300A Version. Ich habe aggregate-batteries in der settings.py auf OWN_SOC = False gestellt und CURRENT_FROM_VICTRON = False ebenfalls jetzt Funktioniert es. Den Battery Aggregator hatte ich vorher schon drauf leider gab es da ein richtiges Problem, beim Testen war der Akku fast voll und eine Zelle kam an 3.65 Volt raun hätte das BMS nicht abgeschalten… Keine Ahnung was hier das Problem war/ist. Habt Ihr eine Idee? Grüße

  44. Hallo zusammen, bei mir läuft inzwischen alles auch ganz gut.
    Nur ein kleines Problem hab ich, mein aggregat…. zeigt immer den doppelten Wert der beiden Batteriepacks an.
    Z.B. wenn jede mit 30A entlädt, zeigt Aggregate 120A statt 60A an

  45. Szenario für zwei Batteriepacks
    Nehmen wir an, aus irgendeinem Grund schaltet eines der zwei der beiden BMS ab. Dies führt dazu, dass nur ein Pack geladen wird. Dieses Problem ist nicht immer sofort erkennbar, da man nicht täglich das Betriebssystem überprüft. Stellen Sie sich vor, ein Akku ist vollständig geladen (100%), während der andere nur zu 20% geladen ist. Wenn das zweite BMS z.B. wegen eines defekten Relais plötzlich beschließt, sich wieder einzuschalten, kann es zu einem erheblichen Problem kommen. Die Spannungsdifferenz zwischen den beiden Packs kann so groß sein, dass es zu einem Kurzschluss kommt und die DC-Sicherungen durchbrennen. Ich habe das schon erlebt mit einem JBD BMS wie hier verbaut wurde. Es geht hier nicht um irgendwelche Einstellungen in dem Fall war alles korrekt. Verwendet wurden Serial Battery und dbus-aggregate-batteries
    BMS waren JBD-AP21S002 300A Version mit RS485 und BT. Wie handhabt Ihr das?

    1. Hi René.
      Es reicht auch schon im Winter, dass ein bms in den sleep Modus geht und beim Laden nur eines geladen wird. Bisher kam das schlafende bms auch bei höherem Ladestand (noch) nicht aus dem sleep mode. Schau mal in die xiaoxiang app. Dort kannst du charge und discharge overcurrent einstellen. Hast du bestimmt auch gemacht. Ich habe 140a eingestellt und 30s Release time. Die 250a Sicherung sollte also ohne schaden davon kommen.
      Bleibt das Problem des sleep mode. Ich arbeite hier grübel an einer Lösung über ein Ladegerät, das alle 6 Stunden kurz mal eine Spannung anlegt um die bms wach zu halten. Ätzend.

    2. Naja, “Kurzschluss” ist das nicht, aber natürlich trotzdem zu viel. Durchgerechnet: eine 280KZelle hat einen Innenwiderstand von 0,25 mOhm und eine Spannungsbandbreite von einem Volt (2.5 bis 3.5V). Somit können beim Zusammenschalten mal eben schlappe 2000A fließen, wenn man sämtliche anderen Widerstände ignoriert und einfach zwei Zellen aufeinanderbratzt. 😉 (Sogar mehr, wenn man auf drei leergesaugte Batteriepacks ein volles draufschaltet …)

      In der Praxis ist es natürlich um Einiges weniger, aber “Einiges” ist relativ. 500A bei zwei oder 1000A bei mehreren Batterien dürften trotzdem ohne Weiteres drin sein. Tschüß, 250A-Sicherung und 300A-Relais. :-/

      Das zu handhaben ist eher schwierig, wenn die BMSe keinerlei Möglichkeit zur Verfügung stellen, das Relais extern anzusteuern. Da bleibt nur manueller Eingriff, d.h. hoffen dass der Bediener die Spannungen prüft bevor er/sie das Pack wieder aufschaltet.

      NB, dass ein Relais sich wegen Defekt selber einschaltet, schließe ich mal aus, aber der Defekt kann ja auch in der BMS-Firmware liegen – oder im Anwender, der/die das Prüfen vergisst …

      Alternativ kann man darüber nachdenken, eine kleine Platine mit einem Optokoppler und zwei Transistoren auszustatten, damit man das Relais zusätzlich extern blockieren kann. Fällt halt in die Rubrik “Bastellösung”, aber was will man machen angesichts unzureichender Hardware …

  46. bei mir geht immer nur ein und das selbe schlafen. Ich habe auch noch eine weitere Anlage mit der gleichen Konfiguration. Da habe ich die Probleme aber nicht.

  47. Hallo Zusammen,
    ich betreibe seit ein paar Wochen zwei Batterie-Blöcke parallel, die mit jeweils einem JK-BMS ausgestattet sind. Die Daten werden über RS485-USB an den Cerbo geliefert und mit dem Battery-Aggregator von “pulquero” zusammengefasst. Ich sehe die Daten der einzelnen Batterien und ebenso die zusammengefassten Daten in der Remote-Console. Darüber hinaus ist auch ein Smart-Shunt verbaut, über den ich die Summenströme auslesen kann. – Mir ist nun aufgefallen, dass der Strom, der über den Battery-Aggregator angezeigt wird, ca. den doppelten Wert anzeigt, verglichen mit der Summe der einzelenen Werte der beiden BMSes. Der Wert des Shunts stimmt mit den Werten der BMSes überein. Ich hatte diese Differenz erst jetzt festgestellt, da wieder mehr Sonne vorhanden ist. Installiert habe ich jeweils die ‘latest’ Varianten der jeweiligen Programme mit dem Package-Manager.
    Fragen:
    – Hat jemand diesen Effekt ebenfalls bemerkt und weiß, wie dies zu beheben ist?
    – Habe ich evtl. bei der Installation einen Fehler gemacht? Sollte eigentlich nicht der Fall sein können, da dies über den Package-Manager erfolgt ist.
    Würde mich freuen, wenn jemand hier weiterhelfen kann.

    Gruß Christof

  48. Hallo Jörg, ich habe den Venus OS mit einem RPI 3B erfolgreich installiert und möchte mein JBD Bms mit dem RPI verheiraten. Leider habe ich keine RS 485 Schnittstelle. Geht das auch mit der UART Schnitstelle des Bluetooth Dongle? Auf den könnte ich verzichten. Bräuchte ich dafür ein UART zu Rs 485 Konverter? Oder geht auch der, den du in deinem Video benutzt?
    Viele Grüße Thomas

  49. Ich kann nur vor diesem JBD-BMS warnen, wenn man es parallel mit mehreren Batteriepacks betreibt! Die BMS gehen nach ca. 18 Stunden in den Sleep-Modus und schalten das Relais ab, aber es fließt noch ein kleiner Strom über einen Parallelwiderstand. Das Problem besteht darin, dass bei einer Parallelschaltung nicht alle BMS wieder zuverlässig ‘aufwachen’, und somit werden nicht alle Packs gleichmäßig geladen. Dadurch kann es zu hohen Spannungsunterschieden zwischen den einzelnen Packs kommen. Wenn dann irgendwann alle Packs wieder einschalten, fließen sehr hohe Ströme, bis im besten Fall die Sicherungen ansprechen oder schlimmeres passiert. Außerdem lässt die Messung des State of Charge (SOC) zu wünschen übrig; sie ist sehr ungenau. Das merkt man aber erst, wenn man sie parallel betreibt. Der Hersteller sagt auch, dass diese BMS nicht für den Parallelbetrieb geeignet sind.

  50. Hallo Leute, vielleicht kann mir jemand helfen. Ich habe ein 3 Phasen ESS mit 3x 18s Packs und JK BMS im Einsatz. Das Sysrtem läuft mit dbus aggregate-batterie eigentlich echt super. Nur die Strombegrenzung DCL bei entladen wird nicht beachtet. Egal was ich in der sttings.py eintrage z.b
    “MAX_DISCHARGE_CURRENT = 20” entlädt das System trotzdem mit der Leistung die ich zb. per ModbusTCP vorgebe. die Ladebegrenzung funktioniert aber. Weiss jemand eventuell war das so ist. Vielen Dank
    Gruss Christian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen