diy solar

diy solar

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

arzaman said:
It seems so. This is the level of overvoltage set on JK-BMS protection, overall 3.6 x 16 = 57.6V, which has never been reached on average. It's possible that one cell exceeds the 3.6V limit and triggers the alarm.

If I understand correctly, when the alarm is active, charging is stopped. Then the voltage drops, and the cycle starts again—Bulk -> Absorption -> alarm.
Click to expand...
arzaman said:
What do you suggest to avoid this situation? Lower the bulk voltage level?

View attachment 192189
Click to expand...
Easy, cell balancing.
 
Below are the voltages of my cells during my load test yesterday with the latest version 1.16.4.

These are new EVE LF280K v2 cells (with EVE test report) I balanced them on the first charge and the graph below is the second charge.

In the application I configure the charge at 55.3V so that Deye charges at 55.2V.

1706636347854.png

1706636150786.png


Charge_status.png
 
Last edited:
arzaman said:
If I understand correctly, when the alarm is active, charging is stopped. Then the voltage drops, and the cycle starts again—Bulk -> Absorption -> alarm.

What do you suggest to avoid this situation? Lower the bulk voltage level?
Click to expand...

Yes thats exactly it.

I just think your battery is not balanced, this is work that needs to be done before putting it into production.

But if we want, we could add lines of code in the script. If the overall voltage of the pack is 54.4V (3.4v/cell) and a cell reaches 3.5v or 3.55v then the charging current must be reduced to do a slow charge and allow enough time for balancing.
 
@Sleeper85
Battery at rest without large charge or discharge. What voltage does Deye and BMS display?

There may be a calibration problem.
Click to expand...

Overall Deye voltage and BMS voltage are perfectly aligned and matches the voltage measured with multimeter
I did voltage calibration months ago and than the voltage measurement is stable and OK
@shvm
Exactly, older JK BMS, ≤ HW V 10.XW don't have the SOC calibration option
Click to expand...

my HW version is V10.XV anbd software V10.10
there is no "soc calibration" parameter
I have always the impression that SOC is not aligned to the real value

@shvm
Easy, cell balancing.
Click to expand...

I did this process at the very beginning (agust 23) during the commissioning, I connected in parallel all the 16 cells and than I charge for more than one month with 3.5V 10A power supply..was perfectly balanced !
How can now repeat this process ?? does the JK BMS active balancer do the job ?

Not so clear to me why during bulk charge or during discharge , below 3.4V the cells are perfectly balanced ?
what happened from 15:00 PM to my battery ?

for example now (night) during discharghe phase cell voltage seems all OK

1706643746521.png

the "delta cell voltage" is normally 0.002v except during the period 15:00 to 17:00

1706643954128.png


what happened in that time frame ?? It seems a "spot" situation but don't understand what was the root cause and how to prevent

thanks
Davide
 
@arzaman

This is completely normal. The difference can really be seen above 3.4V or below 3.0V.
Your cells become unbalanced over time, it may only be a few Ah but enough to have a problem.

I have soon finished a new BLE script with a balancing function for you. :cool:
 
@arzaman

This code is removed because it does not work well. Wait for version 1.16.5 which is currently being tested.
 
Last edited:
arzaman said:
How can now repeat this process ?? does the JK BMS active balancer do the job ?
Click to expand...

Yes no problem, when I build a new battery I place the cells directly in the box and balance with the JK-BMS 2A.

At the beginning I lower the Start Balance V. to 3.4V so that balancing starts sooner.

I understand where your problem comes from, you set your Start Balance V. to 3.0V o_O, that's where all your problems come from.
You have broken your balance.

With a well-balanced battery, in production, the Start Balance V. should be at 3.45V if you charge at 55.2V.

Edit: I think it will be necessary to add a section in the README on how to configure JK-BMS 😅
 
Last edited:
arzaman said:
I have created on HA a simple "status" widget to monitor the adapter communication either CAN and BT

View attachment 192157

BT as reported (on Atom S3) seems quite stable
CAN has periodic disconnection/reconnection every 2h (quite regular)
Is this normal ?

Davide
Click to expand...

Concerning the CANBUS Status I notice the same thing at home, I think it is not very important.

1706651426996.png
 
Sleeper85 said:
I understand where your problem comes from, you set your Start Balance V. to 3.0V o_O, that's where all your problems come from.
You have broken your balance.

With a well-balanced battery, in production, the Start Balance V. should be at 3.45V if you charge at 55.2V.

Edit: I think it will be necessary to add a section in the README on how to configure JK-BMS 😅
Click to expand...
Now I see !!! 🫣
what a mess...😧
I copy paste the settings from Andy (off grid garage) and I'm quite sure the start balance was 3.45v...than I did so many manipulation, tests, new setup, integration with HA that somehow I change that value

please help me to re-balance my loved battery bank 🙏

PS working for testing the BLE version on ESP 32 pico (Atom Lite)
 
Sleeper85 said:
This is an experimental script with a blanching procedure.

line 972, if OVP => balancing = true
line 911, if balancing == true => charge with 55.2V and 5A max
line 937, if End Of Charge => balancing = false

The YAML was compiled for me but not tested.
Click to expand...
Super appreciated (y)
I will install it tomorrow after completing the test session on BLE stability on ESP32 Pico Atom Lite. I don't want to mix up so many tests and configurations.

So, just set again on the BMS, start the balance at 3.45V, and then enable the balancing function. How long does this process take via BMS (balance current 1A)
 
@shvm I have a EG4 6000xp Lux Power coming in Thursday. Can I assume it would use the same protocol and battery settings as yours? I’m using the atom lite platform wired since it’s more stable. Just need to make a cable for Can H/L for it.
 
arzaman said:
Super appreciated (y)
I will install it tomorrow after completing the test session on BLE stability on ESP32 Pico Atom Lite. I don't want to mix up so many tests and configurations.

So, just set again on the BMS, start the balance at 3.45V, and then enable the balancing function. How long does this process take via BMS (balance current 1A)
Click to expand...

As much time as necessary, I don't know, it depends on the imbalance created.

Edit: but don't worry it might just be one day. Configure your Deye to charge from the GRID and let the cells balance until you see the Charge Status “EOC” in HA. Maybe deactivate the float switch before starting the charge.
 
Last edited:
ChrisG said:
I have a EG4 6000xp Lux Power coming in Thursday. Can I assume it would use the same protocol and battery settings as yours?
Click to expand...
Yep, I don't see a reason why it wouldn't.
Let me know when the unit arrives and you need help with the settings.
ChrisG said:
Just need to make a cable for Can H/L for it.
Click to expand...
Yep, I did the same. You only need one pair like a telephone cable instead of the usual four pair in a CAT5E/6. Better make it already.
IMG_20240122_142035525_AE.jpg
 
Sleeper85 said:
Thank you very much for all these schemas, I will add them to the GitHub.

Could the Bluetooth version work with Atom Lite?
Or is it only for Atom S3?
Click to expand...

I try to close this point, at least "empirically"
I compile the BT version on Atom Lite (ESP32 Pico) and

Using Arduino framework
compilation OK but "unstable" BLE connection

1706717875977.png

Using ESP-IDF framework option (various versions)
errors during compilation

@Sleeper85 maybe can investigate erros but the simple raccomadation is "Atom S3 Lite" quite stable and more powerful (same price)

br
Davide
 
Here's what's on my todo list :
  • Improve the alarm system to react before the BMS - first test with version 1.16.5 ( @eumobong )
  • Replace timer absorption with tail current detection ( @shvm )
  • Test Web Server JS ( @shvm )

Regarding the replacement of the absorption timer, I'm not convinced that it could really be better.

If we look at what happens during my last full charging test. When the absorption phase begins at 14:53 (Bat. V. = 55.15V) the current is 2.54A which is already very low. From this point on, if we want to allow time for cell balancing, it is necessary to maintain the voltage at 55.2V.

@shvm If we replace that with tail current detection, at how many amps would you stop charging?

Charge_status.png


29/01 14:45 to 15:30

1706776867904.png

Capture d’écran du 2024-02-01 09-59-47.png

1706777232534.png

29/01 16:00 to 17:00

1706778157947.png

1706777425913.png
 
Sleeper85 said:
@shvm If we replace that with tail current detection, at how many amps would you stop charging?
Click to expand...

It helps to understand the loop carefully.

First we poll the C-rate (current relative to capacity) going into the battery:

If instantaneous charge_rate > [ 0.2 × (V_bulk - 3.375) ], we let bulk reach the user specified voltage value and absorb.
else, charge_rate will be less than or equal to [ 0.2 × (V_bulk - 3.375) ],
then
If at any time, V_batt ≥ N_cells × (3.375 + 5 × charge_rate), we switch to REST/FLOAT.

LFP-charge-model.drawio.png
For charge rates below [ 0.2 × (V_bulk - 3.375) ], cutoff voltage will be lower than specified bulk voltage.

Edit: mistakenly used 0.05 C which corresponds to bulk at 3.625 V/Cell. For lower bulk values, cutoff current will obviously be lower as calculated.
 
Last edited:
@shvm

This is interesting, what is the real gain compared to the timer?

Are you afraid of overcharging the battery?

Did you set it up for yourself?

This would be a big change to the script with lots of testing to validate it.

I think I've already said it, perhaps in private, in 2 weeks I'm going on a big 4-month trip and I won't be able to test anything anymore. This is not a change I will make before I leave. But maybe you can implement it yourself and if it works well I'll test it when I get back?
 
This is interesting, what is the real gain compared to the timer?
Click to expand...
A: it's safer
B: the charging behaviour is more predictable when multiple rebulks are requested on a day with busy loads. The battery will reach absorption far sooner than the timer predicts the second time.

Sleeper85 said:
Are you afraid of overcharging the battery?
Click to expand...
Indeed. If a voltage above ~3.37 V is maintained across LFP Cell terminals with current below extrapolated cutoff, it is technically overcharging.

A battery at 'rest' after a full charge with voltage higher is excluded because voltage is not being explicitly maintained.
Sleeper85 said:
This would be a big change to the script with lots of testing to validate it.
Click to expand...
Pretty much, yes. This happens to be an information complete charging model. There is no ambiguity, every situation regarding power, charging current and voltage is covered.

Sleeper85 said:
But maybe you can implement it yourself and if it works well I'll test it when I get back?
Click to expand...
Agree about this being a strictly beta part.
You have already done most of the work to make things easier.
 
Last edited:
@shvm

I have a lot of things to prepare over the next few weeks before I leave.
Then, at the beginning of March, if you haven't done it yet, I can help you set up what you are proposing but I won't be able to test it.

@eumobong

I have already added an "Alarms Logic" section in version 1.16.5 to address the @arzaman and @hxx balancing problem. I'm going to add temperature control to it. Thus, this section will aim to detect problems before the BMS cut-off which will prevent it from working its MOSFETs to cut a lot of amps.
  • High temperature control (45°C) => stop charging and discharging
  • Low temperature control (0°C) => stop charging
  • Cell max voltage control 3,45V or (Bulk V. / 16) ? => reduce the charging amps to 5A and start a balancing phase
  • Cell min voltage control 2,x ? or (min_discharge_v /16) ? or bms_cell_undervoltage_protection + 0.x ? => stop discharging
This could be based on information from the BMS or values in the script.
If the BMS is poorly programmed then it will not be useful.

What do you think ?
 
V1.16.5 Sleeper85 : Add Preventive Alarms Logic with Balancing function, CAN ID 0x356: send average temperature of T1/T2, new "Discharging current max" slider

github.com

some improvements · Issue #12 · Sleeper85/esphome-jk-bms-can

works great so far - i have some improvements requests Use BMS max charge/discharge current (-5%) [tested and working] recover globals (charge/float voltage, absorbtion time etc) after restart (or ...
github.com github.com
 
Confirming that can protocol 2 and Li Battery 0 on EG4 6000xp is working. Testing with one 5kw battery. Not sure why the calc is showing 50ah battery, have batt_modules: “1”. BMS settings match again, only a single 5kw battery and taking it easy on it.
IMG_4549.jpeg
 
@ChrisG

V1.16.3 Sleeper85 : ID 0x379 will be sent when choosing protocol 2 or 4 (Battery Capacity for Victron, Sol-Ark and Luxpower)

YAML: 
# +--------------------------------------+
# | CAN Protocol Settings                |
# +--------------------------------------+
# CAN BMS Name (0x35E) : 0 NoSent / 1 PYLON / 2 GOODWE / 3 SEPLOS
  can_bms_name: "1"
# CAN Protocol
# 1 : PYLON 1.2 (Deye)
# 2 : SEPLOS 1.0, PYLON 1.3, GOODWE 1.5 (GoodWe, Sol-Ark, Luxpower)
# 3 : SMA (Sunny Island, Sofar)
# 4 : VICTRON
  can_protocol: "2"

The version used is >= 1.16.3 with the CAN parameters as above in the YAML?
 
Sleeper85 said:
@ChrisG

V1.16.3 Sleeper85 : ID 0x379 will be sent when choosing protocol 2 or 4 (Battery Capacity for Victron, Sol-Ark and Luxpower)

YAML: 
# +--------------------------------------+
# | CAN Protocol Settings                |
# +--------------------------------------+
# CAN BMS Name (0x35E) : 0 NoSent / 1 PYLON / 2 GOODWE / 3 SEPLOS
  can_bms_name: "1"
# CAN Protocol
# 1 : PYLON 1.2 (Deye)
# 2 : SEPLOS 1.0, PYLON 1.3, GOODWE 1.5 (GoodWe, Sol-Ark, Luxpower)
# 3 : SMA (Sunny Island, Sofar)
# 4 : VICTRON
  can_protocol: "2"

The version used is >= 1.16.3 with the CAN parameters as above in the YAML?
Click to expand...
I am using 1.16.3. Downloaded 1/2hr before you updated to .4
 
You must log in or register to reply here.

Similar threads

Sleeper85
JK-BMS-CAN with new Cut-Off Charging Logic (open-source)
49 50 51
Replies
1K
Views
40K
cinusik
C
uksa007
JBD/Overkill BMS CAN bus comms support for inverters
2
Replies
47
Views
9K
Tropco
T
X
JK inverter BMS and Voltronic/Phocos Inverter communication
2
Replies
27
Views
695
AshleyL
A
rthorntn
Fake BMS between SmartShunt and GoodWe
Replies
2
Views
437
kommando
K
F
Help programming JK BMS for 24v EVE cells
Replies
9
Views
650
Alarchist
Alarchist

diy solar

diy solar
Back
Top