JK BMS CAN bus comms now possible for inverters that support Goodwe and Pylontech batteries

[eumobong]

I am waiting for my devkit and TJA1050 to arrive to use this your wonderful app. Thanks once again for making this open source.

Please just one observation: the external component is set to refresh every now and then as against recommended minimum of a minute. What does this entail? Won't it be drain on the resources if it keeps checking like this? What is the implication if one sets it to NEVER?

It appears you are working on Bluetooth support as well.

Thanks

 

[uksa007]

Please just one observation: the external component is set to refresh every now and then as against recommended minimum of a minute. What does this entail? Won't it be drain on the resources if it keeps checking like this? What is the implication if one sets it to NEVER?

It appears you are working on Bluetooth support as well.

The external components are downloaded when flashing. I haven’t seen any issues with it checking every time.

No, not working on Bluetooth support, the original code I use to read the BMS does, but I don’t recommend it or support it, as the inverter needs a CAN packet every second, Bluetooth is not reliable enough.

 

[uksa007]

Sneak peak of what i have been working on:
Complete rework of the charging logic, now charges with constant current(CC) to the absorption voltage, then has an absorption timer (Constant Voltage, user configurable time), with rebulk feature (user configurable offset from absorption voltage).
Live sliders for absorption voltage and charging current (can change on the fly!)
Charging status user feedback to let you know what the charging logic is doing. Bulk, Absorption, Complete, Wait , Disabled, etc
Reworked the Charge/Discharge controls and logic, so more user friendly (default to on as below).

 

[eumobong]

Sneak peak of what i have been working on:
Complete rework of the charging logic, now charges with constant current(CC) to the absorption voltage, then has an absorption timer (Constant Voltage, user configurable time), with rebulk feature (user configurable offset from absorption voltage).
Live sliders for absorption voltage and charging current (can change on the fly!)
Charging status user feedback to let you know what the charging logic is doing. Bulk, Absorption, Complete, Wait , Disabled, etc
Reworked the Charge/Discharge controls and logic, so more user friendly (default to on as below).

View attachment 120009

If 90% SoC is reached and the absorption time has not been exhausted, will it exit absorbtion or it will continue till the end of the set time?

 

[uksa007]

If 90% SoC is reached and the absorption time has not been exhausted, will it exit absorbtion or it will continue till the end of the set time?

It would be when it hits the rebulk voltage(not 90%), it will stop absorption and start bulk followed by absorption.

 

[robot_zombie]

this is great, thanks for the work uksa007!
I have been thinking about the possibility to expand so 2 JK bms packs in parallel could work together, processing values sent to the inverter something like so ;

• Battery Voltage = average
• Battery Current (+charge, -discharge) = sum
• State of Charge (SOC) = average
• State of health (SOH) = average/not super important
• BMS Temperature = average or highest
• Charging Voltage = average
• Charging Amps = sum
• Discharge min Voltage
• Battery name
• Alarms: Cell over/under voltage, Charge/discharge over current, High/low Temp, BMS fault = pass through from either bms
• Charging logic: Chargers to user defined max SOC(90%), turns off charge, will restart charging if SOC drops below user defined rebulk SOC(80%).

I had a look and the ESP32 actually has 3 UARTs, but UART0 is used for firmware flashing etc and it seems from a quick google that people generally have difficulty using it, would it be possible to add an rs485 to i2c converter to enable comms to the second BMS?
thoughts?
cheers

 

[uksa007]

I have been thinking about the possibility to expand so 2 JK bms packs in parallel could work together

I have briefly thought about it, there are few hurdles that may prevent it from being simple, like the code that reads the JK-BMS values may not easily support multiple BMS, both hardware serial ports are already used on ESP32 etc.

At the moment I'm focused on improving the charging logic and overall user experience, ensure everything works as it should.

My thoughts at the moment are if you need more capacity just add more of the same cells in parallel then you don't need another BMS.
EG 2P16S, 3P16S etc.

 

[Quattrohead]

both hardware serial ports are already used on ESP32 etc.

Multiplex

 

[uksa007]

Multiplex

There are lots of options to resolve, probably the easiest would be to use software serial, the real problem is current codes does not support reading multiple BMS, it would take lots of development, including buying another BMS and set of batteries, so I can test and develop costing a few thousand dollars. Not something that I plan on doing any time soon.

To be honest it would just add complexity, when adding the new cells in parallel and using one BMS would achieve the same outcome.

 

[sergea]

this is great, thanks for the work uksa007!
I have been thinking about the possibility to expand so 2 JK bms packs in parallel could work together, processing values sent to the inverter something like so ;

• Battery Voltage = average
• Battery Current (+charge, -discharge) = sum
• State of Charge (SOC) = average
• State of health (SOH) = average/not super important
• BMS Temperature = average or highest
• Charging Voltage = average
• Charging Amps = sum
• Discharge min Voltage
• Battery name
• Alarms: Cell over/under voltage, Charge/discharge over current, High/low Temp, BMS fault = pass through from either bms
• Charging logic: Chargers to user defined max SOC(90%), turns off charge, will restart charging if SOC drops below user defined rebulk SOC(80%).

I had a look and the ESP32 actually has 3 UARTs, but UART0 is used for firmware flashing etc and it seems from a quick google that people generally have difficulty using it, would it be possible to add an rs485 to i2c converter to enable comms to the second BMS?
thoughts?
cheers

Read my previous post

 

[uksa007]

Read my previous post

Connecting multiple BMS is the easy part, the software to read multiple BMS and merge them together is not so easy.

 

[robot_zombie]

I have briefly thought about it, there are few hurdles that may prevent it from being simple, like the code that reads the JK-BMS values may not easily support multiple BMS, both hardware serial ports are already used on ESP32 etc.

At the moment I'm focused on improving the charging logic and overall user experience, ensure everything works as it should.

My thoughts at the moment are if you need more capacity just add more of the same cells in parallel then you don't need another BMS.
EG 2P16S, 3P16S etc.

thanks, don't get me wrong, not hassling you or anything, appreciate the work. Your charging logic should be awesome once its working and provide everything I wish the goodwe had in its self define profile haha. My packs are different Ah so not so easy to wire up!
I did notice the original github has an example of reading two BMS's using the one ESP. If you ever want someone to test, I have two JK B2A24S15P running and a goodwe inverter.

 

[rhino]

Seems at least some of the server rack batteries are handling this by having a "master" controller which takes the values from all the other BMS's and processes all of them to then have single CANbus command sent to the rest of your system. I think least complicated way to do this hardware-wise would be to have a separate esp32 for each BMS.

 

[eumobong]

Seems at least some of the server rack batteries are handling this by having a "master" controller which takes the values from all the other BMS's and processes all of them to then have single CANbus command sent to the rest of your system. I think least complicated way to do this hardware-wise would be to have a separate esp32 for each BMS.

My proposition : Since hardware uarts is not sufficient to take care of multiple inputs for esp32, I think this flow can work.
1) separate esp32 for th rest of the battery bank(s) ouputing theirs values through mqtt.
2) a master esp32 then subscribes to those topics and aggregates the values and communicate it with the inverter though CANbus.

But the issues is how to handle the following scenarios:
When bank 1 triggers a cell overvoltage, do you disable charging for all the banks or just that bank? The former means inverter disable charging while the later means the specific BMS disable charging.

 

[uksa007]

But the issues is how to handle the following scenarios:
When bank 1 triggers a cell overvoltage, do you disable charging for all the banks or just that bank? The former means inverter disable charging while the later means the specific BMS disable charging

All the alarms present similar issues:

To be responsible you should do the following if an alarm goes off, which negates most of the benefit of having a seperate pack and BMS:

Under voltage (stop discharging all packs, not a good outcome)
Over voltage (stop charging all packs)
Over charge current (stop charging all packs)
Over discharge current (stop discharging all packs, not a good outcome)
Over temp (stop charge/discharging all packs, not a good outcome)
Under temp (stop charge/discharging all packs, not a good outcome)
BMS fault (stop charge/discharging all packs, not a good outcome)


This and many other issues and complexities are why it's not something that i'm planning on implementing any time soon.
If I get enough support and donations to fund buying more batteries and BMS to develop this feature I may consider it.
In the meantime I suggest that if you need more capacity add the cells in parallel and let one BMS manage the pack, it avoids this and many other issues.

 

[eumobong]

This and many other issues and complexities are why it's not something that i'm not planning on implementing any time soon.
If I get enough support and donations to fund buying more batteries and BMS to develop this feature I may consider it.
In the meantime I suggest that if you need more capacity add the cells in parallel and let one BMS manage the pack, it avoids this and many other issues.

You've done well and you've spoken well too. I appreciate your effort especially in making this open source.

 

[Pete@SolarBatteryBarn]

Yes but strange that Victron and many other vendors have a specific LiFePO4 charging profile but have chosen to have both Absorption and float.

Default profile for Victron LiFePO4:
Absorption voltage: 56.80V
Absorption time: 2h
Float voltage: 54.00V
Re-bulk voltage offset: 0.4V drop below float (53.6v default setting)

My PV will charge at maybe 7kW or so while using 5kW on loads.
When aborption is done and charging stops, my battery will be drained significantly while the sun is still shining if I don't use float.
It seems like I need to float my LiFePO4 if I want to start the night above 80% SOC.
How do other people with high consumption do it?

 

[rhino]

Under voltage (stop discharging all packs, not a good outcome)
Over voltage (stop charging all packs)
Over charge current (stop charging all packs)
Over discharge current (stop discharging all packs, not a good outcome)
Over temp (stop charge/discharging all packs, not a good outcome)
Under temp (stop charge/discharging all packs, not a good outcome)
BMS fault (stop charge/discharging all packs, not a good outcome)

Not sure I follow since you can have one battery with its own BMS have one of these faults and has nothing to do with any of the other batteries. Why should you be completely without power if that is the case? I don't see why having essentially "backups" would be considered a bad thing and hence the reason why having multiple batteries in parallel each with its own BMS would be advantageous.

 

[uksa007]

How do other people with high consumption do it?

Use an inverter charger all in one device.
In my case my inverter will power loads directly from the solar, it only uses the battery when the load is greater than the solar production.

 

[uksa007]

Not sure I follow since you can have one battery with its own BMS have one of these faults and has nothing to do with any of the other batteries. Why should you be completely without power if that is the case? I don't see why having essentially "backups" would be considered a bad thing and hence the reason why having multiple batteries in parallel each with its own BMS would be advantageous.

The issues arises where two batteries/BMS are connected to one inverter/charger.
The inverter/charger can only be ON or OFF with regards to charging and discharge of the battery. (yes there is current limits, but it doesn't help here)
If one battery pack(cells) is under voltage and the inverter continues to discharge the under voltage BMS will have to disconnect which is not ideal, as the BMS will normally turn discharge on and off as the batteries recover, you risk over discharging them and/or causing damage to BMS.
BMS disconnection should be the last resort when all else has failed. The whole point of the BMS communication with the inverter, is so the inverter knows what the battery is doing so it doesn't cause the BMS to have to disconnect.

With two packs and two BMS you have to listen to weakest pack and act accordingly.