Nach lachen ist mir diesbezüglich nicht. Du bestätigst mir gerade ein Gefühl was ich die letzten Tage hatte… „Die Prozesssicherheit kam mir nicht besonders hoch vor“. In Verdacht habe ich Hauptsächlich den Chipsatz „CH34x“ von meinem RS485Adapter
Laut der ersten Recherche, so wie ich es interpretiere, funktioniert das nur im Master/Slave - Betrieb(?).
Per BLE soll wohl nicht die stabilste Lösung sein. Verbreitetet Alternative über esphome mit esp, per rs485 anzapfen.
Was ich noch testen möchte. Ein Can -Master/Slave Betrieb und gleichzeitig per serialbattery alle Packs reinholen für Monitoring
falls du das hinbekommst sage mir wie. Das war heute mein Plan.
Die Adressen waren nicht 0x00 sondern bei allen 0x01.
In der daisy chain brauchen die Batterien natürlich unterschiedliche Adressen. Der Master, der dann via CAN angeschlossen wird hat dann 0x00. Und damit ging die Auslese mit serialbattery nicht. (←Ich hoffe, dass da mein Fehler liegt)
Mit BLE habe ich drei Jahre jk-bms version 11.X ausgelesen. Lief stabil.
ich bestätige auch, dass es nicht funktioniert. Hintergrund, sobald 0x00 gesetzt wird „verblödet“ das BMS. Das hat zur Folge das am 0x00er kein RS485 mehr funktioniert und über CAN nur noch eingeschränkt Werte ausgegebenen werden (u.a keine Einzelspannungen). An anderen BMS innerhalb des CAN-Daisy Chain (0x0X) funktioniert weiterhin die Ausgabe per RS485 aber hierbei kommt es scheinbar zu irgendwelchen Loops/Rückkupplungen beim abfragen mit serialbattery.
Um 0x00 an einem BMS zu vermeiden bin ich aktuell am stabilsten mit einem RS485 Daisy Chain, also nur mit einem RS485Adapter (Waveshare CH34x). Der Waveshare mit 4Ch (Ch344L) läuft auch am Cerbo, allerdings kam es mir träge vor… nicht weiter verfolgt.
Auf der Suche nach einer Lösung mit „nicht 0x00“ bleibt dein BLE - Versuch interessant und ich habe einen Blick auf das Projekt „BSC“ geworfen.
Sofern ich das richtig verstanden habe sitzt der Controller zwischen „nicht 0x00er“ und gibt das an Victron aggregiert weiter.
Parallel dazu ist Mqtt möglich (u.a. alle Zellen wegen nicht 0x00), Prüfung der Werte auf Plausibilität und Einstellungen für das aggregieren der BMS(e)
das dbus-serialbattery findet die beiden BMS und stellt sie im venusOS als zwei akkus dar. der aggregator fasst die dann zusammen, weil das ESS ja nur den SOC etc. einer batterie verwenden kann.
mein RS485-adapter am raspberry ist ein “Waveshare RS485/CAN-Hat (B)”, also nicht über USB angebunden.
das gesamte system läuft seit herbst 2024 so, ohne wesentliche änderungen, bis auf VenusOS- und dbus-serialbattery-updates. seit dem letzten update bekomm ich im Victron GUI regelmäßig “BMS cable failure”-alerts vom dbus-serialbattery, die ich für fake halte, weil ich alle werte aus den BMSen regelmäßig über MQTT abfrage und schlußendlich in grafana bunte kurven mache, und in diesen kurven hab ich keine aussetzer.
Ein schöner Adapter, zumindest vom Layout her und gleich noch mit Spannungsversorgung . Aktuell halte ich noch an meinem CerboGX fest, auch wenn die Performance nicht der Hit ist.
Ich erhalte die Meldung auch, allerdings nur als „Warnung“, was keine weiteren Auswirkungen hat. Ich hätte vermutet, dass es von VenusOS kommt. Nach einem Neustart erscheinen die Batterien relativ schnell und verschwinden kurzfristig wieder. Darauf hin bekomme ich Alarme mit Strom und oder Spannung. Nun erscheinen die Batterien wieder, die Alarme sind weg und es kommt die Warnung mit „Kabelfehler“.
Zurück zu meiner Eingangsfrage: ist es möglich mit einem RS 485 Adapter mehrere alte JK BMS anzuschließen. Diese haben bekanntlich ja keinen Adressen DIP Schalter
Wenn du die JK BMS B…. -Serie meinst. Mein b2a24s20p ist gerade nicht angeschlossen aber ich meine mich zu erinnern, dass du in der App unter „Addr“ einstellen kannst. Anders als bei der PB… -Serie (Inverter), hier ist es in der App ausgegraut da man es über die DIP-Switch(e) einstellt
Aktuell arbeite ich an einer „eigenen“ Aggregierung der Batterien. Hauptsächlich um ungleiche Stromverteilung (105Ah/280Ah) mit CCL/DCL-Grenzen besser Händeln zu können. Auch das Thema eine Batterie fällt weg oder kommt zurück kann ich so nach meinen Geschmack abbilden.
Bzgl. RS485 Adapter bin ich etwas weiter gekommen. Mein Waveshare Adapter, den ich als nicht 24/7 stabil empfand basiert auf dem Chipsatz CH340.
Fehlerbild:
Verbindung weg → wieder da → wieder weg
Mögliche Ursachen:
USB-Reset
Treiberproblem
EMV / Ground-Shift
CH340 unter Last
Aktuell nutze ich einen anderen isolierten Adapter basierend auf FTDI Chip in Kombination mit „RS485-DaisyChain“. → Seit mehreren Tagen kein Aussetzer in der Kommunikation gehabt
Der Victron Adapter basiert laut googeln scheinbar auch auf FTDI, allerdings konnte ich keine zuverlässigen Angaben finden bzgl galvanischer Trennung
danke für deinen Eindruck. Mein Adapter basierend auf FTDI Chip in Kombination mit „RS485-DaisyChain“ ist auch problemlos unterwegs. Da Venus bekanntlich alles per Mqtt bereit stellt, greife ich es so weiterhin für HA-Monitoring ab —> „ich liebe es, die JSON Data von dbus serialbattery“
Hast du GND vom BMS auf dem Adapter aufgelegt? Bei mir war es so, seitdem mein isolierter Adapter „schwimmen“ darf, also kein GND mehr anliegt ist die Meldung bei mir weg.
Keine Ahnung warum, vielleicht hat es damit zu tun das der GX (-USB) auch über die Batterien versorgt wird und so zwei Bezüge (Schleife) am Adapter waren