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

[chaosnature]

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 .

@silverstone
I am perfectly okay.k I don't need to learn anything.

.....anyways - thanks for voicing my same opinion on the UKSA007 solution....at least we had one thing in common.

I did voice my appreciation multiple times for the great effort on the project - even with my annoyance right now that has not changed.....you guys are doing a great job...and you will be rewarded accordingly by the universe. i dont want to leave letting you think i have no appreciation - that would be obserde using your solution and not appreciating - I am not that kind of person nerver will be)...when i do my youtube videos gratitude will still be shown to all that was involved.

I saw you guys as friends however disappointed at how I was constantly being ganged on - but I will get over it... good luck with your future endeavors...!

Ps:
as for the other babies talking...i have no words for you...if i do , i did hook you up privately...they are right i am not gonna messup the thread dedicated for a serious project.

 

[paulsteigel]

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.

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

 

[silverstone]

Slighly unrelated, but for the M5 Stack Atom S3 lite (or any other similar device for that matter), do you know of a DIN-rail mount kit ?

For instance M5Stack sells this but it's for a switch https://eu.mouser.com/ProductDetail/M5Stack/K042?qs=81r%2BiQLm7BSkMqCoAPdArw== (and it's relatively pricey)



And the prototype module they sell is like 50mm x 50mm:

Base15 Proto Industrial Board Module v1.1

Base15 V1.1 is a "5x5cm system" universal functional base, the thickness of the product is 15mm (excluding the busbar pin header). A variety of fixing methods are reserved in the structure, supporting DIN rail, wall mounting, screw fixing, and bottom M12 connector fixing. This product is mainly...

shop.m5stack.com

If should be possible to have something (like above) that is only 18mm or 36mm wide I guess ...

Just dump it in whatever 18mm plastic DIN rail enclosure I can get my hands on and hardwire internally CAN and USB connections ?

 

[MrPablo]

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

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?

 

[chaosnature]

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

I too have a similar challenge - I just wish a 100% could be sent to the inverter (as battery full) based on the top SoC set on the BMS and not on the ah remaining capacity - but again my knowledge of the logic coding is very minimal so I might be talking garbage (in which case just simply ignore).

When it gets near the top I have to intervene and mess with the ah myself to adjust the %tage. it can say its a 100% full (when it has not reached its set SoC) but then when I toggle the ah value up; say from 95 to 96 ah and then back to 95 it will set its percentage back to a lower value and continue to charge. (been on this for days trying different Ah set different from the manufacturer-specified battery capacity, same result)

# Edit
Or combine both in the logic - to say if Max ah reached and yet max set SoC not reached do something....

 

[silverstone]

I'd like to have another "kind" of feature request.

The current setup is quite difficult to maintain for both users (at each update we need to manually modify everything) as well as developers (you have 4x YAML files).

I shared my "build" scripts including using secrets (or `replace_text` function) to dynamically set parameters.

Then it would be as easy as defining a defaults.sh file as well as a user.sh file to override those defaults.
Developers ONLY touch defaults.sh, Users ONLY touch user.sh.

How does the idea sound ?

GitHub - luckylinux/jk-bms-build-helpers: JK BMS Build Helpers

JK BMS Build Helpers. Contribute to luckylinux/jk-bms-build-helpers development by creating an account on GitHub.

github.com

Please have a look inside the esphome-jk-bms-can folder for @MrPablo / @Sleeper85 code.

If possible I'd like to get this merged with you, as I feel it could be interesting for many people.
Separate "format", "code" and "values" basically.

One easy way would be in build_*.sh declare an associative array:
declare -A parameters

Then in defaults.sh you populate it
parameters["charge_a"]="100"
parameters["float_v"]="53.6"

And if the user wants to override these, he can modify user.sh:
parameters["charge_a"]=80

Then in build_*.sh I could just do
for i in "${!parameters[@]}"
do
key=$i
value=${array[$i]}
replace_text "./$esphomeconfig" "$key" "$value"
done


Note: I don't have defaults.sh and user.sh, as I'd like to work on this together with you, not only doing my spinoff.
The spinoff is only interesting for configuring multiple JK BMS (different name, MAC, ...). It doesn't help when you release a new version, I'd still need to go through the same work all over again (even though maybe only 1 or 2 values need to be changed by me).

 

[MrPablo]

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?

 

[silverstone]

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?

It's also just much easier for me to remember what I had to do after 6 months went by .

100 roads bring to Rome.

Maybe you can do something similar in YAML using a YAML for Defaults and a User-level YAML file that overrides this ? Not sure.

We can probably do the same and much more in Python, but I think it's overkill. For simple stuff, I prefer BASH .

 

[Quattrohead]

When you include JBD code I will be able to help you with some of the fundamentals for programming stupid people like myself. I have the hardest time following software things but eventually get it figured out usually after much frustration. I might be a great guinea pig for testing some of this stuff. Hardware I can deal with all day long easy peasy.

 

[silverstone]

@MrPablo: regardless of how you adjust the code, I think it's just much easier for the user to have his PIP / Python venv environment set automatically, then download the repository code, set the required parameters, and run.

(Note: It MUST be run as root IIRC - didn't test non-root for now)

EDIT: Of course I am free to discuss if the build path needs to be moved etc.

But for the inexperienced user, those should be done automatically. I had to do my own trial / research / run into 300 errors etc until I get it working. The result is this script collection which helps the user automate some tasks.

 

[Der_Hannes]

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

 

[silverstone]

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

Yes, I don't know what's going on "behind the scenes" so I can only reach out to try to explain what would be good as a user .

It does not need to be using my script, this is my barebones approach to solve problems I can face as a user.

Because imagine I change 30 different parameters and then you release 1.17.5 or something. Then I have to go through all the same exercise again and most likely miss a parameter or two, thus introducing breaking changes which will most likely make both me and you lose time.

I don't know how the packaged version will look like or when it will be released. Just please keep this in mind .

Even if full YAML, YAML+BASH, YAML+Python, I strongly suggest you set a default configuration, then the user overrides *only* what is needed.

Of course this also assumes that the default configuration is "sane" for the chemistry in question, i.e. don't set crazy defaults (the ones I could see are quite conservative so I'm not too worried there).

 

[silverstone]

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.

 

[paulsteigel]

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?

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


But when turn it on, discharge is no more


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

 

[silverstone]

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

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 ?

 

[Der_Hannes]

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.

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

 

[silverstone]

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

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 ?

 

[Der_Hannes]

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 ?

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

 

[silverstone]

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

Alright, that sounds simple enough .

I didn't have that option with syssi code. So you might argue that my BASH tool might not be needed in the future. But for now it still has its job (until the next major release I assume) .

 

[MrPablo]

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 ?

@silverstone, I'll be enhancing documentation this week and will have much more detail & examples.

As for your final point, requested voltage will go back up as cell imbalance reduces. This auto voltage is only active during bulk and balancing stages.