Hallo,
ich denke über ein Projekt nach, bei dem ich über einen Raspberry und Bluetooth die Daten meiner JK-BMSse (JK-B2A8S20P) auslesen will.
Hat sowas schonmal einer von euch gemacht?
Gibt es irgendwo einen Parser für das JK02 Protokol oder eine Dokumentation hierfür?
Gruß, N.
guck mal auf github, da stehen mehrere Parser und auch was mit BT connection. Teilweise hilft auch ChatGPT oder andre AI’s
ich würde allerdings die RS485 Schnittstelle bevorzugen, das ist einfach weniger ‘trouble’
Grüsse!
Phil
und hier noch ne Modbus Register Map, die ich mal irgendwann irgendwo gefunden hatte. ich weiss allerdings nicht, zu welcher JK Generation die jetz gehört…
BMS RS485 Modbus V1.1.pdf (150,7 KB)
Grundsätzlich gibt es (zumin bei der PB Serie, aber wahrscheinlich bei P genauso) zwei Arten mit den Daten.
Eine ist man schickt da ein w Command hin und bekommt alles in einem Rutsch zurück und muss das auseinanderpflücken, und die andre ist eine Modbus Kommunikation mit read_register.
Zweiteres hab ich für die Cell Voltages mit nem Python Skript auf Raspi realisiert. Steht auf meinen github GitHub - philippoo66/jk-pb-cellvolts: Simple solution to read all the cell voltages via RS485 Modbus and publish them to MQTT
Hallo Phil,
erstmal vielen Dank für deine Antwort.
Leider kann ich dein Projekt nicht direkt umsetzen – jedenfalls nicht so einfach. Ich möchte auf jeden Fall über BLE mit dem JK BMS kommunizieren, aus Sicherheitsgründen (z. B. BT blocken).
Dein Python-Skript nutzt Modbus RTU über RS485/USB. Mein BMS per BLE spricht jedoch eine eigene BLE-Frame-Struktur (JK BMS BLE). Registeradressen, Befehle, Checksummen etc. passen daher nicht.
RS485 ist seriell, synchron, Master/Slave.
BLE ist paketbasiert, asynchron, über Notifications/Write/Read.
Übernehmen könnte ich z. B. den MQTT-Teil, der sollte unabhängig vom Transport funktionieren.
Bisher kann ich mich mit dem BMS verbinden und erhalte auch Werte – was mir aber fehlt, ist eine Zuordnungstabelle der Hex-Werte für mein BLE-BMS (JK-B2A8S20P). Ohne diese kann ich bisher nur die Zellspannungen auslesen, alles andere noch nicht. (abgesehen von den Type3 Daten, wie Modell, Version, Serial, Passwort, usw.)
Wenn du irgendwo so eine Tabelle hast oder Hinweise, wie man die BLE-Frames richtig dekodiert, wäre das extrem hilfreich.
Viele Grüße, Mik
Wenn du dir die Arbeit machen möchtest dann kann du hier reinschauen:
Ich würde allerdings hingehen und einfach diese ESP Home Komponente auf einen ESP32 flashen. deinen MQTT Server konfigurieren und dann hast du ja alle Möglichkeiten offen.
Ein ESP32 bekommst du für 2€ / Stück aus Fernost oder 5€ / Stück Amazon.
Mach ich selber so und ist dann direkt im HomeAssistant Dashboard verfügbar:
Hallo und gutes neues Jahr noch.
Ich habe mich nun schon länger mit dem Thema JK BMS, BLE und Protokoll beschäftigt. Ich möchte keinen ESP32 oder RS485 o.ä. benutzen.Beziehungsweise nicht noch mal. Ich habe mehrere LFP Blöcke. Drei sind schon JKBMS und per 485 und Terminalserver angebunden. Daly und JBD sind auch dabei und die kann ich per BLE abfragen. Nur bei den JK klappt das nicht.
Mich dünkt auch dass die Dokumentation des/der Protokolle etwas nebulös ist. Ich bekomme eine BLE Kommunikation zu JK PB und B Serie hin, aber ich kann den guten Stücken nicht die wichtigen Daten entlocken. Ich hoffe nun dass mir jemand hier die Augen öffnen kann.
Die Präambel ist immer AA 55 90 EB gefolgt vom Kommando 96 oder 97. Es sollen dann Frames mit Kennung 01, 02 und 03 folgen. 01 und 03 bekomme ich. Frame 02 würde aber die Spannungen und SOCs enthalten. Die fehlen mir. Das ist aber das Interessanteste.
Meine PBs und Bs sind HW Version 15. Im Netz fand ich unterschiedliche Informationen zum Kommando 96. Entweder es folgen irgendwelche Bytes mit CRC oder nur Nullen. Bei meinen JKs ist das Resultat immer das selbe.
Da erst 1 Tag vor Sylvester ein Daly inoperabel geworden ist, ist mein Wunsch das nun doch zu realisieren umso dringlicher. Denn das Daly konnte ich abfragen, das dort neu installierte JK nun nicht mehr. Mir ist klar, dass 485 Anbindung in Sachen Echtzeitdaten seine Vorteile hat. Erfahrungsgemäss ergötzt man sich bei neuen Installationen und Blöcken tagelang an den sich bewegenden Volt Pegeln. Das legt sich dann aber und dann reicht es den Block alle 2 oder 3 Minuten abzufragen.
Freue mich auf Antworten zum Thema JK, BLE, 96 und was steckt dahinter. Doku, auch gerne in Englisch, ist herzlich willkommen. Die einschlägigen Github Seiten kenne ich aber schon.
Gruss, M.
PS. Will auch kein Home Assistant oder Venus oder all das. Habe das alles ausgetestet und ich möchte gerne bei meiner Eigenbau-RPi-Windows-Web-Lösung bleiben. Das auch deswegen weil meine Anlage mit insg.50kwh Kapazität Offgrid ist und ich die WR nach Bedarf und Kapazität hier und dort zu- oder abschalte.
Frohes Neues an dich, Michael.
Das 01er und 03er Framesind allgemeine Datenframes.
Was du brauchst, ist das 02er Frame - das sind die Nutzdaten.
Die sind aber Hexdaten und du musst sie entschlüsseln.
Die Dokumentation ist schlecht bis nicht vorhanden.
Das, was du gerade machen willst, habe ich zuletzt gemacht.
Ich habe ein komplettes Dashboard realisiert, das mir aus 2 JK BMSsen alle für mich relevanten Daten ausliest und diese sende ich per websocket an ein html frontend und es läuft komplett autark.
Dass ich die Daten dann nochmal zusätzlich per MQTT sende und sie auch in Home Assistant nutze, steht auf einem anderen Blatt Papier.
Mit welcher Sprache willst du über BLE an deine JKs heran treten?
Was ich dir jetzt schonmal versprechen kann, ist, dass es schwierig ist, die BLE Kommunikation sauber und stabil zum laufen zu bringen - dafür habe ich lange gebraucht…
Du benötigst hierfür Watchdogs, die deine Komponenten und Verbindungen bei Bedarf (=Störungen) neu starten.
Du benötigst weiterhin gute BT USB Sticks, zudem würde ich auf USB 2 setzen, da USB 3 Interferrenzstörungen verursacht.
Ok - der für dich vermutlich derzeit wichtigste Punkt:
Ich habe eine JK Mappingtabelle erstellt, die dürfte dich interessieren.
Lass mir mal deine mailadresse zukommen, ich habe noch ein paar weitere Dateien mehr, die für dich relevant sein dürften.
Noch ein Hinweis: Es gibt in Deutschland eine kleine Firma, die stellt BMS2mqtt Gerätchen her.
Kosten kaum mehr als 35 Euro pro Stück - als ich meine JKs angezapft habe, hatten sie für JK noch nichts. Das könnte sich jetzt aber auch geändert haben, leider komme kich grad nicht auf den Namen. Vielleicht kannst du es heraus finden.
Mein Dashboard, rein über BLE für die JKs und VE.Direct für den Victron sieht so aus:
Du siehst, dass der letzte Reboot ziemlich genau 10 Tage her ist, du siehst weiterhin, dass BT1 seit fast 14000 Frames läuft, während BT2 quasi gerade erst resetttet hat.
Meine Framerate liegt bei ca. 2 Frames pro Sekunde bei den BMS und 1 Frame pro Sekunden beim Solarregler.
Hallo Nordpol,
nun ist mir noch kälter als zuvor. Was ein Name. 
Wegen der Asynchronität bei BLE verwende ich hier Python.
An Deiner Zusammenstellung bin ich sehr interessiert. Klar kann ich Dir eine PN senden, aber ich glaube ganz fest, dass eine Community vom Gemeinsam lebt.
Gruss, M.
Das ist ok so.
mache ich im Übrigen auch.
Ich nutze Python hier primär wegen der asynchronen BLE-Anbindung über Bleak + asyncio.
Die Asynchronität ist gezielt auf die I/O-lastigen Teile beschränkt:
parallele BLE-Verbindungen zu mehreren BMS
gleichzeitiges Empfangen von Notifications
nicht-blockierendes Connect / Reconnect mit Backoff
periodische Keepalive-Writes pro Gerät
Technisch läuft pro BMS ein eigener asyncio-Task, der den kompletten Lebenszyklus der Verbindung kapselt (Connect, Notify, Timeout-Überwachung, Reconnect). Dadurch blockiert kein Gerät ein anderes, auch wenn Verbindungsaufbau oder BLE-Operationen gerade warten.
Die eigentliche Datenverarbeitung (Frame-Parsing, Logging, MQTT/SocketIO-Weitergabe, File-I/O) ist bewusst synchron gehalten. Diese Teile sind:
CPU-leicht
kurzlaufend
nicht I/O-kritisch im BLE-Timing
Eine vollständige „Async-Durchdeklinierung“ würde die Komplexität erhöhen, ohne messbaren Gewinn zu bringen. Deshalb setze ich Async dort ein, wo es notwendig ist (BLE-I/O und Verbindungsmanagement), und bleibe synchron, wo es einfacher und robuster ist.
Was deinen Community-Ansatz angeht:
Ich komme noch aus den „Self-HTML-Zeiten“ und habe mir angewöhnt, anderen vor allem Hilfe zur Selbsthilfe zu geben – also Konzepte, Denkansätze und Stolperstellen zu erklären, statt fertigen Code zu veröffentlichen oder Lösungen einfach zu kopieren.
Das hat sich für mich über die Jahre als der nachhaltigere Weg erwiesen, gerade bei technisch sensiblen Themen. Deshalb teile ich solche Dinge lieber im direkten Austausch, wo man auch Kontext, Grenzen und Hintergründe sauber mitgeben kann.
Zu lesen, dass du das Thema grundsätzlich anders angehst und eher auf Veröffentlichung setzt, lässt mich ehrlich gesagt etwas zögern, weil das nicht ganz meiner Art entspricht. Das ist nicht wertend gemeint – nur eine unterschiedliche Herangehensweise.
Gruss retoure,
auch M. 
Moin,
ich habe mir mehrere Github Projekte zum Thema angesehen. Wenn man dann in issues nachsieht findet man zB bei mpp-solar Einträge, dass ab HW 15 die JKs anders sind in Punkto Kommunikation per BLE. Auch unser Kumpel Andy aus Australien hat ja mehrfach darauf hingewiesen, dass neues BMS eine neue Handy-App benötigt.
Diese Plattform erlaubt keine PN. Ich habe auch keinen fertigen Code erwartet. Ich bin auch im Solar-Stromer Discord unterwegs.
Um meine System Herangehensweise darzustellen. Ein RPi mit einem ASUS BT USB Stick sammelt die Daten ein und schiebt alles in eine SQL Datenbank. Ein Windows Server greift sich die Sachen und verarbeitet es.
Ich verstehe nicht, warum die Hersteller die Protokolle immer dauernd ändern müssen und dann auch noch keine Doku liefern. Im Bereich der OpenSource ist das auch daher ein Thema, weil die Entwickler von mpp-solar u.a. ja nicht alle x Wochen neue BMS kaufen können.
Zurück zu meinen JK. Ich glaube derweil die Antwort ist weniger im Kommando 96 zu suchen und zu finden als mehr in den Settings vom JK. Dazu kommt, im Netz gibt es Berichte, dass die HW 19 wohl gar nicht mehr auf ffe0/ffe1 reagiert. Daher kann die ganze Mühe für HW 15 für die Katz sein. Wir bräuchten Infos von den Herstellern. Eine API Beschreibung.
Gruss, M.
Ich darf mich revidieren.
Es geht. Nun bekomme ich den Frame 2 mit den Zelleninfos.
Für alle die das gleiche Thema haben. Frame 2 kommt nicht per BLE, wenn ihr das Passwort zum Pairen des BMS nicht (!!!) geändert habt. Default ist 1234. Ich meine nicht das Passwort 123456 zum Ändern der Advanced Settings. Solange das Bluetooth Password auf Default 1234 ist, geht kein Frame 2.
Warum auch immer das so ist.
Gruss, M.
Ist genau meine Konfiguration, nur dass ich 2 USB Sticks verwende.
Nochmal - wenn du einen Pi4 hats, nimm auf jeden Fall die USB2 Ports.
Interessant wären jetzt mal 1 oder 2 Frames von dir - denn genau die musst du ja reengineeren.
Optimal wären z.b. 2 Frames, deren Echtzeitwerte du kennst - dann wirds einfacher.
Problem ist, dass man selten Beides hat - den Frame und den echten Wert.
Ich hatte hier das Glück, dass mir jemand meine Frames mit seinem c++ - Script übersetzt hatte.
Deine Vorgehensweise, sql den Mittler zwischen den Daten spielen zu lassen, halte ich für suboptimal - es sei denn, dass du nur selten Daten benötigst.
Aber je BMS 2 Hz an BLE-Daten (das ist die übliche Datenfrequenz von JK) macht über sql keinen Sinn.
Schau dir mal websockets an oder alternativ mqtt - so macht man das eigentlich.
Dass du einen Teil der Daten dann trotzdem z.b. zur Langzeitanalyse deine DB zuführen kannst, ok.
Der 0x97 ist ein Initial-/Wakeup-Command.
Der 0x96 ist ein **Status / Live-Daten Command, er hält sozusagen die Verbindung alive.
**
Hier die Kurzfassung meiner Vorgehensweise:
JK-BMS per BLE auslesen (Kurzfassung)
Verbindung per Bluetooth Low Energy (BLE) zum JK-BMS
Nutzung einer GATT-Characteristic
Nach dem Connect werden Status-Commands (z. B. 0x96 / 0x97) per Write gesendet
Das BMS sendet daraufhin alle Daten per Notification
Keine GATT-Reads, kein Polling
Die binären Daten werden anhand der JK-Startsequenz 55 AA EB 90 zu Frames zusammengesetzt
Auswertung des Cell-Info-Frames (0x02) → Zellspannungen, Strom, SoC, Temperaturen usw.
Regelmäßige Writes dienen als Keepalive (bei mir glaube ich alle 180 Sek.)
Was deine JKs angeht, du hast doch HW15, oder nicht?
Und um diese BMSse geht es doch, oder habe ich dich mißverstanden?
Ach - und schalte unbedingt den internen BT des RPi ab - der hat bei mir ausnahmslos für Ärger gesorgt, egal ob beim RPi3 oder RPi4.
Hallo,
Du hast mich nicht miss verstanden. Aber wie ich schrieb, es geht ja jetzt.
Passwort setzen ist essentiell. Mit dem Default Pairing Passwort geht nur wenig vorwärts und rückwärts.
Gruss, M.
