JK-BMS CAN Support

[mrwillem]

Hello everyone,

I was wondering whether somebody already started to work on a CAN Driver for JK BMS.
As far as I have read different topics there is nothing going on in this direction
I tried to get RS 485 working with a JK BMS for two days but I gave up in the end.
In the meantime, I hacked the pylontech driver to accept CAN Messages from the JK BMS.
I had to slow down the CAN Datarate to 250 kbits and now I get basic data like voltage, current and temperature.
But I saw, that there is a lot of Data which can be aquired from CAN Bus by looking at the CAN-Messages.
Probably most of the data which can be seen in the app like single cell voltage or status of the switches.

This is for instance an extended CAN Message, which shows the configured capacity and the cycle count.
OpenDTU-FF4CF8 OpenDTU[3b0c2131] [Pylontech] Received CAN message: 0x18F128F4 - D1 0A 63 0B E7 33 04 00

A Documentation of the CAN protocol can be found here.
http://www.jk-bms.com/en/Upload/2023-12-05/1559288117.pdf

Just in case it does not work for other people I have to say that I changed the CAN-Transceiver on the CAN-ISO shield to a TCAN 330.
I am not sure whether I destroyed the original SN65HVD230 by inserting the shield in the wrong orientation or whether it simply does not work with the JK-BMS.
The TCAN was lying around here an it is pin compatible in this circuit. So I just changed it to see if it works 😄

There is also support for multiple BMS.
If you configure the "Device Addr:" Parameter in the JK App, the message identifier is increased by the value.
If you configure a 1 for instance then
0x02F4 gets 0x02F5
and
0x18F128F4 gets 0x18F128F5 and so on. So you could get data from more than one BMS.

[Manos1966]

Hi @mrwillem Wilhelm,

In the meantime, I hacked the pylontech driver to accept CAN Messages from the JK BMS.

👀 👀 👀 👀

So I presume you do have some knowledge....
I am surprised therefore that you were not able to make the JK BMS work, I know there is a lot of people here using OpenDTU-OnBattery with JK-BMS.

Did you read the Documentation?
https://opendtu-onbattery.net/hardware/jkbms/

[mrwillem]

Maybe some knowledge.... 😂
I have programmed few microcontrollers and worked with some (serial) protocols like I2C, SPI and MIDI.
But all as hobbyist.

Regarding the documentation, I have read it several times. It was making me crazy that it did not work
Unfortunately, I don't have a logic analyzer and I never worked with the esspressif things.
So I don't know how to debug the board properly.
But according to the logs, I think the BMS never returned data
May 18 19:53:04 admin OpenDTU[3560ded5] [ 15.011] JK BMS: busy waiting for or reading a message from the BMS
May 18 19:53:04 admin OpenDTU[3560ded5] [ 15.254] JK BMS: timeout wating for response from BMS
May 18 19:53:04 admin OpenDTU[3560ded5] [ 15.264] JK BMS: request for data sent
May 18 19:53:04 admin OpenDTU[3560ded5] [ 15.271] JK BMS: busy waiting for or reading a message from the BMS

First, I was using the original JK RS485 converter to connect it to the rs485 Bus via GPS Port.
But lateron I thought, that I might have the "wrong" version of the RS485 converter.
I am using a 12V LiFePO4.
As the VCC Pin of the JK BMS GPS-Port carries VBat it could be that my converter was made for 12s or 16s batteries and that the voltage was to low to drive the RS485 circuit. I think there is a step-down converter inside of the adapter, that creates the proper voltage for the logic ICs. At least I have read, that there are maybe two versions of the adapter for different voltage levels.
What I also tried was building a line Isolator with an ADUM1301.
I wanted to connect the TTL-Ports of the JK directly to a serial Interface of the OpenDTU Fusion Board. (GPIO 43 and 44)
I saw that there was the option to connect the JK BMS via serial (not RS485) in the web interface.
But that also did not work.
Maybe I should have tried without the line isolator.

Concerning the CAN Bus thing, I am quite happy with the solution now.
I have copied the pylontech driver to a new jk can driver this evening in my dev tree, so that I can fiddle around with it a little bit.
Maybe I get even more Information out of the BMS, or what I find more challenging get it displayed on the website of OpenDTU

[Manos1966]

Wow!

I jump to another thing, which is more important... 12V battery?
I hope you are aware OpenDTU-onBatery controls Hoymiles Inverters and these work well with 48-51V Batteries, poorly with 24V batteries but definitively do not work with 12V!

[Manos1966]

Ah OK
You are testing the concept also.

DC to DC converter to get the voltage above 24V (I think this is the start of the HM), with 16V been where it stops) will be challenging.

I do have a question about the JK BMD now... I THOUGHT the JK BMS used by OpenDTU-onBatery is for 15S or 16S Batteries. Are you sure that your JK BMS is working with a 12V battery and it is one of the models compatible with OpenDTU-onBatery?

[mrwillem]

Yes i am kind of testing but it could be a longer test :D
I have the Battery from my Caravan, which is unused when I am not in holiday.
And I also have a "Balkonkraftwerk" (german word). A small PV Powerplant which is limited to 800 Watt. I noticed, that I produce about 2-3kWh power on a sunny day which I don't use. And in the night I consume about 2 kWh from the electricity provider. So I thought if I could store the power from the day and use it at night it would be great.
This is also the size of my batterie (305Ah * 12V ~ 3,6 kWh). Using the DC DC is probably a little inefficient. But i hope it works.
I bought a 2000 W DC DC converter from Ali Express. But for me it would be sufficient to limit the power to 200 - 300 Watt. The converter goes up to 80 V.

Regarding the BMS.
There are some which support 4S or 8S. I bought a B2A8S20P-HC which is for a maximum of 8 Cells. But it also works with 4 cells.
It should have CAN, RS485 and a heater function.
The Protocol on the RS485 and CAN bus should be the same. At least for CAN I can confirm this now :D

[Manos1966]

Hmmm... from the OpenDTU-OnBattery Documentation:

[mrwillem]

Thats something I also read, but...

• There are several people who have both, CAN and RS485 support
• I bought the BMS with CAN and RS485 support from the manufacturer.
• I can select the RS485 Protocol type in the settings of the BMS.
• There is RS485 printed above the GPS Port while CAN is on a different hardware Port.

I will never know if it really has RS485 support - at least until I can analyze the communication on the port with an analyzer or something.

[schlimmchen]

@Manos1966 Be careful not to mix up the JK-B* series with the JK-PB* series. The latter always has RS485 and CAN available on the respective I/O shield.

[mrwillem]

I have pushed the source to an own development tree
https://github.com/mrwillem/OpenDTU-OnBattery
It is far from perfect now. Just a quick hack.
Most values are not implemented and there is much leftover code from the Pylontech driver.
If anyone would like to try it out, the CAN rate can be specified using the key word can_type in the settings.json.
with the CAN/Iso shield from opendtu fusion, the configuration would be
"battery": {
"rx": 13,
"tx": 14,
"can_type": 2
},

If can_type is not specified, the default rate of 500 kBits should be used. So this should be compatible with existing installations.

[schlimmchen]

Would you mind explaining why this is useful? I don't understand, yet. Isn't it far easier to setup the JK BMS using the Bluetooth App to talk a compatible protocol (Pytes or Pylontech) on the CAN bus, then setup OpenDTU-OnBattery as if it were talking to a Pylontech or Pytes? Does the JK protocol carry more information?

[mrwillem]

@schlimmchen At least it is useful for me.
This was the only way I could got my BMS connected up to now.
I cannot select any of the other Protocols which are already supported.
Maybe that works on the newer JK BMS.
At least the options are available in the app, but are greyed out for me.
I just wanted to share what I've done. Maybe it will help others, which have similar problems.

[schlimmchen]

You sound very defensive. Sorry if I came at you the wrong way. I am really just curious. I am even happy to integrate your changes into OpenDTU-OnBattery. I wanted to understand better what the benefits are.

The fact that all the other protocols are greyed out is very confusing... It suggests that the protocol is supported in general, but the selection is limited because of another setting.

Would you mind sharing the exact model number of JK BMS you have? It is a JK PB-* series "Inverter-BMS", isn't it? The picture in the docs looks like yours? I have such a unit and would be happy to evaluate your code -- some time in the next weeks.

And you do realize that integration using RS485 of JK-PB* definitly does work? Would you like to revisit this option?

[mrwillem]

Hey @schlimmchen Thanks. I really thought I have to defend this approach a little. But not because you came the wrong way. I understand that you must be very curious, because the connection by RS485 is well supported and documented and it is quite strange that it did not work for me. It really drove me nuts that it did not communicate.
In the end I think It could have been, that I used the wrong RS485 converter or that mine was faulty. I also read, that there are different types of the JK RS485 converters or that they sometimes break after a certain time. Allthough mine was brand new.
I opened the converter and looked at the circuit.
If I get it right, there is a power converter inside which creates Vcc for the circuit from the battery voltage. But i could not measure any voltage at the output while the battery voltage was there.
So what I could try is to use direct serial communication.

But, to be honest, I somewhat favour the CAN Connection over RS485 for it's simplicity and less converters in between.

The exact model of this BMS is B2A8S20P-HC . So it is one of the B-* series and not one of the newer Inverter BMS. It was bought around April 2024 with the CAN and Heater Option. According to the seller it should supports also RS485.
And I have the options to select a RS485 Protocol type in the bluetooth app.
The BMS is a silver unit which looks like the right BMS in the picture here https://opendtu-onbattery.net/hardware/jkbms/models_b/ .

At least it supports the newer v2.1 CAN Protocol with the extended identifiers according to the document I stated above.
I am also curious why the other options are there, but greyed out. I thought it could be because they are implemented only for the newer inverter BMSs for some reasons but they used the same codebase to build the firmware for this BMS.
It has a hardware version of V11.XA and a Software of V11.45

Regarding evaluation of the code, It is not really at a production level now. But I hope to find some time to complete it in the upcoming weeks.

[knopers1]

sehr gut, ich bauen zur Zeit ein Lifepo4 Akkupack mit einem JK-BD6A20S10P und könnte Euch beim Testen unterstützen. Die CAN Anbindung für den JK wäre echt geil....

[mrwillem]

@knopers1 Klar gerne :D Du könntest aber auch schauen ob bei deinem BMS das funktioniert, was @schlimmchen oben vorgeschlagen hat.
Also wenn du z.B. das Pylontech Protokoll per Bluetooth auswählen kannst ist es wahrscheinlich einfacher, weil der Treiber ja schon fertig geschrieben ist.

[schlimmchen]

Bitte erstellt ein Issue (Feature Request), um das zu tracken, sonst wird das nichts. Ich kann mir vorstellen, das zu übernehmen, aber die Motivation ist so mittel und die Zeit ist nicht wirklich da. Vielleicht Ende August...

[mrwillem]

Alles klar. Mache ich in den kommenden Tagen. Ich habe sogar schon einen großteil geschrieben. Mir fehlt noch die Fehlerauswertung. Da wollte ich mich vielleicht am Sonntag dran setzen.
Zudem habe ich noch nicht ganz verstanden wie ich alle Werte die ich auslese per MQTT anzeigen kann.
Irgendwo fehlt mir da noch ein Schritt.
Ich dachte ich erstelle den Feature request wenn ich einen funktionalen Treiber habe.

[knopers1]

Servus,

ich hätte eine Grundsatzfrage zu dem JK-BMS. Falls ein Alarm zB. wegen Überstrom beim Laden/Entladen kommen sollte, schaltet der JK-BMS den Akku ab.
Kann mir jemand sagen, ob die Spannung erneut zugeschaltet wird, sobald die Überlast erneut wieder weg ist? Dies wäre fatall, da ich beim Zusachalten erst über den Widerstand den Hoymiles vorladen muss. Lässt sich das Wiedereinschalten eventuell irgendwo unterdrücken? Kann da jemand Helfen? LG Lukas

[DonJohnLong]

Du kannst den jeweiligen Relase wert einfach sehr hoch setzen, so dass er nicht so schnell wieder erreicht wird. Z.B den OverDischargeRelease auf den höchstmöglichen Wert setzen. Dann hast du zumindest mehr Zeit, dass Problem händisch zu lösen. Die jeweiligen Limitationen davon, hab ich leider jetzt auch nicht im Kopf.

[knopers1]

da kann man eine drei stellige Zahl i sek. eingeben! Demnach max 999sek/60=16 min :) Nun ja, anscheinend geht es halt nicht. Es ist echt nicht beruhigend! Beim Kurzschluß schaltet das Teil ab, und ballert alle 60sek die Spannung drauf, um wieder AUS und AN zu gehen... Wer denkt sich den so etwas aus?

[mrwillem]

Ja wenn du einen wirklichen Kurzschluss hast, sollte da echt eine andere Sicherung greifen.
Das ist nicht Aufgabe des BMS.
Du musst bedenken, das BMS schützt eigentlich den Akku und nicht die andere Elektronik.
Da musst du dich selber um den Schutz kümmern.

[knopers1]

da bin ich nicht gazn einverstanden damit! Ein Kurzschluss (wo auch immer) schließt ebenfalls die Zellen alle 60 sek. kurz. Demnach sollte das BMS die Zellen schützen, und nicht ständig "kurzschließen" Aber egal.... Ich finde es halt falsch, dies ändert aber nichts an der Tatsache, dass es so ist...

[mrwillem]

Für den Fall gibt es eigentlich Schmelzsicherungen.
Das Problem was man bei diesem "speziellen" Kurzschluss hat, den du abfangen möchtest ist, dass er technisch so nicht vorgesehen ist. Du brauchst dafür eigentlich eine spezielle Schutzschaltung.
Du könntest eine Art Selbsthalteschaltung nutzen oder
z.B. einen Hot-Plug controller wie den LT4363 o.ä