No, there is a new yambms_cutoff_timer var since 1.4.1.
YamBMS JK-BMS-CAN with new Cut-Off Charging Logic (open-source)
- Thread starter Sleeper85
- Start date
No, there is a new yambms_cutoff_timer var since 1.4.1.
So would I simply update to latest dev branch or do I modify: yambms_inverter_offset_v or both?
MrPablo
Solar Enthusiast
Yes, but the inverter offset substitution exists in both 1.3.2 and 1.4.1, doesn't it?
@ChrisG, I would recommend the latest version on Dev in this case. Being on the latest version of @Sleeper85's refinements mean it'll be easier for him to support.
I'll admit, I am not on the YAMBMS version yet.
Yes for all
Thanks. Will clone his current dev repo down later and see if the inverter offset is in 1.4.1. Appreciate all the support. I split one of my 2p16s packs just to test this out. It’s awesome.
Here is what I use at home.
YAML:
# Inverter Offset V. allows you to correct the inverter charging voltage.
# Requested Charging Voltage = Bulk. V + Inverter Offset V.
yambms_inverter_offset_v: "0.1"
yambms_inverter_offset_v_slider: 'false' # true: the slider is hidden, false: the slider is availableThanks. Don’t have web enabled in YAML so can’t OTA update it. Won’t be back onsite till later next week.
Just looked at the single BMS code I was running successfully till multi version. The inverter offset was 0.0 in the single BMS code which worked perfectly fine. Not sure of why it's impacting me in multi version.
Last edited:
If we analyze your data it seems that all your devices are well calibrated but you ask for a charge at 55.6V but you get 55.4V so it is possible that the charging conditions will never be met because you will never reach the cutoff voltage, in this situation you can wait a very long time.
The new version 1.4.1 adds a new `Cut-Off` status which will show you that you have reached the end of charging phase without satisfying all the conditions for it to end but in any case you have well reached the V. and A cutoff.
If that's the problem then the voltage offset will be able to solve it but I don't know why it worked well before in 16S2P without using a V offset.
As soon as you see the status `Cut-Off` you are in this part of the code.
So even to trigger the `EOC timer` of 30min you must satisfy the cutoff conditions during the entire end of charge period, if the status changes from `Cut-Off` to `Bulk` or other then the timers will be killed. This version of the charging logic is slightly different of the old single BMS version. I removed the old counter based system and introduced this two new timers.
Regarding OTA updates, you can do them from the command line.
Last edited:
I VPN'd into a local Mac mini and setup a quick dev environment to install 1.4.1 through OTA esphome command line, worked fine. Worse case it would have just been in permanent grid bypass if it could not recognize the battery, even then I can set to voltage mode. @Sleeper85 one thing to add to the readme on dev env setup (for MacOS anyway) is: Install Setup Tools: pip3 install setuptools, just a suggestion to have 'pkg_manager'. After the flash, looked liked the stars aligned and inverter started discharging. Inverter is now set to discharge to 90% and start charging again, will let you all know how it goes. I did have the inverter offset to 0.1 and have the slider available to tweak if needed.
Again, thank all of you for the support.
Again, thank all of you for the support.
Can now confirm the latest code (multi-ble with MCP2515 CAN) works EG4 6000xp (LuxPower) and two battery packs. It's able to hit target voltage (55.4), SOC, and cells are balanced. Just going to let this cycle for a few days and will report back if any issues. Hard to catch the exact moment of cutover from charge to discharge. If this works I'll add the third JK to the mix next week.
@MrPablo @silverstone and all
There was a small bug (fixed) in the YAML AutoCVL, the value of CVL was not saved in the global variable and therefore this function had no effect.
I realized this while implementing the function proposed in issue #44.
So I decided to implement the AutoCVL Boost Charge V. function and it's really great. This allows you to charge your battery more quickly by increasing the charging voltage which will then be reduced automatically by the AutoCVL function developed by @MrPablo in order to reach the target (Bulk voltage + Inverter Offset V.)
So this is a very good reason to use this function.
Only the YAML AutoCVL has been changed, I'm publishing it as soon as my test is finished and I've reached the end of load.
@MrPablo for info this multi-bms version also works with a single BMS (if you want to test).
Thanks again to @MrPablo for the work done.
There was a small bug (fixed) in the YAML AutoCVL, the value of CVL was not saved in the global variable and therefore this function had no effect.
I realized this while implementing the function proposed in issue #44.
So I decided to implement the AutoCVL Boost Charge V. function and it's really great. This allows you to charge your battery more quickly by increasing the charging voltage which will then be reduced automatically by the AutoCVL function developed by @MrPablo in order to reach the target (Bulk voltage + Inverter Offset V.)
So this is a very good reason to use this function.
Only the YAML AutoCVL has been changed, I'm publishing it as soon as my test is finished and I've reached the end of load.
@MrPablo for info this multi-bms version also works with a single BMS (if you want to test).
Thanks again to @MrPablo for the work done.
Last edited:
MrPablo
Solar Enthusiast
I'll be very interested to see requested charge voltage over time, alongside max cell voltage if you get a chance.
Sadly, this is a case where I'm not sure if I can test effectively with my inverter, it's a bit crap at respecting CVL.
Sadly, this is a case where I'm not sure if I can test effectively with my inverter, it's a bit crap at respecting CVL.
Ok that's a few things I could show after a full charge.
Still working with multiple discharge and charge (90-100%) sessions. @Sleeper85 as you can see I am getting Cut-Off in the charging status. So it seems all conditions are not met for complete charging but the timer kicks in anyway. My Delta is under my trigger amount and voltage is spot on.
Last edited:
No, it's the opposite.
Status Cut-Off all conditions are met to enter the last charging phase before EOC.
Ahh ok. So everything is working as expected now. Thanks. I’ve gone through three discharge/charge cycles at this point since my charge SOC is set to 90%. Going to let it continue to run but so far so good.
Charge/Discharge has worked great from 90%-100% throughout last night and today. I set inverter to go down to 30% before a charge cycle and now something else is going on. The current swings wildly between JK1 and JK2 for charging as you can see in the graph related to voltage. Then at 21:11, Got a YAMBMS alarm and Bitmask changed to 16384 then it just discharges. You can also see YAMBMS SOC drops quickly from 48% to 2%.
For reference, here is the 90 to 100% SOC Charge view:
For reference, here is the 90 to 100% SOC Charge view:
It started charging again but same behavior. Interesting is the voltage and SOC difference between JK1 and JK2.
Code:
yambms YamBMS 1 Warning changed to Alarm
9:42:26 PM - 2 minutes ago
yambms YamBMS 1 Alarm changed to Warning
9:42:26 PM - 2 minutes ago
yambms YamBMS 1 BMS combined changed to 1
9:42:26 PM - 2 minutes ago
yambms YamBMS 1 Cell Count (Σ) changed to 16
9:42:26 PM - 2 minutes ago
yambms YamBMS 1 BMS in alarm changed to 1
9:42:25 PM - 2 minutes ago
yambms YamBMS 1 Errors Bitmask Warning changed to 16384
9:42:25 PM - 2 minutes ago
yambms YamBMS 1 Min Voltage Cell changed to 111
9:42:25 PM - 2 minutes ago
yambms YamBMS 1 Charging Cycles (Ø) changed to 1
9:42:25 PM - 2 minutes ago
yambms Uptime Human Readable changed to 01d 02h 40m 10s
9:42:25 PM - 2 minutes ago
yambms JK-BMS 2 Can be combined turned off
9:42:25 PM - 2 minutes ago
yambms JK-BMS 2 Combine Availability turned off
9:42:25 PM - 2 minutes ago
yambms JK-BMS 2 charging turned off
9:42:24 PM - 2 minutes ago
yambms Uptime Human Readable changed to 01d 02h 40m 05s
9:42:20 PM - 2 minutes agoAttachments
Last edited:
@ChrisG
Concerning the soc change from 48% to 2% here is the responsible code:
Then your JK-BMS 2 was decombined because it seems to have been in alarm. Can you show the error_bitmask of JK BMS 2?
We can see that the YamBMS soc is that of JK-BMS 1 because JK-BMS 2 is decombined.
I cannot analyze your data further at the moment, sorry.
Concerning the soc change from 48% to 2% here is the responsible code:
C:
float soc = id(${yambms_id}_state_of_charge).state;
float min_cell_v = id(${yambms_id}_min_cell_voltage).state;
float cell_uvpr = id(${yambms_id}_cell_uvpr).state;
if (min_cell_v <= cell_uvpr) return 0; // Real 0% Sending 0%
else if (soc < 1) return 2; // False 0% sending 2%
else if (soc < 99) return soc; // SOC < 99% => Sending BMS SOC
// Useful for some inverters, will not send 100% until charging is complete
else if (id(${yambms_id}_eoc) == true) return soc; // End Of Charge => Sending BMS SOC
else return 98;Then your JK-BMS 2 was decombined because it seems to have been in alarm. Can you show the error_bitmask of JK BMS 2?
We can see that the YamBMS soc is that of JK-BMS 1 because JK-BMS 2 is decombined.
I cannot analyze your data further at the moment, sorry.
This is an example of a 3 BMS system with 2 BMS in error.
The system continues to operate as long as 1 BMS has no error, the other 2 BMS are decombined.
Boxed in orange, these are the instructions sent to your inverter. If you have defined a charge or discharge current of 20A on both BMS you should see 20A or 40A with 2 BMS. Perhaps your inverter does not follow these instructions?
silverstone
Solar Enthusiast
- Joined
- May 3, 2022
- Messages
- 1,148
I didn't follow all of the Discussion (as I told you I'm currently dealing with lots of other Stuff), but what exactly do you do in this Situation, if you continue to Operate ?
- Voltage kept in "safe range" (e.g. "float" 54.0VDC instead of 55.2VDC)
- Temperature kept in "safe range" (e.g. 25-35 °C)
- Current kept in "safe range" (e.g. TOTAL current Reference <= 1 x rated current of each Battery, i.e. you don't "count on the faulty batteries", yet they will each see 1/3 of the total current in this example, so if each battery is rated 100ADC, each will in the end see 33ADC roughly [minus unbalances of course])
An error_bitmask of 16384 corresponds to bit 14, which is very surprising because it does not correspond to an overcurrent alarm.
Code:
# +--------------------------------------+
# | YamBMS Alarm and Warning |
# +--------------------------------------+
# | Errors Bitmask (16bit) |
# +--------------------------------------+
# 0x8B 0x00 0x00: Battery warning message 0000 0000 0000 0000
#
# Bit 0 Low capacity 1 (alarm), 0 (normal) warning
# Bit 1 Power tube overtemperature 1 (alarm), 0 (normal) alarm
# Bit 2 Charging overvoltage 1 (alarm), 0 (normal) alarm
# Bit 3 Discharging undervoltage 1 (alarm), 0 (normal) alarm
# Bit 4 Battery over temperature 1 (alarm), 0 (normal) alarm
# Bit 5 Charging overcurrent 1 (alarm), 0 (normal) alarm
# Bit 6 Discharging overcurrent 1 (alarm), 0 (normal) alarm
# Bit 7 Cell pressure difference 1 (alarm), 0 (normal) alarm
# Bit 8 Overtemperature alarm in the battery box 1 (alarm), 0 (normal) alarm
# Bit 9 Battery low temperature 1 (alarm), 0 (normal) alarm
# Bit 10 Cell overvoltage 1 (alarm), 0 (normal) alarm
# Bit 11 Cell undervoltage 1 (alarm), 0 (normal) alarm
# Bit 12 309_A protection 1 (alarm), 0 (normal) alarm
# Bit 13 309_A protection 1 (alarm), 0 (normal) alarm
# Bit 14 Reserved
# Bit 15 Reserved
#
# Examples:
# 0x0001 = 00000000 00000001: Low capacity alarm
# 0x0002 = 00000000 00000010: MOS tube over-temperature alarm
# 0x0003 = 00000000 00000011: Low capacity alarm AND power tube over-temperature alarmFor the moment, the BMS in error are decombined, the load values will be adapted for the number of BMS remaining but if you are in Bulk phase you remain in Bulk, I could change that in the future, to think about.
BMS in error protect themselves by deactivating their charge and discharge switch.
Similar threads
