• Have you tried out dark mode?! Scroll to the bottom of any page to find a sun or moon icon to turn dark mode on or off!

diy solar

diy solar

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

jahyde said:
At ~12am on 12/5 I know SOC was 62%, at 3am Cell_Min_V was 3.11v
Click to expand...

The problem starts here, with min_cell_v at 3.11V your SoC can't be 62%!

I already told you above but the SoC of your BMS is wrong, probably because you haven't charged at 100% for a long time and maybe also because your BMS are not calibrated correctly to measure your standard consumption. I calibrate my BMS for a correct measurement of 5A (this calibration must be done with a fixed current that does not fluctuate, it's important).

It is known that JK-BMS are not good at calculating the SoC and unfortunately part of the system relies on the SoC to make decisions like continuing to discharge the battery or recharging it urgently from the grid.

Adding a Victron Smartshunt or Junctek KH-F to your installation would allow you to have a more accurate SoC.

Note to self: I could introduce the value of min_cell_v in the `Request force charge` function which would be safer.

I see in your screenshot that your two BMS have been uncombined which was probably due to a UVP alarm, you can also check this in your BMS logs.

The reason why the SoC went from 56% to 0% then 2% is the code of my application which detected the false 56% based on the value of min_cell_v which reached 2.4V so smaller than your UVPR. (this is explained in the doc).

I don't have a JK-PB but I recently realized that the OVPR and UVPR values could not be set as with the first JK-B and the new JK-B follow the same logic, following this issue, we changed things in YamBMS 1.5.1 for a correct operation of the Auto CCL / DCL functions, this is not related to your problem but for several reasons I strongly advise you to upgrade to 1.5.1.

I end with a small graph that compares the SoC of my JK-BMS (well calibrated) with the SoC of my Junctek KH-F shunt for a month, see how the SoC of the JK-BMS drifts over time!

You are not the only one having this problem lately, you just have to understand that you can't rely on the JK-BMS SoC, in case of problems look at the voltages of your packs and cells.

SoC JK-BMS 16S vs Junctek shunt.png
 
Agreed, the SOC recorded by the JK BMS is very prone to drift over time.
I recently added a Victron smart shunt to track my SOC due to the improved measurement resolution.

Even after calibration of the JK BMS, the SOC delta is 9 percentage points in 4 days.

26730.png
 
MrPablo said:
Agreed, the SOC recorded by the JK BMS is very prone to drift over time.
I recently added a Victron smart shunt to track my SOC due to the improved measurement resolution.

Even after calibration of the JK BMS, the SOC delta is 9 percentage points in 4 days.
Click to expand...

Which JK BMS is being graphed here? JK-B or JK-PB BMS? Hardware revision? Software version?
 
This leads me to think that I should improve the code related to the SoC sent to the inverter. I never wanted to interfere too much with the SoC sent to the inverter, we are currently content with a small correction near 0% and 100%.

It might be good to add some logic regarding min_cell_voltage to correct a false SoC so that functions like Request force charge can do their job properly.
 
Last edited:
It would be good if this was a feature that could disabled if required.
I say this because one of the batteries I set up for a friend is charged based on 30 minute electricity prices.
He would prefer that the battery does not force charge at unexpected times, as it could be a very expensive period.

I'm in the process of setting up a smart shunt on that battery also.
 
MrPablo said:
It would be good if this was a feature that could disabled if required.
I say this because one of the batteries I set up for a friend is charged based on 30 minute electricity prices.
He would prefer that the battery does not force charge at unexpected times, as it could be a very expensive period.

I'm in the process of setting up a smart shunt on that battery also.
Click to expand...

We will think about this question all together. Recently I was confronted with this problem on @cali-clim Victron system. The passage from a 50% SoC to 0% because of a very low cell triggers a forced charge that stops quickly as soon as min_cell_v goes above low_cell_v (UVP+0.02). The system was yoyoing between 50% and 0% because the forced charge stopped as soon as the SoC returned to 50%, the battery was then discharged again and when min_cell_v touched cell_low_v a 0% SoC was sent again causing a new forced charge and so on...

So I think it would be necessary for the new code to simply detect a false SoC or an anomaly based on the value of min_cell_v. The SoC would be marked as fake and a dedicated code executed only in this case would estimate the real SoC until the SoC can be considered real before sending the real SoC from the BMS. A sudden jump from 0% to 50% should be avoided.
 
Sleeper85 said:
...So I think it would be necessary for the new code to simply detect a false SoC or an anomaly based on the value of min_cell_v. The SoC would be marked as fake and a dedicated code executed only in this case would estimate the real SoC until the SoC can be considered real before sending the real SoC from the BMS. A sudden jump from 0% to 50% should be avoided.
Click to expand...
When the calculation is based upon voltage it needs at least a correction for the rate at which the battery is (dis)charging.
Between 90 and 25% its difficult to detect false SoC because the voltage curve is so flat.

Idea: When there is a YamBMS guestimate displayed, how about display only large steps: f.e. 10%, and maybe a little more gradations in the 90-100 and 0-10% SoC. Then it will be more obvious whether SoC percentage is coming from BMS (1% changes) or YamBMS (mostly 10% changes).

Anyway, what is the cell voltage measurement accuracy of a JK BMS?
 
cj0 said:
When the calculation is based upon voltage it needs at least a correction for the rate at which the battery is (dis)charging.
Between 90 and 25% its difficult to detect false SoC because the voltage curve is so flat.

Idea: When there is a YamBMS guestimate displayed, how about display only large steps: f.e. 10%, and maybe a little more gradations in the 90-100 and 0-10% SoC. Then it will be more obvious whether SoC percentage is coming from BMS (1% changes) or YamBMS (mostly 10% changes).

Anyway, what is the cell voltage measurement accuracy of a JK BMS?
Click to expand...

It is clear that the discharge current as well as min_cell_v must be analyzed together.
It would be possible to add code to detect a real 5% or at most a 10% because above it becomes more complicated.

Concerning the approach of 100% I think that the current code is already OK because the SoC of the BMS will correct itself as the charge progresses and will remain blocked at 98% as long as the charge is not considered complete.
 
During a discharge, if min_cell_v reaches a value (based on the discharge current) considered as 10% and the combined BMS SoC is above 10% then the SoC will be corrected and marked as false, the next step will be 5% then 0%. I can also add a text_sensor to indicate that the SoC has been corrected during this period (useful for debugging).

During a charge, min_cell_v will be analyzed according to the charge current and the SoC gradually increased by 5% jumps up to ??? SoC before sending the real value of the combined BMS SoC and mark the SoC as true.

Edit: but this is easier said than done because in reality temperature also comes into this equation. There are plenty of studies to read on this subject...
 
Last edited:
Just a random here - the SOC on the JK's is fundamentally f**ked! It's well know that their SOC can be way off. For example, yesterday my inverter stopped charging when my cells were around 3.6v (nmc), which I couldn't understand, then I looked at the SOC which was well over 80%, cells should have been nearer 3.9-4v for that SOC. My rough and ready solution is to log into the JK's and set the battery capacity Ah setting WAY out of range briefly, then set it back to the correct number. For example in my battery I set it too 400Ah, then back to it's correct 98Ah. It works a charm :) I'm going to set up a small automation in HomeAssistant to do this maybe once a day I think, as this causes me trouble in every single battery I have every 3-5 days or so. Has there been much progress in getting a better SOC?
 
External shunt is the only safe way if you don't want to risk your pack health as I have noticed on mine - jumping from 53% - 0% in a few seconds. Victron Smart Shunt or Juntek KM105F monitor, both integrate with YamBMS. Victron is also compatible with Solar Assistant.
 
The challenge is that the JK-B BMS is fundamentally not that accurate at current measurement, and therefore coulomb counting.

You can see that the resolution in current measurement is not fantastic compared to a dedicated shunt.
Calibration of the JK-B current works ok for that particular current (for example 25 amps), but it will be inaccurate above and below.

The best option is to integrate a better shunt into the system, otherwise it's just approximations and relying on cell voltages at either extremes.
 
jahyde said:
External shunt is the only safe way if you don't want to risk your pack health as I have noticed on mine - jumping from 53% - 0% in a few seconds. Victron Smart Shunt or Juntek KM105F monitor, both integrate with YamBMS. Victron is also compatible with Solar Assistant.
Click to expand...

Be careful, Junctek KH-F is the latest model from Junctek, it works relatively well. Victron seems to be even better (I haven't compared them).
 
With my Mn15 AOI, I register 35W continuous draw from the battery pack with the victron smart shunt when the sun goes down. None of my other packs are able to register any current and that is expected when you have so many parallel packs. Heck, even the inverter itself is not registering the correct dc power that is being consumed. I think we are expecting too much from these BMSes.
 
Ya, I just double checked, the KH are BT only, KM came out earlier this year with BT+Wifi, so you can use their app from anywhere to check levels. It is interesting, I prefer not being limited to BT range, but I think I will go Victron since my experience has been Solar Assistant devs are not very flexible in adding new options like the Juntek. Someone posted a comparison of both products connected in-line with ~1% variance through the entire SOC range, so accuracy is pretty close on either.
 
jahyde said:
Ya, I just double checked, the KH are BT only, KM came out earlier this year with BT+Wifi, so you can use their app from anywhere to check levels. It is interesting, I prefer not being limited to BT range, but I think I will go Victron since my experience has been Solar Assistant devs are not very flexible in adding new options like the Juntek. Someone posted a comparison of both products connected in-line with ~1% variance through the entire SOC range, so accuracy is pretty close on either.
Click to expand...

But if you want to use it with YamBMS the shunt will have to be connected to your ESP32, Solar Assistant will have the right value too because your inverter will receive the SoC from the shunt.
 
Yes, but I think both RPi and ESP32 can tap in to the shunt tx/rx lines to rs-485 interface.
 
upnorthandpersonal said:
Do you have to run closed loop? If you do, why not use a SmartShunt or something as the SOC indicator to the system instead of the BMS?
Click to expand...
When people say 'smart shunt', do they mean specifically Victron smart shunt, or any type of smart shunt? I have a 300A shunt (not smart) that I've never integrated and was going use that with an ESP32 and another little chip INA (can't remember its number). Could that be integrated into YAMbms from HA? That would only help one system and battery though, the other system which is the main pain with SOC would be more difficult to put a shunt in.
 
No - not "any" smart shunt, it would be the ones discussed in the last 5-6 posts which Sleeper85 has written supporting code for, they have to have RS-485 output, Victron offers a few, and so does Junctek, models discussed above, only Victron is supported by Solar Assistant in case you ever wanted that.

 
Last edited:
I have tried to get 1.5.1 working on a couple of boards with varying success. My Waveshare board currently working on 1.4.5, flashes 1.5.1, boots, connects to BMS, inverter, Home Assistant, but it loses network at 1:40 uptime, I can watch the console on it and it keeps going, keeps reading BMS and sending CAN data to the inverter. This is a ESP32-S3-WROOM-1U-N8 + MCP2515. Attached is a full serial log and yaml, the log probably went by another 1000 lines after network dropped before I pulled the power, it would keep running fine, but no wifi.

Main yaml: https://u.sdit.me/allble1
Here is the board yaml: https://u.sdit.me/board1

1733639138201.png


The other board I have is a ESP32-S3-DevKitC-1-N8R2, that board flashes 1.5.1 and starts to boot, but just stops at this screen:
1733643828928.png
Yaml for this board: https://u.sdit.me/board2
Main config yaml: https://u.sdit.me/allble2

Edit: attachments not saving to post......
 

Attachments

Last edited:
You must log in or register to reply here.

Similar threads

P
JK-PB2A16S-20P BMS overloading at inverter startup
Replies
2
Views
69
1234enough
1
A
How to read Current and Charge State(SOC) from JK BMS to ESP32/Arduino ? preferably via Blue tooth connection.
Replies
13
Views
2K
DanDyse
D
S
Yet another JK BMS to CAN bus interface, this one Arduino, BLE to PylonLV CAN, on a Lilygo T-Display S3
Replies
5
Views
2K
akumd
A
C
How to Flash Atom S3 with EspHome - HA
Replies
23
Views
2K
MaikelK
M
R
a new uart protocol for a Daly Smart 150A BMS?
Replies
9
Views
1K
Tyrulf
T

diy solar

diy solar
Back
Top