Ich habe euch den letzte Protokoll-Talk abgetrennt, zurück bis zur Seite 76 des Original-Fadens.
Sorry falls der Trennpunkt nicht optimal war.
Falls weitere Themen abtrennbar sind oder neu geschaffen werden können - gerne.
-- Carolus --
-------------------------------------------------------
Ich habe gestern auf meine HW15.0 und 15.2 Firmware 15.30 installiert.
Fun Fact:
15.0: UART2 Protokoll steht wie auch davor auf 15 und lässt sich nicht ändern
15.2: UART Protokoll lässt sich zwar auswählen, aber "OK" ist ausgeblendet
CAN=2 (Pylon) hat endlich richtige Anzahl der Module im Protokoll, aber auch die "Magic Bytes" "0x50 0x4E" in 0x359
Ich habe gestern auf meine HW15.0 und 15.2 Firmware 15.30 installiert.
Fun Fact:
15.0: UART2 Protokoll steht wie auch davor auf 15 und lässt sich nicht ändern
15.2: UART Protokoll lässt sich zwar auswählen, aber "OK" ist ausgeblendet
CAN=2 (Pylon) hat endlich richtige Anzahl der Module im Protokoll, aber auch die "Magic Bytes" "0x50 0x4E" in 0x359
Wenn die Basics mittlerweile stimmen, kanns ja nur besser werden. Danke für deine Beobachtungen.
Float-Voltage Bug in FW15.30 ist auch im Pylon-Protokoll enthalten (also nicht nur Victron) :/
EDIT: mein fault, es geht doch. Float fängt nach eingestellter Zeit an.
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 😉
Wenn ich die CAN auf Pylon Stelle fehlen bei mir die Details auf Venus OS und im Victron Protokoll 14 laufen sie nur unter 500kbit.
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)
An der Stelle kleine Werbung für mein Projekt: https://www.akkudoktor.net/forum/open-source-software-projekte/projektvorstellung-mitpylon-man-in-the-pylon
Ich werde mich nächste Zeit mit JK eigenem Protokoll beschäftigen (sind dann auch 29bit IDs).
Du meinst das hier?
http://www.jk-bms.com/en/Upload/2023-12-05/1600531633.pdf
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 🙂
JM2C