Nachdem es hier soviele Probleme mit der Kommunikation gibt: Auch ich warte seit längerer Zeit darauf endlich ein BMS bestellen zu können welches nicht nur bezüglich der Batterie gut funktioniert, sondern das auch noch gut kommuniziert. Derweil betreibe ich ein 2x16 Array Pylons an einem LV Hub und habe mich aus diesem Grund etwas mit dem Pylon Protokoll auseinandergesetzt. Summa Summarum ist das kein Protokoll, sondern ein riesen Murks welcher irgendwie von Chinesen zusammgebastelt wurde, welche noch nie etwas vom ISO/OSI Stack, einer Vermittlungs oder Transportschicht gehört haben. Wenn das nun jemand anderes wie das JK emuliert, dann kann das eigentlich nur noch schlimmer werden aber niemals alles korrekt funktionieren.
Zur RS485: Ist sowohl bei JK wie auch Pylon ein schnödes Request Response Protokoll. Das ist allerdings nur als Punkt zu Punkt Protokoll realisiert während RS485 eigentlich Punkt zu Multipunkt bzw. Master zu mehreren Slaves gedacht war. Derzeit gibt es immer eine Master Batterie welche die Aggregation, also das Zusammenfassen der einzelnen Kapazitäten macht und dazu Protokoll Slave spielt. Die Slave Batterien sind über eine getrennte "interne" CAN Schnittstelle verbunden welche komplett undokumentiert ist. Die Aggregation hat ursprünglich nur für 8 Batterien funktioniert. Sie wurde später auf 12 Batterien erweitert. Unabhängig davon können mit der internen CAN Schnittstlelle bis zu 16 Batterien aggregiert werden. Wie schon Bill Gates einstmals DOS in weiser Vorraussicht von 512k Ram auf 640k Ram erweitert hat. Mehr braucht ja sowieso nie jemand obwohl es 286 mit MMU längst gegeben hat. Um das zu erkennen, hat es dann einen gewissen Linus Torvalds und Jahrzehnte für Microsoft gebraucht. Auf diese Weise bleibt die RS485 Implementation so immer nur eine Punkt zu Punkt Verbindung zwischen Master Batterie und Wechselrichter.
Hätte man ein solches RS485 Protokoll als Punkt zu Multipunkt ordentlich gemacht, würde es ein Produkt wie den LV_Hub zum zusammenschalten von mehreren Batterien überhaupt nicht geben. Mit etwas Hirnschmalz würde über einen Token Ring sogar Multimaster möglich. Der einzige Vorteil welchen das Pylon Protokoll hat, ist dass es ziemlich früh da war und Victron es deshalb ganz gut unterstützt. JK hat nun zusätzlich zur Pylon Emulation das Modbus RTP auf RS485 genommen. Das macht absolut Sinn hier das Rad nicht neu zu erfinden. Mit modernen RS485 Transceivern kann man 128 Busteilnehmer anschalten. Ein Hub ist dazu überflüssig. Leider scheint es so, daß das JK Modbus RTP Protokoll von niemand? unterstützt wird. Hier müsste nämlich der WR bzw. Cerbo GX die Aggregation übernehmen. Venus OS kann das und das macht auch als Einziges Sinn. Vielleicht müsste man da bei unseren blauen Freunden etwas Druck machen, denn Modbus kennen die bereits. Alle x Batterien in einem System müssen gleichbereichtigte Slaves sein. JK hätte mit Modbus RTP auch noch ein Stück weiterdenken können. Darüber gibt es auf Modbus RTP nämlich aufsetzend Sunspec welches die Inhalte der einzelnen Telegramme für die Anwendung Solar Wechselrichter definiert. Fronius ist zum Beispiel ein Hersteller welcher das überall eingebaut hat. Für die Chinesen ist das vielleicht etwas zuviel verlangt. Der Download der Sunspec PDF Beschreibung kostet für nicht Mitglieder stolze 500 Euro. Obwohl JK mit Modbus gegenüber Pylon bereits einen Schritt weiter ist, halte ich es für vergebliche Mühe darauf zu warten, daß JK mit einer endlichen Anzahl von FW Updates irgendetwas vergleichbar funktionierendes wie Sunspec hinkriegen würde.
Zudem: Modbus erlaubt keinen Multimaster Betrieb. D.h. wenn auch nur eine einzelne Batterie über RS485 mit dem WR verbunden ist, kann keine zweite Instanz wie etwa eine Haus-Visualisierung bei der Batterie auf der gleichen Schnittstelle Daten etwa für Einzelzellen anfordern. Den WR interessieren ja schliesslich nur die aggregierten Gesamtdaten anstelle der Details. Alles was nun zum Bsp. mit FHEM, OpenHAB o.ä. Daten auf der RS485 abgreift, funktioniert nur deshalb weil Pylon über CAN zum WR kommunizuiert und RS485 zufällig nebenbei bedienen kann. Das funktioniert aber nur solange man keinen LV_Hub zum zusammenschalten verschiedener Batteriegruppen hat. Hier wird nämlich die RS485 zusätzlich für interne und undokumentierte Zwecke benutzt. Um irgendwelche Versäumnisse im Protokollentwurf zu flicken, hat Pylon im Übrigen zusätzlcih 3 Hardware Steuerleitungen auf allen Schnittstellen aufgelegt. Die undokumentiere Funktion scheint Pylontech ebenfalls nicht so ganz genau zu kennen, weshalb man zum Nachtrag im LV_Hub Manual mit dem Hinweis diese im Kabel zur Master Batterie aufzutrennen gezwungen war. Darüber hinaus muß man beim Einbuchen von mehreren Gruppen im Hub eine bestimmte Reihenfolge mit 3x Piepsen der Teilnehmer, einstecken von Verbundungsleitungen und umlegen von Dipschaltern an einer bestimmten Stelle des Betriebs einhalten damit überhaupt etwas funktioniert. In allen Punkten erhebliche Definzite im Protokollentwurf welche durch eine Emulation nicht dokumentierter Eigenschaften durch JK nur noch schlimmer werden können.
Zum CAN: Ist es mit den von allen Chinesen implementierten Protokollen ebenfalls nicht viel weiter her. Bosch hat als Erfinder bei CAN leistungsfähige Hardware vorgesehen welche die Protokollsoftware und die Rechenlast deutlich vereinfachen soll. Diese HW steht praktisch in jedem uC mit CAN nebebei zur Verfügung. Allerdings sind sowohl die JK wie auch die Pylon CAN Protokolle so aufgebaut, daß diese Vorteile überhaupt nicht genutzt werden weil die Entwickler das Konzept nicht verstanden haben. CAN erlaubt mit seinen HW Funktionen etwa problemlos auch Multimaster Systeme. Die Adress Identifier haben HW Filter, so daß Slaves den Datenverkehr gar nicht mehr mitkriegen welcher für sie nicht bestimmt ist. Die CAN IDs werden aber sowohl bei JK wie auch Pylon gar nicht zum Adressieren der Slaves verwendet, sondern es sind die einzelnen Request Befehle darauf abgebildet. Das kann man machen, war aber nicht im Sinne des Erfinders Bosch und führt natürlich in eine Sackgasse. Um CAN universell zu halten, sind von Bosch absichtlich keine höheren Protokollschichten definiert. Äquivalent zu Modbus macht das etwa die CiA mit CanOpen. Diese definierten Prozessdatenobjekte (PDOs) und Servicedatenobjekte (SDOs) neben vielen anderen nützlichen Funktionen welche ein chinesischer Batterie oder BMS Hersteller nicht mal so nebenbei erfinden kann. Es gibt zwischenzeitlich sogar CanOpen mit Telegramminhalten für PV Systeme und DC-Netze mit Batterien. Ein alternativer Ansatz bei CAN ist NMEA2000 welcher sich im Bootsbereich und damit auch bei Victron bereits flächendeckend durchgesetzt hat. Daher nochmal: Es ist vergebliche Mühe darauf zu warten, bis JK mit einer endlichen Anzahl von FW Updates irgendwas vergleichbar funktionierendes hinkriegen würde.
Solange wird der Einsatz von Teilen wie dem JK BMS immer eine höchst fragwürdige Frickelei bleiben welche mit einer zusätzlich robusten Kommunikation nicht für die gewünschte Redundanz bei der Überwachung der erforderlichen Sicherheit sorgen kann. Bei Einzelbatterien kann das vielleicht noch halbwegs funktionieren aber nicht mehr als sorglos kaskadierbares System. Seit ich verstehe, warum es einen LV-Hub gibt, habe ich bei meinem fertig gekauften Pylon System aber auch kein besseres Vertrauen.
Ich verstehe von diesen ganzen Protokollen zwar nur Bahnhof - aber da du dich ja offenbar auskennst: Gibt es denn ein BMS, bei dem das in deinen Augen gut gemacht ist?
Bei mir läuft ein einzelner Pylontechakku an Victron, alles funktioniert, und er muß auch noch ein paar Jahre laufen, bis er sein Geld verdient hat. Den Bastler in mir würde es trotzdem reizen, einen größeren Selbstbauakku zu haben, aber ich habe halt auch eine Abneigung gegen Bauteile, die "90% fertig entwickelt" sind. Die BMS-Thematik hat mich bisher davon abgehalten, in die Richtung Eigenbauakku zu starten.
Auf ein ein perfektes BMS zu günstigem China Preis warten ja praktisch alle hier. Das JK hat die Nase im Rennen ziemlich vorne aber es fehlt eben noch viel bis zur Perfektion oder auch nur bis zum unauffällig problemlosen Betrieb. Ich würde liebend gerne auch meinen Akku selbst zusammenbbauen anstelle weitere Pylons zu kaufen. Die Pylons laufen sogar auch in Stückzahlen mit Hub aber man sollte halt nicht allzusehr hinter die Kulissen des Protokolls schauen.
Beim JK BMS tun das die Käufer hier typischerweise und auch berechtigt, nicht zuletzt von der Offgrid Garage angefeuert. Das ist auch gut so, denn mit Akkus ist wegen der Brandgefahr nicht zu spaßen. Die Ausführungen über Protokoll Grundlagen nur deshalb um besser zu verstehen, warum JK hier voraussichtlich noch weitere unendliche Runden mit FW updates drehen wird. Etwa genauso lange und aus den gleichen Gründen wie Micro$oft seit MSDOS gebraucht hat einen ähnlich gut funktionierenden Desktop wie Apple zu bringen. Vor allem wenn sie versuchen das Pylon Protokoll mit seinen konstruktiven Mängeln nachzubilden um bei all den WR Herstellern kompatibel zu sein welche Pylon draufschreiben.
Also meine drei JK BMS laufen per CAN gut an meinem Victron 3x Multiplus II + MPPT RS 450/200 + MPPT RS 450/100 System. (der Fehler das nur die Min und Max Zellen des Masterpacks berücksichtigt werden stört mich nicht, meine Zellen laufen gut und bei Ausreißern würde des BMS das Pack schützen.)
Welches Protokoll hast du eingestellt, gibt es eine Master Batterie oder sind irgendwelche Adressen bei den DIPschaltern der einzelnen BMS eingestellt?
Wie ist die Busverdrahtung CAN-in/CAN-out und die Abschlusswiderstände an beiden Busenden?
Hast du am Venus irgendwas modifiziert oder werden die Batterien einfach so erkannt?
Es scheint ja mal wieder eine neue FW Version für das JK zu geben in welcher einiges korrigiert ist. Trotzdem hat der Adressschalter wie bei den Pylons abgeguckt nur 4 bit und die Kaskadierung ist deshalb spätestens bei 16 Racks oder etwa 200 nutzbaren kWh konzeptionell am Ende. Über BT wäre die Einrichtung ohne Dip Schalter ganz einfach. Um das wieder geradezubiegen gibts dann ganze Shops die wieder davon leben sowas ähnliches wie den Pylon LV-Hub auf JK draufzusetzen.
Auf ein ein perfektes BMS zu günstigem China Preis warten ja praktisch alle hier.
Und gibt es was besseres zu europäischen Preisen? Das Rec BMS?
Soo, Off Grid Andi hat ein Video zu der neuen 15.30 FW gemacht, scheint wohl stabil zu laufen und man kann jetzt Bluetooth abschalten, einfach Doppelklick auf den An-Schalter. Ich habs getestet, funktioniert wunderbar.
...und das Tolle: Es ist keine Einbahnstraße!
Man kann Bluetooth auch wieder einschalten - gleichfalls mit Doppelklick auf den Taster 😉
Mit der nächsten FW-Version soll es auch die Möglichkeit geben die Einstellungen Importieren/Exportieren.
Das wäre tatsächlich sehr gut.
Habe schon überlegt das auf ModBus Basis als extra Programm zu machen, das kann ich mir dann wohl sparen
Gerade FW 15.30 probiert. Bei mir scheint der Float mode mit Victron nicht mehr zu funktionieren. Hat das auch noch jemand beobachtet?
Welches Protokoll hast du eingestellt und welche Schnittstellenverbindung ist dazu in Benutzung? Ist DVCC (forced) On? Lädst du vom Netz oder von einem MPPT?
@janvi 04 victron
es hat ja bei 15.24 super funktioniert. CVL kommt auch durch. Auch wenn ich was ändere kommt die änderung durch. Aber hab nur FW update gemacht dann gings nicht mehr.
Ist das Victron Protokoll auf der BMS CAN @500kbit Schnittstelle oder auf der VE-CAN (NMEA2000 Protokoll @250kbit) angeschlossen ? Falls VE-CAN, sind dort gleichzeitig RS450 MPPT dran? Diese sollten mit der letzten FW Version auch Schwierigkeiten beim Float haben. Mit ESS Assistent merkt man das aber gar nicht weil sie da vom Venus DVCC aus gesteuert werden. Offensichtlich wurde ja am Protokoll was geändert und möglicherweise hat das unerwünschte Nebenwirkungen
@janvi ist am bms can. Habe keine mppt nur multiplus.
also der CVL kommt ja durch. Daher schauts weniger nach protokoll sondern mehr nach einer logik geschichte aus. Aber wer weiss ob das in der FW überhaupt so getrennt ist
Datenkabel war ab. Victron neu gestartet. BMS neu gestartet.