JK-BMS-CAN with new Cut-Off Charging Logic (open-source)

silverstone said:

Well ... I also originally had a look at UKSA007 solution.

"It's expensive, can you just share the code &schematic and let DIYers do it themselves?" -> NO
"I'd like to have a Digital Output to trigger a forced disconnection / reconnection using a contactor. Can you implement that ?" -> NO

So there you have it ... That's why I like this project. I also need to do my work, but then I can customize it to fit my needs. And I really like that everybody is happy to help each other out.

And yes, I'm an ESPHome Noob. I just recently started tinkering with MQTT. A bit earlier with Podman/Docker. Everybody has to learn, and I cannot learn 300 things at once. Heck technologies change faster than you implement them, it's crazy.

So it will take time, but I hope I can also contribute to this project .

Click to expand...

paulsteigel said:

Hi All,
It's great to have the new code with many functionalities. However, when I flash the new firmware, the inverter stop charging and discharging by reducing the current limit to 0. Actually, I forked Sleeper's version a month ago and do some modification on the can id 0x355 to help the inverter continuing charging process when JK report wrong soc so we can achieve 3.45 (at max) for LFP. Also, I made new slider to help user to control on UVP (higher than the number defined in the JK) and OVP (lower than the number defined in JK). I found the Jan version of Sleeper is working better with Luxpower and Deye. 2 days ago, I flash the new code and it seem the inverter stop charging/ discharging if we leave the auto voltage and current switch on.
With the details I have observed on using 3 Luxpower and 3 JKBMS + LFP in a year, I found that:
+ JK has it owned problem on SOC calculation and we can solve this by not posting its SOC when it reported 100% but Voltage is less than 3.45 V, similarly applied for 3.2 or 3.0 (depending on user, i myself set 3.2 as the UVP). Inverter like Lux prefer using SOC than Voltage (Voltage only work if choosing battery interface as lead acid);
+ Charging logic is seem to be difficult to handle. Inverter like Deye or Luxpower seem to have better control on charging with full and smoot CCCV when battery is set as Lead Acid (no Can communication). I am not quite good at programing but I do see the logic that @sleeper is using but I have not got a chance to leave both (the new yaml config and the own one) to work, I all have to intervene myself at the final stage to reduce the charging current to avoid Inverter alarm (change status to "notice" which is annoy innocent user a bit) and shut off charging.
My proposal: Treat the Battery similarly to what Inverter is treating as "Lead acid" and solve at 2 points
1. Control on SOC reporting - easy as Sleeper has done already: when JK report wrong SOC, keep it at 98 or 99 - Lux stop charging randomly when SOC is 99% but fully stop at 100%;
2. Refine the Charging/ discharging logic by better control on current so that:
>> At charging:
+ CC: Bulk charge can happen any time as set by Inverter and apply 0.3C-0.5C when cell voltage is below 3.42;
+ CV: start and reducing current gradually so when JK SOC hits 100%, current should be low enough to avoid the 3.45 ceiling
+ Floating: When 3.45 is reached, keep the float voltage until the discharging cycle start.
>> At discharging: Better to set the UVP target voltage in software so we can tell the inverter to reducing discharging current limit to lower or even 0 when user defined UVP is reached (minimum cell voltage is lower than the defined UVP value on home assistant)

As I observed my revision on the can_id 0x355: I was not able to revise Sleeper code on the part relating to can_id 0x351 so I decicided to revise the 0x355 part with following checkpoint:
1. Jksoc is alway 98 or 99% when voltage is not yet reaching the OVP level defined by user: so the inverter will continue to charge, of course, i will have to intervene manually here at the final stage to reduce charging current when cell voltage is 3.42. This will automatically help JK to reset its wrong SOC;
2. When Jk report SOC 0% or below the Stop discharging SOC (set in inverter - i.e 25%), but minimum cell voltage is still greater than 3.2 or UVP level set by user, report to inverter the SOC of 26% and start reducing discharging limit, With this we can help JK to discharge to the expected safe level without alarming the inverter.
I will try reading a bit more on how to work with Script to revise Sleeper code to make the charging can be as smoot as expected. Also, some more feature like discharging/charging current by time can be included.
View attachment 203891
My English is not so good but I would like to share my view with you guy for moving forward a better and smarter JKBMS things.
Best
Ngoc

Click to expand...

paulsteigel said:

Hi All,
It's great to have the new code with many functionalities. However, when I flash the new firmware, the inverter stop charging and discharging by reducing the current limit to 0. Actually, I forked Sleeper's version a month ago and do some modification on the can id 0x355 to help the inverter continuing charging process when JK report wrong soc so we can achieve 3.45 (at max) for LFP. Also, I made new slider to help user to control on UVP (higher than the number defined in the JK) and OVP (lower than the number defined in JK). I found the Jan version of Sleeper is working better with Luxpower and Deye. 2 days ago, I flash the new code and it seem the inverter stop charging/ discharging if we leave the auto voltage and current switch on.
With the details I have observed on using 3 Luxpower and 3 JKBMS + LFP in a year, I found that:
+ JK has it owned problem on SOC calculation and we can solve this by not posting its SOC when it reported 100% but Voltage is less than 3.45 V, similarly applied for 3.2 or 3.0 (depending on user, i myself set 3.2 as the UVP). Inverter like Lux prefer using SOC than Voltage (Voltage only work if choosing battery interface as lead acid);
+ Charging logic is seem to be difficult to handle. Inverter like Deye or Luxpower seem to have better control on charging with full and smoot CCCV when battery is set as Lead Acid (no Can communication). I am not quite good at programing but I do see the logic that @sleeper is using but I have not got a chance to leave both (the new yaml config and the own one) to work, I all have to intervene myself at the final stage to reduce the charging current to avoid Inverter alarm (change status to "notice" which is annoy innocent user a bit) and shut off charging.
My proposal: Treat the Battery similarly to what Inverter is treating as "Lead acid" and solve at 2 points
1. Control on SOC reporting - easy as Sleeper has done already: when JK report wrong SOC, keep it at 98 or 99 - Lux stop charging randomly when SOC is 99% but fully stop at 100%;
2. Refine the Charging/ discharging logic by better control on current so that:
>> At charging:
+ CC: Bulk charge can happen any time as set by Inverter and apply 0.3C-0.5C when cell voltage is below 3.42;
+ CV: start and reducing current gradually so when JK SOC hits 100%, current should be low enough to avoid the 3.45 ceiling
+ Floating: When 3.45 is reached, keep the float voltage until the discharging cycle start.
>> At discharging: Better to set the UVP target voltage in software so we can tell the inverter to reducing discharging current limit to lower or even 0 when user defined UVP is reached (minimum cell voltage is lower than the defined UVP value on home assistant)

As I observed my revision on the can_id 0x355: I was not able to revise Sleeper code on the part relating to can_id 0x351 so I decicided to revise the 0x355 part with following checkpoint:
1. Jksoc is alway 98 or 99% when voltage is not yet reaching the OVP level defined by user: so the inverter will continue to charge, of course, i will have to intervene manually here at the final stage to reduce charging current when cell voltage is 3.42. This will automatically help JK to reset its wrong SOC;
2. When Jk report SOC 0% or below the Stop discharging SOC (set in inverter - i.e 25%), but minimum cell voltage is still greater than 3.2 or UVP level set by user, report to inverter the SOC of 26% and start reducing discharging limit, With this we can help JK to discharge to the expected safe level without alarming the inverter.
I will try reading a bit more on how to work with Script to revise Sleeper code to make the charging can be as smoot as expected. Also, some more feature like discharging/charging current by time can be included.
View attachment 203891
My English is not so good but I would like to share my view with you guy for moving forward a better and smarter JKBMS things.
Best
Ngoc

Click to expand...

MrPablo said:

Interesting approach @silverstone, we're working on a packaged version where core logic is stored in different YAML files, with a device specific YAML referenced as needed.
I wonder if your script approach would be needed, or if it would be adjusted.

Perhaps one for @Sleeper85 to comment on?

Click to expand...

Der_Hannes said:

The goal of the packaged version we are currently working on is:
To have one relative simple yaml config file with mostly multiple-choice configurations (which ESP-board, BMS, BLE/wired) and some other numbers to put in like bulk / float voltage etc.

This main config file does not change until new major features with breaking changes where added (and even then, it should be much easier for users to manage the config file.)

All needed modules would then be loaded from github automatically with the newest branch

This is the easiest way to catch up to new releases - for minor changes, only a new compile and OTA would be needed.

Another benefit would be that the modules could be used in other projects very easy

This should be possible, but of course, it is a long stony road to get there

Click to expand...

MrPablo said:

Hi @paulsteigel, good to see another user!

The latest main release (v1.17.4) has quite a bit of logic in which might already solve some of your issues.

Firstly, dynamic charge and discharge current - this automatically reduces battery current as either:
- Max cell voltage approaches OVPR as set in the BMS
- Min cell voltage approaches UVPR as set in the BMS
This should prevent any over or undervoltage issues as long as your BMS is set appropriately.

Secondly, the code also maintains a max of 99% SOC until the following occurs:
- Battery current drops below the automatically calculated cutoff current
- Max cell voltage >= the automatically calculated cutoff voltage
You can find the logic of how these are calculated on the readme link on GitHub.

You could test if changing 99% to 97% in the code is more effective for your setup.

As for continuing discharge after the BMS reads 0%, this is something I've considered before but it sounds like the core issue is how your BMS is working.
Is the battery capacity definitely accurate?

Click to expand...

paulsteigel said:

Hi @MrPablo ,
I did the test day again with both charge and discharge (LuxPower Inverter) and I had to intervene:
1. To stop the auto feature of current/voltage: as the battery pack is 280Ah and it can not achieve 10-12 Kw charge if I let the feature to do it (it reduce current while SOC is still 40-50%);
2. My charging time start from 7AM to 5PM and during that time if Bat is full, then no more charge should happend.
3. At the discharging time 5PM to 7AM, if the auto discharge current on, it will reduce current to very small or even to 0. normally, I leave the discharge current at night of 10A.
If I leave the auto feature off, it start discharge as expected
View attachment 203991

But when turn it on, discharge is no more
View attachment 203992
View attachment 203993
These are the reason that i think the logic should be considered again! I my self still have the old version with my revision and it still function ok enough for small battery (less than 150Ah) but with big like 280Ah, it did not work quite well!

Best,
Ngoc

Click to expand...

silverstone said:

The other use-case in my case (no pun intended !) at least was to have a device "database" (devices.sh) with settings concerning names, mac address, protocol/driver for syssi layer, etc.

I didn't want to copy-paste each time a new file (nightmare to maintain !) neither manually editing it each time when it could be automated .

If you trust OTA this might not be a big deal once the initial flash is done.

However, if (as I expect .... Murphy's law you know ?) OTA breaks down or something stops working, you will have to reflash everything you have.

Not a huge deal if you only have 1-2 BMS, but once you have maybe 8 or so that will become a hassle.

Click to expand...

Der_Hannes said:

it does not matter if you then upload the new compiled with ota or usb - in case ota does not work, you can do it via usb of course
No changes needed

i think this is much mor comfortable than deading with python etc to create config files - but an interesting approach

Click to expand...

silverstone said:

I'm carefully optimistic without knowing all the details .

BASH and Python might be a hack, but I don't know how your solution will look like.

The reasons I did it this way (originally with syssi code):
- Multiple Parameters
- Multiple BMS
- Remember what I did

EDIT: "No changes needed" ? So how do you build multiple firmwares for different BMS attached to different BLE MAC addresses ?

Click to expand...

Der_Hannes said:

one main config yaml for each esp - there is the mac defined for your bms

or a simple bms_id which then picks the right mac and ble protocol from the substitutions section

Click to expand...

silverstone said:

1. I'd be interested to see what the cell voltages are at such high current (12kW / 54V ~ 220 A). Granted it's highly non-linear, but I think my cells stay around 3.35V with only 40-50 A. Are you sure the "problem" (or "feature") is not the cell voltage being too high due to the high current x small ESR of the cell ? Your plots only show at very low (discharge) load ...

2. OK ...

3. Why do you set a discharge limit to 10A for a 280Ah cell ? It's during the night that you should be using your stored energy IMHO


@MrPablo: is there written somewhere exactly how the voltage derating works, in case:
- Cell goes *above threshold (assume 3.45 V for LFP)
- Cell delta voltage is excessively high

Do you have some kind of proportional, proportional+integral, feed-forward+integral controller (P / PI / FF+I) ?
Or some more "aggressive" algorithm to reduce the charge voltage using e.g. some polynominal expression ?

Vcharge = Vbat - a * sum(max(0 , cell_voltage(i) - 3.45)) - b * sum(max(0 , cell_voltage(i) - 3.45))^2

EDIT: here is the cutout logic, but not the "derating" one -> https://github.com/Sleeper85/esphome-jk-bms-can/blob/main/documents/README/Cut-Off_Charging_Logic.md

Furthermore, is this logic "reversible", i.e. it will basically SLOWLY ramp up the charge voltage, once the balancer has started bringing back to a lower voltage the highest cell ? Or it's set & stop, basically going back to float ?

Click to expand...