Hallo Leute! Ich habe ein sehr seltsames Problem das ich nicht einordnen kann. Ich habe 3 mit je einem BMS in meinem System. 2 Akkus haben ein PAce 200A BMS und ein Akku hat ein JKBMS in Verwendung. soweit so gut. Das System arbeitet auf den ersten Blick normal und alle 3 BMS werden mir im VRM Portal ordnungsgemäß angezeigt, aber…
Sehe ich in die Remote-Console sehe ich alle 3 BMS.
Sehe ich in den GUI v2 Beta, sehe ich nur 2 BMS. Das 2. Pace BMS fehlt hier.
Sehe ich ins Node-RED sehe ich auch nur das erste Pace BMS und das JKBMS, das 2. Pace BMS sehe ich hier ebenfalls nicht.
Ich verwende derzeit die Cerbo GX Firmware V3.50~15. Der Battery Aggregator sagt mir aber auch, dass 3 Batterie-Module online sind. Es ist also kein generelles kommunikations-Problem. Die Pace BMS sind mittels CAN angebunden und das JK-BMS hängt an einem USB Adapter der die RS485 Kommunikation vom JK-BMS überträgt.
Das Venus OS ist nicht wirklich dafür ausgelegt mehrere BMS zu verwalten.
Victron geht davon aus, das es in einem System auch nur einen Akku und somit auch nur ein BMS gibt.
Zudem werden beide BMS nicht offiziell unterstützt.
Das mag sein, dass Victron diese BMS nicht offiziell unterstützt und auch nicht mehr als ein BMS. Prinzipiell sollte das aber trotzdem funktionieren. Es gibt genug leute da draußen die noch mehr unterschiedliche BMS miteinander gemischt haben und wo es funktioniert. Ich versuche zu verstehen wo der Unterschied zwischen Remote Console und GUI bzw. NodeRED ist. Ich war immer der Meinung, dass es entweder überhaupt nicht funktioniert oder funktioniert und nicht in einem Bereich gut funktioniert und in einem anderen nicht. Das ist für mich nicht nachvollziehbar.
Wenn es so nicht unterstützt ist, dann kann es unterschiedlichste Effekte geben, weil eben kein Stück Code darauf ausgelegt ist, wie so etwas behandelt wird.
In der einen Iteration wird halt alles Angezeigt
In einer anderen hat der Entwickler eine Abbruchbedingung drin, sobald EIN BMS gefunden ist
Der nächste Entwickler hat sich irgendwo gedacht: Top, BMS schon via CAN gefunden, brauch ich USB gar nicht scannen
Usw, usw.
Code-technisch ist es immer ein riesen unterschied, ob ich EIN Objekt habe und Erwarte oder immer eine LISTE von Objekten. Häufig ist alles auf LISTEN ausgelegt, und wenn ich weiß, dass ich per Spezifikationen nur ein Element haben darf/kann/sollte, verwende ich direkt immer Liste[0], ohne zu prüfen ob es ein 2tes oder ntes Element gibt…
Kritisch wird es dann evtl., wenn ggf. Werte durcheinander gewürfelt werden, weil 2 Unterschiedliche Code-Elemente jeweils gerade ein anderes BMS als Datengrundlage verwenden.
Das hilft dir nix, nur so als Anmerkung aus Sicht eines unabhängigen Softwareentwicklers, weil du schreibst, dass du nicht nachvollziehen kannst, warum dies geht, aber das nicht.
Danke für deine Ausführung, dessen bin ich mir durchaus bewusst. Ich bin nur davon ausgegangen, dass ein so offenes System wie von Victron schon einheitlich programmiert wurde.
Für so einem speziellen Anwendungfall wie ich das mit unterschiedlichen BMS habe, gibts ja auch ein Dritthersteller-Lösung wie den BatteryAggregator. Der funktioniert bei mir problemlos. Ich hätte nur gerne die Max und Min Zellen-Werte jedes BMS ausgelesen damit ich diese tracken und bei Bedarf einen Alarm auslösen kann. Das funktioniert aber so wie es bei mir derzeit ist leider nur mit 2 BMS da das Dritte scheinbar nur fallweise erkannt wird. Irgendeine Lösung muss ich mir wohl hierfür noch einfallen lassen wenn das nicht über NodeRED machbar ist.
Victron ist schon ziemlich offen… und die kennen schon eine Menge BMS…
dafür gibt es halt Kompatibilitäts-Listen… wenn man sich daran nicht hält…
aber, wenn die dann auch ALLE Wünsche/Sonderheiten der Kunden einbauen sollten…
dann könnten wir das nicht mehr bezahlen…
wenn Du eine spezielle Lösung möchtest, dann musst Du halt selber was bauen ;O))))
Wenn sie in der RK und im BA alle drei angezeigt werden, dann sind sie wohl erst mal da. Das hat meiner Meinung nach nichts mit dem eigentlichen victron-OS zu tun.
Wie benutzt du denn NodeRed? verwendest du die originalen viictron-Nodes, dann könnte hier das Problem liegen. Vielleicht werden die beiden Peace-BMS nicht eindeutig unterschieden.
Ich nutze ein MQTT-Broker, und frage von dem die Daten für das NodeRed ab. Ich verwende zwei 123Smart-BMS und habe damit keine Probleme.
Versuch doch mal den Entwickler vom BA zu kontaktieren, seine Kontaktdaten findest du glaube ich im GitHub, oder in der Hilfe vom BA.
Danke, das war die erste brauchbare und konstruktive Rückmeldung.
Genau. Sie sind da und funktionieren in Verbindung mit dem Battery-Aggregator auch sehr zuverlässig. Nur die neue Gui v2 und Node Red zeigen mir immer nur entweder BMS 01 oder BMS 03 an. Beides sind Pace BMS. Ich hatte auch schon die Vermutung, dass die BMS vielleicht die selbe ID haben und deswegen immer wieder mal das eine oder mal das andere BMS angezeigt wird. Ich habe allerdings keine Ahnung wie ich das ändern kann. Das liegt wahrscheinlich an der Firmware der BMS. Ich kann zwar die BMS per CAN miteinander koppeln, dann komme ich aber nicht an die Min/Max Daten der Zellenspannungen von beiden BMS ran. Da wird dann immer nur die höchste und die niedrigste Zellenspannung der 2 Akku-Pakete gesammelt angezeigt. Also z.B. Zellenspannung 1 high Bat 01 und Zellenspannung low Bat02. Deswegen habe ich beide Akku-Pakete getrennt per CAN an den Cerbo GX angeschlossen. Das ist aber scheinbar auch keine wirklich fehlerfreie Lösung.
Ja, ich verwende die original Victron Node und übertrage dann per mqtt die Daten an den iObroker.
Versuche doch mal die Werte in den MQTT-Broker direkt einzulesen, ohne Verwendung der Victron Nodes.
Zum aktivieren musst du zyklisch ein Nachricht an das VenusOS senden, andernfalls wird das senden der Daten wieder abgestellt. Ich mache das wie folgt. Für die Zahl musst du deine Victron VRM ID einsetzen.
Vielen Dank für den guten Input. Kenne mich mit Node Red leider noch nicht so gut aus… Ich habe allerdings nichts brauchbares im Internet gefunden. Nach welchen Begriffen suche ich da am Besten?
Ja da heut zu Tage was zu finden ist nicht so einfach, da es ja jetzt das Large OS und die VictronNodes gibt, nutz niemand mehr das “alte” System.
Ich hab mich damals an das Video von Meine Energiewende gehalten, das hat mir gut geholfen. Da wird alles erklärt. Da musst du dir nur die Teile rauspicken die relevant sind. MQTT-Broker hast du ja schon irgendwo installiert, brauchst du also nicht mehr machen.
Hier das Video
Danke, das habe ich bereits versucht. Das ändert leider gar nichts… Beide Pace BMS erhalten immer die selbe VM ID… Ich könnte zwar die PACE BMS miteinender per CAN verbinden, dann kann ich aber die High/Low Zellenspannungen nicht von jeder einzelnen Batterie erfassen. Da werden dann nur High/Low aller Zellen gesammelt angezeigt. Also z.B. High Batterie 1(Zelle 5), Low Batterie 2(Zelle 16).
@cyborgxxl
Ich kann dir vielleicht nicht mit der Programmierung via NodeRed helfen habe aber folgende Info die dir ggf. weiterhelfen kann. Ich frage meine Pace BMS unabhängig von der CAN-Bus Anbindung zum Cerbo über die RS232 Schnittstelle ab. Und dort ist die übergebene Pack-No immer 1 auf dem benutzten RS232 Port. Nur wenn ich den RS232 Port vom ersten Akku nutze und darüber alle anderen mit abfrage ändert sich auch die Pack-No.
Danke… ich vermute mittlerweile auch, dass das Problem irgendwie damit zu tun hat. Das würde auch erklären warum manchmal BMS 1 und manchmal das BMS 2 angezeigt wird. Wahrscheinlich haben beide die ID1 und je nachdem wer schneller antwortet landet dann im VRM Portal bzw. am Cerbo GX. HAst du die BMS miteinander verbunden und die Dip Switches auf 1, 2, 3 eingestellt?
Verstehe ich dich richtig, dass zu zusätzlich zum CAN auch über RS232 abfragst? Also eine parallele Abfrage? Wusste gar nicht, dass das funktioniert.
@cyborgxxl
Ja, ich frage die unabhängig vom CAN-BUS ab.
Funktioniert hiermit:
Habe aber umgestellt auf diese Verbindung, (1 pro Akku, weil auslesen aller geht wie schon geschrieben für alle wenn am 1.Akku abgefragt wird. Will man Parameter ändern geht das nur wenn das BMSTool direkt mit dem entsprechen Port verbunden ist. Sonst wird die Änderung immer nur im 1. Akku vorgenommen - “kleiner Fallstrick” )