Louisvdw / dbus-serialbattery

Battery Monitor driver for serial battery in VenusOS GX systems
MIT License
539 stars 165 forks source link

JK BMS - SoC daily decreasing by 2% #703

Closed Dighy closed 1 year ago

Dighy commented 1 year ago

Describe the problem

Hello everybody,

I would like to start telling that I'm just beginer and I'm following all the instruction provided. I was replacing my old battery with 24V/280Ah lifepo4 battery monitored by JK Bms (2A8S20P) in a Victron Easy solar 24/3000 with CCGX system. Initially I let it running by setting only the VE Bus System (multiplus) and Solar charger (70A/150V type) with settings like CVL-27.2V and CCL - 50A and I checked the battery behavior at high discharge rate (120A). Everything fine Soc was going from 100% to 99%(float mode) and 68-74% in the morning as per consumption. After few days, I installed the driver version [v1.0.20230508beta] with every setting from default, I set JK-BMS serial battery as master (external control) and behavior was the same like without driver from SoC calculation point of view. Once the latest version was released [v1.0.20230531], I update it by USB in my CCGX and updated the value of CCL to 70A and DCL to 100A through SSL client Putty and reboot the GX. That I noticed is that in the first 2 days SoC was not going to 100% and only to 99% and after that every day maximum was 2% less compare with previous day (eq. 97%-95%-93%......) and now I reached 89% and as per logic CVL is going to 27.6V, then reduced to 27V (float) and after increasing again to 27.6V due to the SoC < 90%. Today, I came back to CCL - 50A and all the others the same as before to see what is going on... I would be so greatful for any support on what is the issue and how to correct it.

Thanks.

Driver version

v1.0.20230531

Venus OS device type

CCGX

Venus OS version

2.94

BMS type

JKBMS / Heltec BMS

Cell count

8

Connection type

Serial USB adapter to RS485

Config file

[DEFAULT]

; --------- Battery Current limits ---------
MAX_BATTERY_CHARGE_CURRENT    = 70.0
MAX_BATTERY_DISCHARGE_CURRENT = 100.0

; --------- Cell Voltages ---------
; Description: Cell min/max voltages which are used to calculate the min/max battery voltage
; Example: 16 cells * 3.45V/cell = 55.2V max charge voltage. 16 cells * 2.90V = 46.4V min discharge voltage
MIN_CELL_VOLTAGE   = 2.900
; Max voltage can seen as absorption voltage
MAX_CELL_VOLTAGE   = 3.450
FLOAT_CELL_VOLTAGE = 3.375

; --------- Bluetooth BMS ---------
; Description: List the Bluetooth BMS here that you want to install
; Example with 1 BMS: Jkbms_Ble C8:47:8C:00:00:00
; Example with 3 BMS: Jkbms_Ble C8:47:8C:00:00:00, Jkbms_Ble C8:47:8C:00:00:11, Jkbms_Ble C8:47:8C:00:00:22
BLUETOOTH_BMS =

; --------- BMS disconnect behaviour ---------
; Description: Block charge and discharge when the communication to the BMS is lost. If you are removing the
;              BMS on purpose, then you have to restart the driver/system to reset the block.
; False: Charge and discharge is not blocked on BMS communication loss
; True: Charge and discharge is blocked on BMS communication loss, it's unblocked when connection is established
;       again or the driver/system is restarted
BLOCK_ON_DISCONNECT = False

; --------- Charge mode ---------
; Choose the mode for voltage / current limitations (True / False)
; False is a step mode: This is the default with limitations on hard boundary steps
; True is a linear mode:
;     For CCL and DCL the values between the steps are calculated for smoother values (by WaldemarFech)
;     For CVL max battery voltage is calculated dynamically in order that the max cell voltage is not exceeded
LINEAR_LIMITATION_ENABLE = True

; Specify in seconds how often the linear values should be recalculated
LINEAR_RECALCULATION_EVERY = 60
; Specify in percent when the linear values should be recalculated immediately
; Example: 5 for a immediate change, when the value changes by more than 5%
LINEAR_RECALCULATION_ON_PERC_CHANGE = 5

; --------- Charge Voltage limitation (affecting CVL) ---------
; Description: Limit max charging voltage (MAX_CELL_VOLTAGE * cell count), switch from max voltage to float
;              voltage (FLOAT_CELL_VOLTAGE * cell count) and back
;     False: Max charging voltage is always kept
;     True: Max charging voltage is reduced based on charge mode
;         Step mode: After max voltage is reached for MAX_VOLTAGE_TIME_SEC it switches to float voltage. After
;                    SoC is below SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT it switches back to max voltage.
;         Linear mode: After max voltage is reachend and cell voltage difference is smaller or equal to
;                      CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL it switches to float voltage after 300 (fixed)
;                      additional seconds. After cell voltage difference is greater or equal to
;                      CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT it switches back to max voltage.
; Example: The battery reached max voltage of 55.2V and hold it for 900 seconds, the the CVL is switched to
;          float voltage of 53.6V to don't stress the batteries. Allow max voltage of 55.2V again, if SoC is
;          once below 90%
;          OR
;          The battery reached max voltage of 55.2V and the max cell difference is 0.010V, then switch to float
;          voltage of 53.6V after 300 additional seconds to don't stress the batteries. Allow max voltage of
;          55.2V again if max cell difference is above 0.050V
; Charge voltage control management enable (True/False).
CVCM_ENABLE = True

; -- CVL reset based on cell voltage diff (linear mode)
; Specify cell voltage diff where CVL limit is kept until diff is equal or lower
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL = 0.010
; Specify cell voltage diff where CVL limit is reset to max voltage, if value get above
; the cells are considered as imbalanced, if the cell diff exceeds 5% of the nominal cell voltage
; e.g. 3.2 V * 5 / 100 = 0.160 V
CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT = 0.080

; -- CVL reset based on SoC option (step mode)
; Specify how long the max voltage should be kept, if reached then switch to float voltage
MAX_VOLTAGE_TIME_SEC = 900
; Specify SoC where CVL limit is reset to max voltage, if value gets below
SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT = 90

; --------- Cell Voltage Current limitation (affecting CCL/DCL) ---------
; Description: Maximal charge / discharge current will be in-/decreased depending on min and max cell voltages
; Example: 18 cells * 3.55V/cell = 63.9V max charge voltage
;          18 cells * 2.70V/cell = 48.6V min discharge voltage
;          But in reality not all cells reach the same voltage at the same time. The (dis)charge current
;          will be (in-/)decreased, if even ONE SINGLE BATTERY CELL reaches the limits

; Charge current control management referring to cell-voltage enable (True/False).
CCCM_CV_ENABLE = True
; Discharge current control management referring to cell-voltage enable (True/False).
DCCM_CV_ENABLE = True

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
CELL_VOLTAGES_WHILE_CHARGING   = 3.55, 3.50, 3.45, 3.30
MAX_CHARGE_CURRENT_CV_FRACTION =    0, 0.05,  0.5,    1

CELL_VOLTAGES_WHILE_DISCHARGING   = 2.70, 2.80, 2.90, 3.10
MAX_DISCHARGE_CURRENT_CV_FRACTION =    0,  0.1,  0.5,    1

; --------- Temperature limitation (affecting CCL/DCL) ---------
; Description: Maximal charge / discharge current will be in-/decreased depending on temperature
; Example: The temperature limit will be monitored to control the currents. If there are two temperature senors,
;          then the worst case will be calculated and the more secure lower current will be set.
; Charge current control management referring to temperature enable (True/False).
CCCM_T_ENABLE = True
; Charge current control management referring to temperature enable (True/False).
DCCM_T_ENABLE = True

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
TEMPERATURE_LIMITS_WHILE_CHARGING = 0,   2,   5,  10,  15, 20, 35,  40, 55
MAX_CHARGE_CURRENT_T_FRACTION     = 0, 0.1, 0.2, 0.4, 0.8,  1,  1, 0.4,  0

TEMPERATURE_LIMITS_WHILE_DISCHARGING = -20,   0,   5,  10, 15, 45, 55
MAX_DISCHARGE_CURRENT_T_FRACTION     =   0, 0.2, 0.3, 0.4,  1,  1,  0

; --------- SOC limitation (affecting CCL/DCL) ---------
; Description: Maximal charge / discharge current will be increased / decreased depending on State of Charge,
;              see CC_SOC_LIMIT1 etc.
; Example: The SoC limit will be monitored to control the currents.
; Charge current control management enable (True/False).
CCCM_SOC_ENABLE = True
; Discharge current control management enable (True/False).
DCCM_SOC_ENABLE = True

; Charge current soc limits
CC_SOC_LIMIT1 = 98
CC_SOC_LIMIT2 = 95
CC_SOC_LIMIT3 = 91

; Charge current limits
CC_CURRENT_LIMIT1_FRACTION = 0.1
CC_CURRENT_LIMIT2_FRACTION = 0.3
CC_CURRENT_LIMIT3_FRACTION = 0.5

; Discharge current soc limits
DC_SOC_LIMIT1 = 10
DC_SOC_LIMIT2 = 20
DC_SOC_LIMIT3 = 30

; Discharge current limits
DC_CURRENT_LIMIT1_FRACTION = 0.1
DC_CURRENT_LIMIT2_FRACTION = 0.3
DC_CURRENT_LIMIT3_FRACTION = 0.5

; --------- Time-To-Go ---------
; Description: Calculates the time to go shown in the GUI
;              Recalculation is done based on TIME_TO_SOC_RECALCULATE_EVERY
TIME_TO_GO_ENABLE = True

; --------- Time-To-Soc ---------
; Description: Calculates the time to a specific SoC
; Example: TIME_TO_SOC_POINTS = 50, 25, 15, 0
;          6h 24m remaining until 50% SoC
;          17h 36m remaining until 25% SoC
;          22h 5m remaining until 15% SoC
;          28h 48m remaining until 0% SoC
; Set of SoC percentages to report on dbus and MQTT. The more you specify the more it will impact system performance.
; [Valid values 0-100, comma separated list. More that 20 intervals are not recommended]
; Example: TIME_TO_SOC_POINTS = 100, 95, 90, 85, 75, 50, 25, 20, 10, 0
; Leave empty to disable
TIME_TO_SOC_POINTS =
; Specify TimeToSoc value type [Valid values 1, 2, 3]
; 1 Seconds
; 2 Time string <days>d <hours>h <minutes>m <seconds>s
; 3 Both seconds and time string "<seconds> [<days>d <hours>h <minutes>m <seconds>s]"
TIME_TO_SOC_VALUE_TYPE = 1
; Specify in seconds how often the TimeToSoc should be recalculated
; Minimum are 5 seconds to prevent CPU overload
TIME_TO_SOC_RECALCULATE_EVERY = 60
; Include TimeToSoC points when moving away from the SoC point [Valid values True, False]
; These will be as negative time. Disabling this improves performance slightly
TIME_TO_SOC_INC_FROM = False

; --------- Additional settings ---------
; Specify only one BMS type to load else leave empty to try to load all availabe
; LltJbd, Ant, Daly, Daly, Jkbms, Lifepower, Renogy, Renogy, Ecs
BMS_TYPE =

; Publish the config settings to the dbus path "/Info/Config/"
PUBLISH_CONFIG_VALUES = 1

; Select the format of cell data presented on dbus [Valid values 0,1,2,3]
; 0 Do not publish all the cells (only the min/max cell data as used by the default GX)
; 1 Format: /Voltages/Cell (also available for display on Remote Console)
; 2 Format: /Cell/#/Volts
; 3 Both formats 1 and 2
BATTERY_CELL_DATA_FORMAT = 1

; Simulate Midpoint graph (True/False).
MIDPOINT_ENABLE = False

; Battery temperature
; Specifiy how the battery temperature is assembled
; 0 Get mean of temperature sensor 1 and temperature sensor 2
; 1 Get only temperature from temperature sensor 1
; 2 Get only temperature from temperature sensor 2
TEMP_BATTERY = 0

; Temperature sensor 1 name
TEMP_1_NAME = Temp 1

; Temperature sensor 2 name
TEMP_2_NAME = Temp 2

; --------- BMS specific settings ---------

; -- LltJbd settings
; SoC low levels
; NOTE: SOC_LOW_WARNING is also used to calculate the Time-To-Go even if you are not using a LltJbd BMS
SOC_LOW_WARNING = 20
SOC_LOW_ALARM   = 10

; -- Daly settings
; Battery capacity (amps) if the BMS does not support reading it
BATTERY_CAPACITY = 50
; Invert Battery Current. Default non-inverted. Set to -1 to invert
INVERT_CURRENT_MEASUREMENT = 1

; -- ESC GreenMeter and Lipro device settings
GREENMETER_ADDRESS  = 1
LIPRO_START_ADDRESS = 2
LIPRO_END_ADDRESS   = 4
LIPRO_CELL_COUNT = 15
Footer
© 2023 GitHub, Inc.
Footer navigation
Terms
Priv

Relevant log output

root@ccgx:~# tail -F -n 100 /data/log/dbus-serialbattery.ttyUSB0/current | tai64nlocal
2023-06-10 14:05:00.418178500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:00.421230500 INFO:SerialBattery:Testing Ecs
2023-06-10 14:05:00.680324500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:00.682613500 INFO:SerialBattery:Testing HeltecModbus
2023-06-10 14:05:05.664882500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:05.666927500 INFO:SerialBattery:Testing HLPdataBMS4S
2023-06-10 14:05:10.243922500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:10.260524500 INFO:SerialBattery:Testing Jkbms
2023-06-10 14:05:10.622829500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:10.656490500 INFO:SerialBattery:Testing Lifepower
2023-06-10 14:05:11.034053500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:11.049800500 INFO:SerialBattery:Testing LltJbd
2023-06-10 14:05:11.470241500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:11.539241500 INFO:SerialBattery:Testing Renogy
2023-06-10 14:05:11.907924500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:11.956294500 INFO:SerialBattery:Testing Renogy
2023-06-10 14:05:12.359554500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:12.409389500 INFO:SerialBattery:Testing Seplos
2023-06-10 14:05:13.498134500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:14.001186500 INFO:SerialBattery:Testing Daly
2023-06-10 14:05:14.174892500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:14.177150500 INFO:SerialBattery:Testing Daly
2023-06-10 14:05:14.358791500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:14.361598500 INFO:SerialBattery:Testing Ecs
2023-06-10 14:05:14.927333500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:14.938899500 INFO:SerialBattery:Testing HeltecModbus
2023-06-10 14:05:19.480098500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:19.491206500 INFO:SerialBattery:Testing HLPdataBMS4S
2023-06-10 14:05:24.056239500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-10 14:05:24.058070500 INFO:SerialBattery:Testing Jkbms
2023-06-10 14:05:24.272273500 INFO:SerialBattery:Connection established to Jkbms
2023-06-10 14:05:24.313045500 INFO:SerialBattery:Battery Jkbms connected to dbus from /dev/ttyUSB0
2023-06-10 14:05:24.317409500 INFO:SerialBattery:========== Settings ==========
2023-06-10 14:05:24.339809500 INFO:SerialBattery:> Connection voltage: 27.49V | Current: 6.23A | SoC: 89%
2023-06-10 14:05:24.348689500 INFO:SerialBattery:> Cell count: 8 | Cells populated: 0
2023-06-10 14:05:24.365962500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2023-06-10 14:05:24.370631500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 70.0A | MAX BATTERY DISCHARGE CURRENT: 100.0A
2023-06-10 14:05:24.397823500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 75.0A | MAX BATTERY DISCHARGE CURRENT: 140.0A (read from BMS)
2023-06-10 14:05:24.419063500 INFO:SerialBattery:> CVCM:     True
2023-06-10 14:05:24.422176500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.45V
2023-06-10 14:05:24.432216500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2023-06-10 14:05:24.450465500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2023-06-10 14:05:24.455104500 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
2023-06-10 14:05:24.465389500 INFO:SerialBattery:Serial Number/Unique Identifier: Ghy Baterie 7.2K
2023-06-10 14:05:25.073299500 INFO:SerialBattery:DeviceInstance = 1
2023-06-10 14:05:25.075984500 INFO:SerialBattery:com.victronenergy.battery.ttyUSB0
2023-06-10 14:05:25.560512500 INFO:SerialBattery:publish config values = 1
2023-06-11 05:52:48.388214500 *** CCGX booted (1) ***
2023-06-11 05:54:15.352873500 INFO:SerialBattery:Starting dbus-serialbattery
2023-06-11 05:54:15.389372500 INFO:SerialBattery:dbus-serialbattery v1.0.20230531
2023-06-11 05:54:15.437346500 INFO:SerialBattery:Testing Daly
2023-06-11 05:54:15.668394500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:15.674437500 INFO:SerialBattery:Testing Daly
2023-06-11 05:54:15.885802500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:15.887633500 INFO:SerialBattery:Testing Ecs
2023-06-11 05:54:16.112791500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:16.114470500 INFO:SerialBattery:Testing HeltecModbus
2023-06-11 05:54:20.990416500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:20.992216500 INFO:SerialBattery:Testing HLPdataBMS4S
2023-06-11 05:54:25.631865500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:25.634154500 INFO:SerialBattery:Testing Jkbms
2023-06-11 05:54:26.070250500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:26.085905500 INFO:SerialBattery:Testing Lifepower
2023-06-11 05:54:26.521666500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:26.553496500 INFO:SerialBattery:Testing LltJbd
2023-06-11 05:54:26.980406500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:27.007841500 INFO:SerialBattery:Testing Renogy
2023-06-11 05:54:27.423674500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:27.455473500 INFO:SerialBattery:Testing Renogy
2023-06-11 05:54:27.948149500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:27.986388500 INFO:SerialBattery:Testing Seplos
2023-06-11 05:54:29.104338500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:29.607481500 INFO:SerialBattery:Testing Daly
2023-06-11 05:54:29.789763500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:29.791533500 INFO:SerialBattery:Testing Daly
2023-06-11 05:54:29.987914500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:29.989622500 INFO:SerialBattery:Testing Ecs
2023-06-11 05:54:30.519377500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:30.544188500 INFO:SerialBattery:Testing HeltecModbus
2023-06-11 05:54:35.136473500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:35.149535500 INFO:SerialBattery:Testing HLPdataBMS4S
2023-06-11 05:54:39.718108500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2023-06-11 05:54:39.794737500 INFO:SerialBattery:Testing Jkbms
2023-06-11 05:54:40.544066500 INFO:SerialBattery:Connection established to Jkbms
2023-06-11 05:54:40.615324500 INFO:SerialBattery:Battery Jkbms connected to dbus from /dev/ttyUSB0
2023-06-11 05:54:40.735716500 INFO:SerialBattery:========== Settings ==========
2023-06-11 05:54:40.862151500 INFO:SerialBattery:> Connection voltage: 26.92V | Current: 10.51A | SoC: 83%
2023-06-11 05:54:40.864012500 INFO:SerialBattery:> Cell count: 8 | Cells populated: 0
2023-06-11 05:54:40.993437500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2023-06-11 05:54:40.995360500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 50.0A | MAX BATTERY DISCHARGE CURRENT: 100.0A
2023-06-11 05:54:41.124907500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 75.0A | MAX BATTERY DISCHARGE CURRENT: 140.0A (read from BMS)
2023-06-11 05:54:41.235411500 INFO:SerialBattery:> CVCM:     True
2023-06-11 05:54:41.307494500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.45V
2023-06-11 05:54:41.400694500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2023-06-11 05:54:41.476469500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2023-06-11 05:54:41.613432500 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
2023-06-11 05:54:41.676390500 INFO:SerialBattery:Serial Number/Unique Identifier: Ghy Baterie 7.2K
2023-06-11 05:54:42.644408500 INFO:SerialBattery:DeviceInstance = 1
2023-06-11 05:54:42.659331500 INFO:SerialBattery:com.victronenergy.battery.ttyUSB0
2023-06-11 05:54:43.215483500 INFO:SerialBattery:publish config values = 1

Any other information that may be helpful

No response

jdeus commented 1 year ago

Same issue. The issue seems that this project does not implement scheduled charge

mr-manuel commented 1 year ago

The JKBMS resets the SoC to 95%, when all cell voltages are greater or equal to 3.500 V. Please try to increase MAX_CELL_VOLTAGE to 3.50 or 3.51.

Dighy commented 1 year ago

The JKBMS resets the SoC to 95%, when all cell voltages are greater or equal to 3.500 V. Please try to increase MAX_CELL_VOLTAGE to 3.50 or 3.51.

I will try this and leave the feedback. My concern is why with previous version there was no issue by using the same max cell voltage 3.45V. The only thing was changed is CCL and DCL. But today I came back to default CCL (50A). Let's see how it behave. Thanks

mr-manuel commented 1 year ago

Probably because before the CVL was not as accurate as it is now.

mr-manuel commented 1 year ago

Same issue. The issue seems that this project does not implement scheduled charge

@jdeus can you please explain better with an example?

mr-manuel commented 1 year ago

@Dighy @TazerReloaded, could you try to lower the OVP in the BMS settings to 3.48 volts and the OVPR to 3.45. Then change the MAX_CELL_VOLTAGE in the config.ini to 3.48 and see, if this resets the SoC to 100%.

If this works you could set the OVP values to the values you need/want, e.g. OVP to 3.45 and OVPR to 3.40. But you have to try what works best. Please report back.

Dighy commented 1 year ago

Today I've tried your sugestion with max. cell voltage 3.51V but still the same. Soc not sereted. See the pictures. ![Console](https://github.com/Louisvdw/dbus-serialbattery/assets/127723834/51ecafe0-bddd-4283-b62a-4d Cell voltage 312937ab46)

I will check also OVP 3.48V and OVPR 3.45V in BMS settings and let you know.

jdeus commented 1 year ago

@mr-manuel Due to the voltage-SOC relationship on LFP, the only way to ensure batteries stay balanced is to periodically increase the voltage such as all cells reach 3.6V. Once or twice a month seems reasonable. Currently, this option is missing from this project.

We should be able to define the frequency of this top-up.

Dighy commented 1 year ago

@Dighy @TazerReloaded, could you try to lower the OVP in the BMS settings to 3.48 volts and the OVPR to 3.45. Then change the MAX_CELL_VOLTAGE in the config.ini to 3.48 and see, if this resets the SoC to 100%.

If this works you could set the OVP values to the values you need/want, e.g. OVP to 3.45 and OVPR to 3.40. But you have to try what works best. Please report back.

Feedback: I was in settings proposed for reseting SoC (max. voltage 3.51V each cell) and then I've changed back to max. 3.45V as default limit and reboot the CCGX. After, I changed in the BMS settings the OVPR to 3.45V and OVP to 3.48V and suddenly SoC increased from 86% to 95%. That time cells voltage was 3.45V After going back to float (3.75V/cell), I've changed the OVP to 3.46V and OVPR to 3.43V and tomorow I will see what SoC will be coming. :)

mr-manuel commented 1 year ago

@jdeus please open a feature request for this. This is not related to this issue.

@Dighy it will be interesting, if the JKBMS resets the SoC to 100%, if OVP is hit. Please check also, if this is needed for all cells or only one. Currently it seems that when OVPR is reachet the BMS resets to 95% and probably when OVP is reached the BMS resets to 100%.

jdeus commented 1 year ago

@mr-manuel On the contrary I think it's the same issue. A connected battery pack should not have its reported SOC decreased like that. Without any top-up, JKBMS will slowly decrease the SOC, and that's what I also observe and what's described here.

mr-manuel commented 1 year ago

We cannot change what the BMS firmware does with this SOC. You can try to write to the JKBMS developers, but I had no luck since months to receive valid answers...

TazerReloaded commented 1 year ago

Setting the OVP to a value lower than the highest cell resets the SoC to 98% on my JKs, but also disconnects charging and raises a lot of alarms. It's an emergency function after all, to protect the cells if something in the charging logic goes wrong. I had better luck completely ignoring the BMS SoC and just using it for cell protection. Victrons own coulomb counter seems to be pretty accurate, and it resets when absorption voltage is reached (55.2V in my setup). The JKs tend to drift downwards over time, but not to the same amount, one BMS is only 6% lower than the actual SoC at the moment, the other one a whole 30%. I did a current and voltage calibration with the same meter on both, but that did not improve things, they were already calibrated reasonably well from the factory. They were also bought together, same exact type, wiring and configuration on both.

Dighy commented 1 year ago

@jdeus please open a feature request for this. This is not related to this issue.

@Dighy it will be interesting, if the JKBMS resets the SoC to 100%, if OVP is hit. Please check also, if this is needed for all cells or only one. Currently it seems that when OVPR is reachet the BMS resets to 95% and probably when OVP is reached the BMS resets to 100%.

Feedback: With CVL=3.45V as per driver defaut settings and OVP=3.46V in the BMS settings, The Soc was reseted to 100% once alarm os high cell voltage was triggered by BMS. This alarm was coming in cascade until I set back the OVP to higher value in order to let the controller judge the situation and reduce the current to stabilize at 3.45V. This is only a solution if you are closer to intervene immediately. My oppinion: During the charging, let's say, it is reached 3.45V and it waiting for cells balance and SoC is 100%.
Until evening, controller is trying to maintain the foalt voltage of 3.375V and when this value is increasing start discharging the battery or viceversa. At the and of the day, battery SoC will ve 2% max 3% lower, which means 98-97%. I think BMS is not counting this and next day is calculating the energy consumed during the night and it will charge up to 97-98% only and like this BMS SoC will be decreasing daily some value. I will follow this for next days to see if its confirmed.

ArendsM commented 1 year ago

Hi all,

I’m owning a JK BMS as well and having the same issue. I would like to share my idea with you:

After or just before the MAX_VOLTAGE_TIME_SEC time is over, perform the following algorithm:

• Rember actual BMS values for OVP and OVPR • Supress “High voltage alarm” in BMS readout loop by setting a filter • Change OVPR value to the value of the highest cell voltage – 0.5 by modifying the matching BMS register • Change OVP value to the value of the highest cell voltage – 0.1 by modifying the matching BMS register

That should trigger an OVP alert (at least for the BMS) and resets the SoC to 100%

• Reset OVP and OVPR values back to the previous settings • Remove the filter to supress the “High voltage alarm”

What do you think?

Best regards Meik

mr-manuel commented 1 year ago

I had a similar idea and it should work, but is not that easy to implement. Anyway that would be a great feature!

It has to work with serial and Bluetooth connection. For the Bluetooth connection there is already some code to change settings.

Surpressing the BMS alert is the easiest thing, changing the OVPR and OVP values the trickiest one. Feel free to open a PR for this!

josmeijer commented 1 year ago

I have the same (or comparable) problem with my DALY smart BMS. SOC was gradually decreasing and I reset it a couple of times (by means of the Daly app) to 100% but due to busy times I did not attend the instalation for a while to find out that the max SOX is 85% by now. I can find no anomalies (no reports of bad cells preventin it from full charge) If someone is in the opportunity to have a look and see if I overlooked something essential, I will set the VRM link to open for a while https://vrm.victronenergy.com/installation/31525/share/c43e4823

drtinaz commented 1 year ago

I have the same (or comparable) problem with my DALY smart BMS. SOC was gradually decreasing and I reset it a couple of times (by means of the Daly app) to 100% but due to busy times I did not attend the instalation for a while to find out that the max SOX is 85% by now. I can find no anomalies (no reports of bad cells preventin it from full charge) If someone is in the opportunity to have a look and see if I overlooked something essential, I will set the VRM link to open for a while https://vrm.victronenergy.com/installation/31525/share/c43e4823

This is a pretty common issue with Daly and some of the other bms. It just doesn't do a good job of calculating SOC. This is why I have a flow in node red to compare the bms SOC with the smart shunt SOC at intervals and when they are out of sync by a few % I use mqtt to set the bms SOC to match the smart shunt. Works great.

mr-manuel commented 1 year ago

@josmeijer check https://github.com/Louisvdw/dbus-serialbattery/discussions/657 For Daly

ogurevich commented 1 year ago

This variant looks like a plan. What will happen if the existing loads (e.g. electric stove or washing machine) are suddenly switched off at this very moment. Does BMS then disconnect the battery due to over voltage protection?

ArendsM commented 1 year ago

I had a similar idea and it should work, but is not that easy to implement. Anyway that would be a great feature!

It has to work with serial and Bluetooth connection. For the Bluetooth connection there is already some code to change settings.

Surpressing the BMS alert is the easiest thing, changing the OVPR and OVP values the trickiest one. Feel free to open a PR for this!

Hi Manuel, I have some working code now to modify the OVP and OVPR registers in jkbms_brn.py. I'll let you know when I've included that functionality triggered by the MAX_VOLTAGE_TIME_SEC timeout. I'll create a PR as soon I feel comfortable with the results ;-)

ArendsM commented 1 year ago

This variant looks like a plan. What will happen if the existing loads (e.g. electric stove or washing machine) are suddenly switched off at this very moment. Does BMS then disconnect the battery due to over voltage protection?

Hi, only the charging MOSFETs will be switched off until OVPR voltage is reached again. Discharging is not affected. High loads during that time might affect the reset to 100% in case the higest battery voltage will drop under OVP to fast. Let's see ...

ogurevich commented 1 year ago

Another control question: What about several batteries connected in parallel? The SOC is updated for one battery, but not for the others. And that first battery is almost always the same.

ArendsM commented 1 year ago

Another control question: What about several batteries connected in parallel? The SOC is updated for one battery, but not for the others. And that first battery is almost always the same.

Hi Oleg, with the new code submitted, all batteries should have their own instance of dbus-serialbattery and the SOC reset should work for all of them when the requirements are met.

ArendsM commented 1 year ago

I had a similar idea and it should work, but is not that easy to implement. Anyway that would be a great feature! It has to work with serial and Bluetooth connection. For the Bluetooth connection there is already some code to change settings. Surpressing the BMS alert is the easiest thing, changing the OVPR and OVP values the trickiest one. Feel free to open a PR for this!

Hi Manuel, I have some working code now to modify the OVP and OVPR registers in jkbms_brn.py. I'll let you know when I've included that functionality triggered by the MAX_VOLTAGE_TIME_SEC timeout. I'll create a PR as soon I feel comfortable with the results ;-)

Hi Manuel, I've created PR #736. Please review my changes. I'm happy to get your feedback.

mr-manuel commented 1 year ago

It seems that the JKBMS over the serial connection is read only. I now spend about 50 hours to search a solution and writing with the developers, but they answer with all other suff other than the answers to my questions...

The only workaround would be to use the Bluetooth connection (which I dont want) or to set the OVPR to the MAX_CELL_VOLTAGE. This resets the SoC at least to 95%.

Otherwise I can add an option to disable high voltage warning and you can set OVP to 3.48 V.

mr-manuel commented 1 year ago

In the meanwhile I added a bulk voltage that is triggered every x days. So you can load the battery up to OVP once a week, month or whatevery you want. Maybe also other BMS can benefit from it.

Please try it and give me a feedback. In the installer select specific version and then insert the URL or the *.tar.gz:

https://github.com/mr-manuel/venus-os_dbus-serialbattery/releases/download/v1.0.20230629beta/venus-data.tar.gz

Here the link to the release: v1.0.20230629beta

jdeus commented 1 year ago

So it was in the end the correct answer. However, the proposed solution is problematic when batteries are in parallel (i.e more than one BMS). This bulk period should be determined by the controller aggregating multiple batteries and not on a per-battery (i.e per-BMS) basis

drago-more commented 1 year ago

The only workaround would be to use the Bluetooth connection (which I dont want) or to set the OVPR to the MAX_CELL_VOLTAGE. This resets the SoC at least to 95%.

@mr-manuel Just fyi. This is not working for the JKBMS 4/8s, FW 11.XW. I just tested it with my two JKBMS'. The SOC is not reset to 95% even if all cells are exceeding OVPR.

mr-manuel commented 1 year ago

The only workaround would be to use the Bluetooth connection (which I dont want) or to set the OVPR to the MAX_CELL_VOLTAGE. This resets the SoC at least to 95%.

@mr-manuel Just fyi. This is not working for the JKBMS 4/8s, FW 11.XW. I just tested it with my two JKBMS'. The SOC is not reset to 95% even if all cells are exceeding OVPR.

I have to say, that I also tried it again and it do not work anymore with the OVPR voltage. If I check the stats I see that sometime it works and sometimes not.

ogurevich commented 1 year ago

to get SOC recalculated try to change OVPR and then change capacity, for example from 280 to 281 it triggers recalculation in JKBMS. (remind to restore changed values) :)

mr-manuel commented 1 year ago

I think when you change the capacity you also loose the history of the battery cycles.

drago-more commented 1 year ago

The only confirmed and repeatable feature in the JKBMS rule set is the reset to 100% when exceeding OVP. Everything else seems to be dependent on FW version and various other factors which we don‘t know for sure.

Dighy commented 1 year ago

Hi all, for me this issue seems to be solved. The last reset of SOC I did about one week ago and since then my SOC is going daily up to 99% even 100% for a while, which is waht I need. I would like to share with you my settings, this may work/help somebody to solve this issue. In BMS, I set the OVP at 3.5V permanently and 3.46V for reseting the SOC. OVPR at 3.4V to avoid alarms and restarting charging at higher cell voltage. In the driver only thing I changed is float voltage reduce from 3.375V to 3.35V (26.8 in my 24V system). It needs patience, from SOC reset until see the result. In my case only after third reset the things were going well. Before, reseting SOC, after 2-3days with 99% SOC, again start decreasing 1-2% daily (more or less). I attached my system overvie, where you can see the battery status. Only one day SOC gone up to 95% due to cloudy weather. System overview one month

System overview

Valdiralita commented 1 year ago

For me hitting OVP resets soc to 100%, currently I get alarms every day for high voltage which are expected. Thats not really desireable because everything freaks out and I get warnings in VRM, the remote console and the app. Would either of these be possible?

mr-manuel commented 1 year ago

It‘s already done. I‘m still testing it. You can download from my repository the dev branch. There you have a bulk voltage, after how many days the bulk voltage should be applied again and a muting of the high voltage alarm in the bulk voltage phase.

joseal commented 1 year ago

@mr-manuel is it only working for the bluetooth connected jk BMSs? Or did you managed to make it work for the rs485 ?

mr-manuel commented 1 year ago

The bulk voltage is working for all BMS that do not support the SoC reset directly. It was merged yesterday into the dev branch so you can install the nightly and select dev.

joseal commented 1 year ago

Thanks @mr-manuel ! I will test it and provide you some feedback.

Valdiralita commented 1 year ago

It‘s already done. I‘m still testing it. You can download from my repository the dev branch. There you have a bulk voltage, after how many days the bulk voltage should be applied again and a muting of the high voltage alarm in the bulk voltage phase.

It was merged yesterday into the dev branch so you can install the nightly and select dev.

Using install.sh it installed 1.0.20230711dev today (option nightly -> dev) and set BULK_CELL_VOLTAGE = 3.610 and still getting high voltage alerts at 57.65V (16S). With the version number im not sure if its the wrong version or wrong settings.

mr-manuel commented 1 year ago

@Valdiralita what do you see in the parameter page in the remote console/GUI -> SerialBattery -> Parameters? Please post a screenshot. What is your max cell voltage and to which values did you set OVP and OVPR in the JKBMS app.

Valdiralita commented 1 year ago

@Valdiralita what do you see in the parameter page in the remote console/GUI -> SerialBattery -> Parameters? Please post a screenshot. What is your max cell voltage and to which values did you set OVP and OVPR in the JKBMS app.

grafik

MIN_CELL_VOLTAGE = 2.750 MAX_CELL_VOLTAGE = 3.600 FLOAT_CELL_VOLTAGE = 3.375 BULK_CELL_VOLTAGE = 3.610

The JKBMS has 3.6V OVP and 3.55V OVPR.

mr-manuel commented 1 year ago

Max cell voltage and OVP should not be the same. Therefore you have the warning.

Set max voltage to 3.45 and try bulk voltage to 3.56. If it‘s not resetting to 100% SoC try to increase bulk voltage by 0.01 per test.

Valdiralita commented 1 year ago

Max cell voltage and OVP should not be the same. Therefore you have the warning.

Set max voltage to 3.45 and try bulk voltage to 3.56. If it‘s not resetting to 100% SoC try to increase bulk voltage by 0.01 per test.

I thought I need to exceed the OVP in the jkbms for it to set soc to 100%, which means the bulk voltage should be higher than the OVP? 3.45 is also my balancing start voltage.

EDIT: with max voltage of 3.45 and bulk at 3.56v it wont charge and the battery stays at 55.2v and im getting high voltage alarms in VRM but not in the remote console.

mr-manuel commented 1 year ago

If you have OVP set to 3.60 you won‘t be able to go higher. One cell has to reach OVP to set SoC to 100%. Therefore you can set bulk voltage a bit lower because of cell voltage difference.

joseal commented 1 year ago

I'm doing something wrong for sure, but with this Dev build and the bellow settings, I'm stuck in Absorption (Linear Mode) all the time (I don't see bulk anymore, even when bellow 40%) and SoC is not occuring...

image

My current settings:

MAX_BATTERY_CHARGE_CURRENT = 60.0
MAX_BATTERY_DISCHARGE_CURRENT = 80.0

BULK_CELL_VOLTAGE  = 3.56

AUTO_RESET_SOC = True
JK_BMS_AUTO_RESET_SOC = True

Screenshot_20230718_111358_BMS

mr-manuel commented 1 year ago

Please read the config.default.ini again.

https://github.com/Louisvdw/dbus-serialbattery/blob/a24d6ef458239a1bc70399f774ae71348e48bf9d/etc/dbus-serialbattery/config.default.ini#L16-L28

joseal commented 1 year ago

Please read the config.default.ini again.

https://github.com/Louisvdw/dbus-serialbattery/blob/a24d6ef458239a1bc70399f774ae71348e48bf9d/etc/dbus-serialbattery/config.default.ini#L16-L28

Got it... thank you! Testing...

image

joseal commented 1 year ago

Reached the 56.96v (BULK_CELL_VOLTAGE x 16) and moved to Float, but no SoC reset:

image

BMS_TYPE = Jkbms

MAX_BATTERY_CHARGE_CURRENT = 60.0
MAX_BATTERY_DISCHARGE_CURRENT = 80.0

MIN_CELL_VOLTAGE   = 2.900
MAX_CELL_VOLTAGE   = 3.450
FLOAT_CELL_VOLTAGE = 3.375
BULK_CELL_VOLTAGE  = 3.56
BULK_AFTER_DAYS = 1

AUTO_RESET_SOC = True
JK_BMS_AUTO_RESET_SOC = True

Doubt: do we need AUTO_RESET_SOC and JK_BMS_AUTO_RESET_SOC?

mr-manuel commented 1 year ago

Reached the 56.96v (BULK_CELL_VOLTAGE x 16) and moved to Float, but no SoC reset:

Just read again https://github.com/Louisvdw/dbus-serialbattery/issues/703#issuecomment-1636759210

Doubt: do we need AUTO_RESET_SOC and JK_BMS_AUTO_RESET_SOC?

No, where does JK_BMS_AUTO_RESET_SOC come from?