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

[ChrisG]

Yes look at the chart I posted in my edit above. Slowly coming down.

Just so I’m clear, this is the Balance Trigger Voltage in the BMS settings, no where else correct?

 

[MrPablo]

Just so I’m clear, this is the Balance Trigger Voltage in the BMS settings, no where else correct?

Yes, that's correct.

 

[Der_Hannes]

But is your actual Charge status 'Balancing' or 'Bulk'?

 

[ChrisG]

But is your actual Charge status 'Balancing' or 'Bulk'?

It’s Balancing so seems to be working as expected.

 

[silverstone]

how is the actual cell deviation and is the BMS actually balancing?

are you on version 1.17.3 or 1.17.4?

Using @Sleeper85 code I guess.

I'd be VERY interested if you could port the latest changes into your code @Der_Hannes .i might also play a bit around, but I'm a complete esphome noob

 

[Der_Hannes]

Using @Sleeper85 code I guess.

I'd be VERY interested if you could port the latest changes into your code @Der_Hannes .i might also play a bit around, but I'm a complete esphome noob

already working on catching up to 1.17.4 - but have to solve some issues and can´s actually say when it will be finished

 

[silverstone]

already working on catching up to 1.17.4 - but have to solve some issues and can´s actually say when it will be finished

I guess I'll test your current version this weekend then. I guess the Deye inverter will trip when I change battery mode from voltage mode to lithium (00 type I assume ?)

 

[chaosnature]

That seems like the "offset" / voltage measurement error problem I had.

If it was 0.033V for the entire pack I would understand.
But 0.46V difference across your 14s is more likely a lack of calibration of your jk bms in the jk bms app.

As I said I used to have 0.7V voltage difference for the full pack. First I thought it was a diode. Then it was probably a voltage measurement error. Finally, at NO LOAD, disconnect everything and measure with the multimeter. The difference was there.

Since I calibrated the voltage at NO LOAD in the jk bms app the voltage readings *for the entire PACK* have stayed between +0 ... + 0.15V (instead of +0.7V !).
When I load the battery a bit (especially DISCHARGE) the difference becomes virtually zero.

I am not particularly happy with some ppl on this thread - not mentioning names , bcos i dont want to give them excuse to start something bcos if they do i might explode on them.

But for the project sake and for the sake of ppl who will refer to similar senario when they do their reseach i am updating my findings .

It is not the Pylon protocol causing issues rather it was a faulty fuse when i duge more into the connections.

i have since installed 100A fuses into the individual batteries and replace the fuse with a junction box - and now its all good.

thanks to all those who contributed..

Good luck with future updates......

 

[MrPablo]

I am not particularly happy with some ppl on this thread - not mentioning names , bcos i dont want to give them excuse to start something bcos if they do i might explode on them.

But for the project sake and for the sake of ppl who will refer to similar senario when they do their reseach i am updating my findings .

It is not the Pylon protocol causing issues rather it was a faulty fuse when i duge more into the connections.

i have since installed 100A fuses into the individual batteries and replace the fuse with a junction box - and now its all good.

thanks to all those who contributed..

Good luck with future updates......

Good to hear you found and resolved an issue, are your cables also rated for 100A?

 

[ChrisG]

I’m using 1.17.3. Balancing is almost complete. Down to .012. Trigger is set to .010.

I didn’t know 1.17.4 was out. Don’t see it on git.

 

[MrPablo]

I’m using 1.17.3. Balancing is almost complete. Down to .012. Trigger is set to .010.

I didn’t know 1.17.4 was out. Don’t see it on git.

It's not finalised yet, we're doing some internal testing first to make sure nothing blows up.

 

[ChrisG]

Balancing finished and it went right to discharge. Note, no PV hooked up yet, only grid. PV will hopefully be installed in a month as things start thawing out.

 

[Der_Hannes]

I guess I'll test your current version this weekend then. I guess the Deye inverter will trip when I change battery mode from voltage mode to lithium (00 type I assume ?)

No, mine does not trip - trips only when changing grid mode, low noise mode or something related

 

[Der_Hannes]

No, mine does not trip - trips only when changing grid mode, low noise mode or something related

Oh wait, mine is grid connected - maybe it trips when you are off-grid? I don't know that

 

[Der_Hannes]

I am not particularly happy with some ppl on this thread - not mentioning names , bcos i dont want to give them excuse to start something bcos if they do i might explode on them.

But for the project sake and for the sake of ppl who will refer to similar senario when they do their reseach i am updating my findings .

It is not the Pylon protocol causing issues rather it was a faulty fuse when i duge more into the connections.

i have since installed 100A fuses into the individual batteries and replace the fuse with a junction box - and now its all good.

thanks to all those who contributed..

Good luck with future updates......

thanks for the update and clearing that out
i dont want to mention names too, but someone said a week ago that your breakers are causing problems ;-)

 

[Brucey]

thanks for the update and clearing that out
i dont want to mention names too, but someone said a week ago that your breakers are causing problems ;-)

When I first read that previous post I thought it was you venting (understandably), was stunned to see who posted it.

 

[silverstone]

Oh wait, mine is grid connected - maybe it trips when you are off-grid? I don't know that

Yeah that was my concern.

What about reflashing or upgrading? Are you doing OTA it's just a matter of disconnecting everything and reflashing manually?

What happens if the other Esp32 stop sending data (mqtt persistence data / old data)... Do you tell the inverter to stay in a "neutral" place (e. G. 53V), do you trip, or you cannot detect that? I'm talking about fail Safe basically

 

[silverstone]

@Der_Hannes :i had a very quick look at your code... Not sure if esphome natively supports this, but it would be great if you could do a "for" loop to populate the yaml file for every bms (and potentially every shunt which I'm planning).

If esphome doesn't support it, I'd suggest using python+jinja2 to generate these files based on a template and configuration script so that the part concerning BMS 1 BMS 2 etc gets dynamically generated (and maybe we define these exact names in a confog file, as I prefer to use bat 01 and bat 02 for instance so that nothing weird happens once I hit 10 ) .

I'll try to see if I can create a fork and implement this idea (unless you see better options of course) .

 

[Der_Hannes]

Yeah that was my concern.

What about reflashing or upgrading? Are you doing OTA it's just a matter of disconnecting everything and reflashing manually?

What happens if the other Esp32 stop sending data (mqtt persistence data / old data)... Do you tell the inverter to stay in a "neutral" place (e. G. 53V), do you trip, or you cannot detect that? I'm talking about fail Safe basically

I do all my updates OTA - think the initial flashing should be done via USB
there might be a way to do thith OTA as well using a fixed IP, but i would not recommend it, cause OTA the bootloader and partitions doesnt get flashed - so initial OTA can caus problems.

you have to use the last will topic on the slave ESPs - so the broker notifies if the node is not connected anymore
i have also implemented a binary sensor on my slaves which states the BLE connection
Both conditions must be met to be a valid source for the master - otherwise the node gets ignored then.
the inverter will be told a charge and discharge current of 0A and a charge voltage of 0V
In my deye i have to enable "BMS_err_stop" to get the inverter to shut off - otherwise the CAN Data gets ignored and the inveter still works (charging, discharging, load etc)
There need to be done further investigation

 

[Der_Hannes]

@Der_Hannes :i had a very quick look at your code... Not sure if esphome natively supports this, but it would be great if you could do a "for" loop to populate the yaml file for every bms (and potentially every shunt which I'm planning).

If esphome doesn't support it, I'd suggest using python+jinja2 to generate these files based on a template and configuration script so that the part concerning BMS 1 BMS 2 etc gets dynamically generated (and maybe we define these exact names in a confog file, as I prefer to use bat 01 and bat 02 for instance so that nothing weird happens once I hit 10 ) .

I'll try to see if I can create a fork and implement this idea (unless you see better options of course) .

there is only one template yaml file for the JK BMSs which must be included via package include - there is a parameter "bms"
So if you have 3 BMSs, you need to inlude the template file 3 times (bms: 1 / bms: 2 / bms: 3)

for the combine sections, i dont know dynamic way to implement a different number of devices - but unless your number of BMSs changes often, i think the copy-paste effort is handleable on inital setup

Good idea to add a leading zero - i have to figure that out for the future - but actually there should be no problems when hitting 10 BMSs