Ich glaube man müsste eine Bug und eigene Feature Request Liste erstellen, an Andy aushändigen damit er die an JK übergibt. Und dann können wir abhacken was gemacht wurde bzw. was kaputt gemacht wurde. Bug-Tracker Comunity Edition.
Oder JK soll einfach die FW als Open Source anbieten, wir machen das schon
Die Probleme sind glaube ich grundlegender. Habe mir jetzt im Übrigen auch mal 3 JK-BMS bestellt um damit rumspielen zu können. Hierzu muß man wissen das es zwei grundlegend verschiedene BMS Protokolle von Victron gibt. Anfang der Woche habe ich dazu lange mit dem Entwickler des Boostech BMS telefoniert. Das bessere Protokoll Victron Nr. 1 implementiert deshalb niemand, weil Victron Nr. 2 bei vielen Wechselrichtern passt.
Victron BMS Protokoll Nr. 1) basiert auf NMEA2000. Das ist eine super Sache die man einfach einsteckt und es funktioniert. Das Protokoll wird auch von den neuen RS450 MPPT genutzt. Es läuft auf 250kbit mit den 28 bit langen Identifiern und hat eine Autokonfiguration bis 50 Busteilnehmer. Die Bootsleute brauchen etwa immer einen Bildschirm fürs Radar. Das Radar selbst ist vielleicht von Raymarine, der Tanksensor von X und das BMS von Victron. Jedenfalls mit Victron BMS Protokoll Nr. 1 = NMEA2000 stöpselt man das so einfach wie Lego zusammen und es funktioniert einfach weil das Protokoll bis Anwendungsschicht 7 reicht. Das Victron Lynx BMS hat das Protokoll, kann aber nicht balancieren, die Batterien sind viel zu teuer und mit ist kaum ein anderer Hersteller bekannt, der dieses Protokoll implementiert hat. Einer der wenigen scheint Bluenova zu sein, aber auch nicht auf den Racks für Heimanwendungen. Wie das aussehen kann sieht man etwa hier: Nachdem man einsteckt wird neben dem Rader von Simrad auf dem Touchscreen von Raymarine einfach der SOC von Victron angezeigt. JK & Co könnten das auch, aber sie haben entweder das Protokoll nicht verstanden oder richten sich lieber nach Deye, Goodwe & Co aus weil deren Markt größer als der Bootsmarkt ist.
Victron BMS Protokoll Nr. 2) ist wohl weder von Victron noch von Pylontech sondern vermutlich von SMA von denen es den Sunny Island als erstes gab. Wie man beiliegender Tabelle aus Github sieht, sind die Protokolle Pylon, SMD, Victron alles das Gleiche nur mit leicht unterschiedlichem Implementierungsumfang bzw. unterschiedlich verschlimmbessert. Es handelt sich um ein Punkt zu Punkt Protokoll bei 500kbit mit 11 bit Identifiern von CAN welche zu sowas nie gedacht waren. Als Folge davon werden nie mehr als 2 Teilnehmer am CAN Bus sein können und für die Slave Batterien braucht man einen extra CAN oder RS485 Bus mit zusätzlicher Hardware. Alles was an diesem Protokoll noch geschustert wird, verschlimmbessert die Sache weiter. Dazu gehört auch der Pylontech LV-Hub oder andere Versuche das zu retten. Grundlegende Funktionen der Transportschicht wie etwa Fehlerkorrektur, Wiederholstrategien, Datensegementierung, Flusskontrolle fehlen. Es wird sie genauso wie eine Autokonfiguration der Busteilnehmer gar nie geben können. Deshalb ist dieses Protokoll ein totes Pferd auf welchem aber komischerweise alle reiten wollen.
@janvi Der Markt ist halt nun mal so, dass man eher auf die "Standardlösungen" setze. Das ist Pylon (und deren Ableitungen wie SMA/Vistron und co) sehr verbreitet und weit unterstützt.
Es hindert niemanden daran einen Adapter dazwischen zu packen der genau das mach was man will.
Aber ansonsten hat JK doch sehr guten Job gemacht: die meistens BMS werden nicht mal annährend so viele Informationen liefern, dann auch mit WRs direkt kompatibel sein.
Ich werde mich nächste Zeit mit JK eigenem Protokoll beschäftigen (sind dann auch 29bit IDs). Da bekommt man über CAN alles was man wünscht, sogar die Zellspannungen einzelnen Packs.
Da kann man dann Victron oder Pylon oder was auch immer daraus basteln (machen die Kollegen von denen die Screenshots stammen ja auch).
Der Rest an nützlichen Information geht direkt ins HomeAssitant (in meinem Fall)
Ich habe weiter in die CAN-Bus Welt mit FW15.30 eingestiegen.
Deye=Pylon, was auch Sinn macht.
Es sind neue Messages dazugekommen:
Bei beiden sind 0x370 und 0x371 (kann aber auch daran liegen, dass ich 2x BMSen mit Master Slave habe). Siehe Screenshot ein paar Posts höher, PYLON+, 0x70=0x370... und da haben wir wieder den Salat
0x35e: da stand früher "JK-BMS", jetzt steht da Text aus "User Private Data", den man selbst eingeben kann! Das ist ja cool! Kann das jemand mit älteren FW checken ob das schon früher so war?
Ist vermutlich erst unlängst mit V2.1 mit den llangen Identifier ergänzt worden. Da sind jetzt auch die Daten der Einzelzellen. Das Protokoll scheint aber noch immer keine anderen Teilnehmer auf den CAN Bus zu berücksichtigen?
@janvi das ist BMS Protokoll, welche andere Teilnehmer? In diesem Fall geht JK davon aus dass es nur BMS und ein Zuhörer=WR an der Leitung sitzen.
Dafür werden die Daten von ALLEN JK BMSen in geschickt, da werden die CAN IDs einfach hochgezählt, stand irgendwo... muss noch ausprobieren, aktuell keine Zeit dafür.
Andere Teilnehmer sind andere CAN Slaves. Das können andere (Master)Batterien oder auch MPPTs wie der RS450 von Victron sein. Der WR oder Cerbo ist immer der CAN Master. Ordentliche Protokolle können auch Multimaster aber ich wäre schon froh wenn mehrere Slaves oder wenigstens mehrere gleichartige JK an einem CAN Bus als Slave laufen würden. Der Name (CAN)Bus kommt von Omnibus. Das ist lateinisch und heisst "für Alle". Das hochzählen der CAN Ids wäre eine (schlechte) Möglichkeit das zu realisieren. Das machen auch weder Pylontech noch SMA so. Deshalb wird das aktuell auch kein WR verstehen. Er müsste dazu auch die Bereiche scannen wo etwas Antwortet und dazu die Batterie Aggregation einrichten. Die CAN IDs sind aber vor Allem gar nicht für so etwas gedacht. Sie werden nämlich in der CAN Peripherie in Hardwarevergleichern ausgewertet. Bei Gleichheit gibts einen Interrupt und die Software kann das 8 Byte Telegramm zur Auswertung abholen. Telegramme an die anderen 100 Busteilnehmer (JK-BMS) müssen auf diese Weise gar nicht von allen Busteilnehmern ausgewertet werden weil die Hardware das über die IDs schon wegfiltert.
Von Andy gibts im Übrigen ein neues Video wegen der fehlerhaften SOC Anzeige. Diese beruht auf fehlerhafter Strommessung. Wenn Andy hierzu befragt wird wie das zu lösen geht und er nur die halbe Lösung hat ist das ok. Es lässt aber leider auch erahnen, daß die Entwickler bei JK zum ersten Mal einen Analogeingang sehen.
@janvi@Eugenius könntet ihr bitte zum CAN-Thema vielleicht einen eigenen Thread eröffnen?
Ich verfolge eure Diskussion mit hohem Interesse, da ich beruflich selbst auch mit Bussystemen zu tun habe. Aber ich denke, für die meisten JK Inverter BMS user geht das mittlerweile zu weit ins Detail - insbesondere da es mit der altuellen usability nichts mehr zu tun hat. Danke euch
das kann man nicht unbedingt pauschal so sagen. Bei CANopen z.B. sind die Default COBs immer irgendwas + Node ID. Bei UDSonCAN bsw. sind die COB IDs auch direkt and die ECUs gebunden, eine für Request und eine für Response...
Aber ich stimme @gura zu - das gehört eigentlich nicht hier hin
Die Usabiltiy ist halt dann betroffen wenn man mehrere BMS an einem Bus betreiben möchte. Der zweite Bus zum Anschalten von Slave BMS ist auch weitgehend undokumentiert und konzeptionell begrenzt. Freilich dürfte diese Batteriegröße für die meisten Heimanwender nicht relevant sein. Die Hersteller zeigen aber liebend gerne größere Containerinstallationen. Sowohl Pylon wie auch Pytes umgehen das mit einer eigenen LV-Hub Hardware. Dass das JK BMS daran mit dem nachgebauten Protokoll funktioniert möchte ich bezweifeln. @Eugenius bastelt ja an so einer Kommunikationsbox und wir machen dort weiter. Die Firma JiKong können wir hier in diesem Thread sowieso nicht sanieren und wenn es dann was Neues speziell zum JK Inverter gibt, können wir das Resultat immer noch hier posten.
Solange @eugenius nicht doch noch ein JK CAN Protokoll mit adressierbaren CAN IDs hinkriegt sehe ich nur einen (etwas komplizierten Um-) Weg über RS485 und einen USB Hub zum Betreiben mehrerer Master BMS. Das RS485 Protokoll hat in der Regel auch den Vorteil, daß mehr Infos bezüglich der Einzelzellenwerte verfügbar sind. Über den internen RS485 Bus kann das JK bis zu 15 Slaves an einem Master betreiben. Damit braucht man nur noch einen RS485 zu USB Konverter und belegt nur eine USB Buchse an einem doch relativ billigen USB Hub. USB kann man ja grundsätzlich auf n Anschlüsse kaskadieren.
Zum Glück hat das Venus OS dazu auch noch das geniale dbus Konzept aus freedesktop.org zur Interprozesskommunikation über einen Software Datenbus übernommen. Mit Serialbattery sollte man damit beliebig viele Master Batterien als Device mit Venus verbinden können ohne hierzu selbst eine Hardware löten zu müssen. Die vielen Master Batterien lassen sich dann mit einem Dbus Treiber Aggregate-Batteries zusammenfassen damit Venus über das DVCC die gemeinsame Steuerung übernehmen kann. Damit sollte dann ein von der Leistung her offenes Konzept für mehr als 16 Batterien ohne LV_Hub vorhanden sein. Zumindest wenn das mit den JKBMS so tut wie es die Projekte auf Github versprechen. Meine 3 JKBMS kommen irgendwann nächste Woche und dann kann ich das mit meinem ebenfalls noch rumliegenden Cerbo-GX einmal ausprobieren.
Für normale Inverter Deye & Co ist das natürlich etwas zuviel verlangt und diese wären weiterhin auf ein vernünftiges Protokoll angewiesen was dann auch ganz ohne zusätzliche Hardware RS485 Converter und USB Hub funktionieren könnte. Vermutlich wird es solch Protokoll aber nie geben, weil die anderen WR selbst eben auch nicht wie die Multiplus mit externen MPPTs beliebig parallelschaltbar und erweiterbar sind und damit auch keine größeren Batterien brauchen.
Da geht es darum, dass ich nur das, was JK über "PYLON" Protokoll sendet auswerte, evtl. modifiziere und weiter an WR sende. Da gibt es leider keine einzelne Zellen. Aber seit kurzen zumindest höchste und niedrigste Zelle Spannung über ALLE Akkupacks (auch Slaves)
Das was ich extra machen wollte: JK-BMS CAN Protokoll decodieren und daraus selbst PYLON Protokoll für WR erzeugen. Vorteil: so hat man Spannungen auch für einzelne Zellen von allen Akkupacks (Auch Slaves). Das hat bei mir sehr niedrige Prio.
Was die anderen schon gemacht haben: RS485 von alten JKs zu PYLON Protokoll um geschlüsselt. Das muss auch mit JK Inverter BMS gehen.
JK Inverter BMS hat seit Kurzem auch PYLON RS485 Protokoll. Da sollen auch einzelne Zellen geben (bin mir nicht sicher), auch dafür gibt es Adapter im Netz.
In allen Fällen:
Über PYLON Protokoll gehen an den WR keine einzelnen Zell-Spannungen.
In allen Fällen versuche ich alle Daten die kommen auch an HomeAssistant bzw. MQTT zu senden.
3 Stück sind freilich kein Problem. Das Projekt hat aber Platz für mindestens 40 JK-BMS bzw. mehr als 500kWh. Es gehen aber nur Gruppen von maximal 16 Stück. Deshalb müssen mehrere Master vorhanden sein. Die funktionieren wegen der gleichen CAN Ids aber nicht auf dem CAN Bus sondern immer nur einer. Die 3 JK BMS habe ich nur zum Ausprobieren bestellt weil das die Mindestanzahl ist um zwei Master und einen Slave zu testen. Wenn dann zwei Master gehen nehme ich an daß auch weitere funktionieren.
Ja, vom Protokoll her geht das prima. Meine original Pylons habe ich auch schon mit FHEM auf der RS485 ausgelesen. Da erhält man alle Daten der Einzelztellen. Leider funktioniert das nur bis 12 Stück in einer Gruppe und nicht bis 16 Stück obwohl diese ansonsten erfolgreich kaskadiert werden. Steht auch so in der Pylon RS485 Protokoll Beschreibung drin. Weil Pylontech hier auch noch weitere undokumentierte Tricksereinen mit zusätzlichen 3 Hardware Leitungen macht, nehme ich an daß die JK RS485 im Pylon Mode auch nicht auf dem Pylon LV-Hub laufen. Werde ich aber ausprobieren.
USB ist eine der wenigen billigen Möglichkeiten eine große Anzahl von Ports an den Cerbo zu kriegen. Beliebige Anzahl von CAN Ports gehen im Venus zwar auch, stelle ich mir in der HW aber gegenüber virtuellen Com Ports problematisch vor. Deshalb seriell. Sternförmig muß die Verdrahtung sowieso werden. [quote data-userid="7967" data-postid="231834"]
In allen Fällen:
Über PYLON Protokoll gehen an den WR keine einzelnen Zell-Spannungen.
In allen Fällen versuche ich alle Daten die kommen auch an HomeAssistant bzw. MQTT zu senden.
[/quote]
Das betrifft das Pylon CAN Protokoll aber nicht das RS485
MQTT geht auch über den Cerbo wenn die Daten dortselbst erst mal ankommen
Im Übrigen habe ich zwischenzeitlich ein YT-Video gefunden der genau das was ich vorhabe vorgemacht hat. Allerdings mit JBD-BMS über RS485. Müsste aber mit JK genauso gehen.
