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.
)und zweitens, in der Zeit wird balanzieret, und zwar nur! in der Zeit...
