JKBMS BLE - Loss of connection after an indefinite period of time

Describe the bug

I’m facing sporadic disconnect issues after a while (sometimes one hour, sometimes a day or a bit more). Venus OS doesn’t recognize the disconnect as values don’t get updated. After a while the messages in the log changes. I have spent hours searching through reported issue reports, but have not found any identical, unfixed or reported bugs.

How to reproduce

Issue is reproducible, but periodes vary. Sometimes the connection works for more than 24 hours, in other cases only for minutes or hours.

Expected behavior

Stable connection

Driver version

1.2.20240401

Venus OS device type

Raspberry Pi 4

Venus OS version

v3.33

BMS type

JKBMS / Heltec BMS

Cell count

Battery count

Connection type

Bluetooth

Config file

[DEFAULT]

; --------- Set logging level ---------
; ERROR: Only errors are logged
; WARNING: Errors and warnings are logged
; INFO: Errors, warnings and info messages are logged
; DEBUG: Errors, warnings, info and debug messages are logged
LOGGING = INFO

; --------- Battery Current limits ---------
MAX_BATTERY_CHARGE_CURRENT    = 50.0
MAX_BATTERY_DISCHARGE_CURRENT = 60.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 voltage (can be seen as resting voltage)
FLOAT_CELL_VOLTAGE = 3.375

; --------- SOC reset voltage ---------
; Description:
;     May be needed to reset the SoC to 100% once in a while for some BMS, because of SoC drift.
;     Specify the cell voltage where the SoC should be reset to 100% by the BMS.
;       - JKBMS: SoC is reset to 100% if one cell reaches OVP (over voltage protection) voltage
;     As you have to adopt this value to your system, I reccomend to start with
;     OVP voltage - 0.030 (see Example).
;       - Try to increase (add) by 0.005 in steps, if the system does not switch to float mode, even if
;         the target voltage SOC_RESET_VOLTAGE * CELL_COUNT is reached.
;       - Try to decrease (lower) by 0.005 in steps, if the system hits the OVP too fast, before all
;         cells could be balanced and the system goes into protection mode multiple times.
; Example:
;     If OVP is 3.650, then start with 3.620 and increase/decrease by 0.005
; Note:
;     The value has to be higher as the MAX_CELL_VOLTAGE
;     You also have to set CELL_VOLTAGES_WHILE_CHARGING accordingly, if you set CCCM_CV_ENABLE to true
;         else the charging current will be reduced to 0 before the target voltage is reached and the
;         battery will never switch to float
SOC_RESET_VOLTAGE = 3.650
; Specify after how many days the soc reset voltage should be reached again
; The timer is reset when the soc reset voltage is reached
; Leave empty if you don't want to use this
; Example:
;     Value is set to 15
;     day 1: soc reset reached once
;     day 16: soc reset reached twice
;     day 31: soc reset not reached since it's very cloudy
;     day 34: soc reset reached since the sun came out
;     day 49: soc reset reached again, since last time it took 3 days to reach soc reset voltage
SOC_RESET_AFTER_DAYS =

; --------- Bluetooth BMS ---------
; Description:
;     Specify the Bluetooth BMS and it's MAC address that you want to install. Leave emty to disable
; Available Bluetooth BMS:
;     Jkbms_Ble, LltJbd_Ble
; Example for one BMS:
;     BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:00:00:00
; Example for multiple BMS:
;     BLUETOOTH_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 = Jkbms_Ble C8:47:8C:EC:BA:6F

; --------- Bluetooth use USB ---------
; Description:  Some users reported issues to the built in bluetooth module, you can try to fix it with an USB
;     module. After a change you have to run reinstall-local.sh and to manual reboot the device!
;     The usb bluetooth module must have BLE support (bluetooth version >= 4.0)
;     Other bluetooth devices such as Ruuvi tags not tested yet.
; False: Use the built in bluetooth module
; True: Disable built in bluetooth module and try to use USB module
BLUETOOTH_USE_USB = False

; --------- CAN BMS ---------
; Description:
;     Specify the CAN port(s) where the BMS is connected to. Leave empty to disable
; Available CAN BMS:
;     Daly_Can, Jkbms_Can
; Example for one CAN port:
;     CAN_PORT = can0
; Example for multiple CAN ports:
;     CAN_PORT = can0, can8, can9
CAN_PORT =

; --------- 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 for 20 minutes, if cell voltages are between
;     3.25 V and 3.35 V. Else the driver block charge and discharge after 60 seconds.
; True:
;     Charge and discharge is blocked on BMS communication loss, it's unblocked when connection is established
;     again or the driver/system is restarted. This is the Victron Energy default behaviour.
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 MAX_VOLTAGE_TIME_SEC
;             additional seconds.
;             After cell voltage difference is greater or equal to CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT
;             OR
;             SoC is below SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT
;             it switches back to max voltage.
; Example when set to True:
;     Step mode:
;          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 80%
;     Linear mode:
;          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 900 additional seconds to don't stress the batteries. Allow max voltage of
;          55.2V again if max cell difference is above 0.080V or SoC below 80%.
; 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 MAX_VOLTAGE_TIME_SEC restarts if diff is bigger
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_TIME_RESTART = 0.013
; 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 & linear mode)
; Specify how long the max voltage should be kept
;     Step mode: If reached then switch to float voltage
;     Linear mode: If cells are balanced keep max voltage for further MAX_VOLTAGE_TIME_SEC seconds
MAX_VOLTAGE_TIME_SEC = 900
; Specify SoC where CVL limit is reset to max voltage
;     Step mode: If SoC gets below
;     Linear mode: If cells are unbalanced or if SoC gets below
SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT = 80

; --------- SOC calculation ---------
; Description:
;     Calculate the SOC in the driver. Do not use the SOC reported by the BMS
; SOC_CALCULATION:
;     True: Calc SOC in the driver, do not use SOC reported from BMS
;         - The SOC is calculated by integration of the current reported by the BMS
;         - The current reported from the BMS can be corrected by
;           the map (SOC_CALC_CURRENT_REPORTED_BY_BMS, SOC_CALC_CURRENT_MEASURED_BY_USER)
;         - The SOC is set to 100% if the following conditions apply for at least SOC_RESET_TIME seconds:
;             * Current is lower than SOC_RESET_CURRENT amps
;             * Sum of cell voltages >= self.max_battery_voltage - VOLTAGE_DROP
;         - The calculated SOC is stored in dbus to persist a driver restart
;     False: Use SOC reported from BMS (none of the other parameters apply)
; More info: https://github.com/Louisvdw/dbus-serialbattery/pull/868
SOC_CALCULATION   = False
SOC_RESET_CURRENT = 7
SOC_RESET_TIME    = 60
SOC_CALC_CURRENT_REPORTED_BY_BMS  = -300, 300
SOC_CALC_CURRENT_MEASURED_BY_USER = -300, 300
; Example to set small currents to zero
;     SOC_CALC_CURRENT_REPORTED_BY_BMS  = -300, -0.5, 0.5, 300
;     SOC_CALC_CURRENT_MEASURED_BY_USER = -300,    0,   0, 300

; --------- 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

; --------- Cell Voltage limitation (affecting CVL) ---------
; This function prevents a bad balanced battery to overcharge the cell with the highest voltage and the bms to
; switch off because of overvoltage of this cell.
;
; Example:
;     15 cells are at 3.4v, 1 cell is at 3.6v. Total voltage of battery is 54.6v and the Victron System sees no reason to
;     lower the charging current as the control_voltage (Absorbtion Voltage) ist 55.2v
;     In this case the Cell Voltage limitation kicks in and lowers the control_voltage to keep it close to the MAX_CELL_VOLTAGE.
;
; In theory this can also be done with CCL, but doing it with CVL has 2 advantages:
;     - In a well balanced system the current can be kept quite high till the end of charge by using MAX_CELL_VOLTAGE for charging.
;     - In systems with MPPTs and DC-feed-in activated the victron systems do not respect CCL, so CVL is the only way to prevent the
;       highest cell in a bad balanced system from overcharging.
;
; There are 2 methods implemented to calculate CVL:
;   1. penalty_sum-Method (CVL_ICONTROLLER_MODE = False)
;      The voltage-overshoot of all cells that exceed MAX_CELL_VOLTAGE is summed up and the control voltage is lowered by this "penalty_sum".
;      This is calculated every LINEAR_RECALCULATION_EVERY seconds.
;      In fact, this is a P-Controller.
;   2. I-Controller (CVL_ICONTROLLER_MODE = True)
;      An I-Controller tries to control the voltage of the highest cell to MAX_CELL_VOLTAGE + CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL.
;      (for example 3.45V+0.01V =3.46V). If the voltage of the highest cell is above this level, CVL is reduced. If the voltage is below, CVL is
;      increased until cellcount*MAX_CELL_VOLTAGE.
;      An I-Part of 0.2 V/Vs (CVL_ICONTROLLER_FACTOR) has proved to be a stable and fast controlling-behaviour.
;      This method is not as fast as the penalty_sum-Method but usually smoother and more stable against toggeling and has no stationary deviation.
; More info: https://github.com/Louisvdw/dbus-serialbattery/pull/882
CVL_ICONTROLLER_MODE   = False
CVL_ICONTROLLER_FACTOR = 0.2

; --------- 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
TEMPERATURES_WHILE_CHARGING      =    0,    2,    5,   10,   15,   20,   35,   40,   55
MAX_CHARGE_CURRENT_T_FRACTION    = 0.00, 0.10, 0.20, 0.40, 0.80, 1.00, 1.00, 0.40, 0.00

TEMPERATURES_WHILE_DISCHARGING   =  -20,    0,    5,   10,   15,   45,   55
MAX_DISCHARGE_CURRENT_T_FRACTION = 0.00, 0.20, 0.30, 0.40, 1.00, 1.00, 0.00

; --------- SOC limitation (affecting CCL/DCL) ---------
; Description:
;     Maximal charge / discharge current will be increased / decreased depending on State of Charge
;     Since the SoC is not as accurate as the cell voltage, this option is disabled by default
; Example:
;     The SoC limit will be monitored to control the currents.
; Charge current control management enable (True/False).
CCCM_SOC_ENABLE = False
; Discharge current control management enable (True/False).
DCCM_SOC_ENABLE = False

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
SOC_WHILE_CHARGING                 =   98,   95,   90,   85
MAX_CHARGE_CURRENT_SOC_FRACTION    = 0.10, 0.20, 0.50, 1.00

SOC_WHILE_DISCHARGING              =    5,   10,   15,   20
MAX_DISCHARGE_CURRENT_SOC_FRACTION = 0.10, 0.20, 0.50, 1.00

; --------- 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 one or more BMS types to load else leave empty to try to load all available
; Available BMS:
;     Daly, Ecs, HeltecModbus, HLPdataBMS4S, Jkbms, Lifepower, LltJbd, Renogy, Seplos
; Available BMS, but disabled by default (just enter one or more below and it will be enabled):
;     ANT, MNB, Sinowealth
BMS_TYPE = Jkbms

; Exclute this serial devices from the driver startup
; Example:
;     /dev/ttyUSB2, /dev/ttyUSB4
EXCLUDED_DEVICES =

; Auto reset SoC
; If on, then SoC is reset to 100%, if the value switches from absorption to float voltage
; Currently only working for Daly BMS and JKBMS BLE
AUTO_RESET_SOC = True

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

; 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
; Specify how the battery temperature is assembled
; 0 Get mean of temperature sensor 1 to sensor 4
; 1 Get only temperature from temperature sensor 1
; 2 Get only temperature from temperature sensor 2
; 3 Get only temperature from temperature sensor 3
; 4 Get only temperature from temperature sensor 4
TEMP_BATTERY = 0

; Temperature sensor 1 name
TEMP_1_NAME = Temp 1

; Temperature sensor 2 name
TEMP_2_NAME = Temp 2

; Temperature sensor 2 name
TEMP_3_NAME = Temp 3

; Temperature sensor 2 name
TEMP_4_NAME = Temp 4

; --------- 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

; -- JKBMS settings
; Predefines cell count for Jkbms_can
; The cell count should be auto-detected by identifying the highest cell number,
; but this process may be sometimes slow what could cause that cells voltage is not not
; updated in VenusOS. Try this workaround if you experience problems with cell voltage.
JKBMS_CAN_CELL_COUNT = 1

; -- ESC GreenMeter and Lipro device settings
GREENMETER_ADDRESS  = 1
LIPRO_START_ADDRESS = 2
LIPRO_END_ADDRESS   = 4
LIPRO_CELL_COUNT    = 15

; -- HeltecModbus (Heltec SmartBMS/YYBMS) settings
; Set the Modbus addresses from the adapters
; Separate each address to check by a comma like: 1, 2, 3, ...
; factory default address will be 1
HELTEC_MODBUS_ADDR = 1

; --------- Voltage drop ---------
; If you have a voltage drop between the BMS and the charger because of wire size or length
; then you can specify the voltage drop here. The driver will then add the voltage drop
; to the calculated CVL to compensate.
; Example:
;     cell count: 16
;     MAX_CELL_VOLTAGE = 3.45
;     max voltage calculated = 16 * 3.45 = 55.20
;     CVL is set to 55.20 V and the battery is now charged until the charger reaches 55.20 V.
;     The BMS now measures 55.05 V since there is a voltage drop of 0.15 V on the cable.
;     Since the dbus-serialbattery reads the voltage of 55.05 V from the BMS the max voltage
;     of 55.20 V is never reached and max voltage is kept forever.
;     By setting the VOLTAGE_DROP to 0.15 V the voltage on the charger is increased and the
;     target voltage on the BMS is reached.
VOLTAGE_DROP = 0.00

Relevant log output

2024-07-03 17:59:57.390883500 Starting bluetooth: bluetoothd.
2024-07-03 17:59:57.410705500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:00.434951500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:00.435308500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:00.439681500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 18:00:02.530767500 Starting bluetooth: bluetoothd.
2024-07-03 18:00:02.548911500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:05.594779500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:05.595115500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:05.599339500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 18:00:07.695595500 Starting bluetooth: bluetoothd.
2024-07-03 18:00:07.714199500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:10.524920500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:10.525304500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:10.529827500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 18:00:12.618931500 Starting bluetooth: bluetoothd.
2024-07-03 18:00:12.642386500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:15.875032500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:15.875624500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:15.880277500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 18:00:17.970953500 Starting bluetooth: bluetoothd.
2024-07-03 18:00:17.989252500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:20.935017500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:20.935435500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:20.938751500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 18:00:23.029540500 Starting bluetooth: bluetoothd.
2024-07-03 18:00:23.048084500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 18:00:26.355002500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 18:00:26.355763500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 18:00:26.359645500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
....

After one or two hours

...
2024-07-03 21:20:38.352398500 Starting bluetooth: bluetoothd.
2024-07-03 21:20:38.370592500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 21:20:40.381504500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.freedesktop.DBus.Error.AccessDenied', 'Client tried to send a message other than Hello without being registered') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 21:20:40.382059500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 21:20:40.384293500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 21:20:42.476923500 Starting bluetooth: bluetoothd.
2024-07-03 21:20:42.495511500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 21:20:44.506431500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.freedesktop.DBus.Error.AccessDenied', 'Client tried to send a message other than Hello without being registered') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 21:20:44.506748500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 21:20:44.508822500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 21:20:46.601465500 Starting bluetooth: bluetoothd.
2024-07-03 21:20:46.619614500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 21:20:48.630256500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.freedesktop.DBus.Error.AccessDenied', 'Client tried to send a message other than Hello without being registered') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 21:20:48.630547500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 21:20:48.632829500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 21:20:50.723933500 Starting bluetooth: bluetoothd.
2024-07-03 21:20:50.742399500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-07-03 21:20:52.753393500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.freedesktop.DBus.Error.AccessDenied', 'Client tried to send a message other than Hello without being registered') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-07-03 21:20:52.753708500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-07-03 21:20:52.755984500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-07-03 21:20:54.850113500 Starting bluetooth: bluetoothd.

Any other information that may be helpful

This behavior was already apparent immediately after initial operation. It is reproducible, but periodes vary. Sometimes the connection works for more than 24 hours, in other cases only for minutes or hours.

After a reboot without successful reconnection, the log shows the following.

2024-07-03 21:54:49.437041500 2024-07-03 21:54:50.191633500 INFO:SerialBattery: 2024-07-03 21:54:50.192071500 INFO:SerialBattery:Starting dbus-serialbattery 2024-07-03 21:54:50.193135500 INFO:SerialBattery:Venus OS v3.33 2024-07-03 21:54:50.193590500 INFO:SerialBattery:dbus-serialbattery v1.2.20240401 2024-07-03 21:55:06.468249500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EC:BA:6F 2024-07-03 21:55:06.468532500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EC:BA:6F 2024-07-03 21:55:17.097821500 INFO:SerialBattery:--> asy_connect_and_scrape(): device not found: C8:47:8C:EC:BA:6F 2024-07-03 21:55:17.098157500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 21:55:17.185993500 ERROR:SerialBattery:No BMS found at C8:47:8C:EC:BA:6F 2024-07-03 21:55:17.186304500 ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble 2024-07-03 21:55:17.376305500 [CHG] Device C8:47:8C:EC:BA:6F RSSI: -57 2024-07-03 21:55:17.376572500 2024-07-03 21:55:17.376633500 INFO:Bluetooth details 2024-07-03 21:55:17.408004500 Attempting to disconnect from C8:47:8C:EC:BA:6F 2024-07-03 21:55:17.408009500 Successful disconnected 2024-07-03 21:55:22.449397500 Device C8:47:8C:EC:BA:6F (public) 2024-07-03 21:55:22.449402500 Alias: JK_B2A24S15P 2024-07-03 21:55:22.449404500 Paired: no 2024-07-03 21:55:22.449407500 Trusted: no 2024-07-03 21:55:22.449409500 Blocked: no 2024-07-03 21:55:22.449411500 Connected: no 2024-07-03 21:55:22.449413500 LegacyPairing: no 2024-07-03 21:55:22.449415500 UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) 2024-07-03 21:55:22.449419500 RSSI: -55 2024-07-03 21:55:22.451376500 2024-07-03 21:55:23.155704500 INFO:SerialBattery: 2024-07-03 21:55:23.155975500 INFO:SerialBattery:Starting dbus-serialbattery 2024-07-03 21:55:23.156872500 INFO:SerialBattery:Venus OS v3.33 2024-07-03 21:55:23.157143500 INFO:SerialBattery:dbus-serialbattery v1.2.20240401 2024-07-03 21:55:39.424715500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EC:BA:6F 2024-07-03 21:55:39.425001500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EC:BA:6F 2024-07-03 21:55:40.626482500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474 2024-07-03 21:55:40.627076500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 21:55:40.630664500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 21:55:40.746956500 [CHG] Device C8:47:8C:EC:BA:6F RSSI: -55 2024-07-03 21:55:40.746961500 [CHG] Device C8:47:8C:EC:BA:6F RSSI: -55 2024-07-03 21:55:40.746965500 [CHG] Device C8:47:8C:EC:BA:6F RSSI is nil 2024-07-03 21:55:42.722294500 Starting bluetooth: bluetoothd. 2024-07-03 21:55:42.744304500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 21:55:55.095326500 INFO:SerialBattery:--> asy_connect_and_scrape(): device not found: C8:47:8C:EC:BA:6F 2024-07-03 21:55:55.095638500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 21:55:55.153250500 ERROR:SerialBattery:No BMS found at C8:47:8C:EC:BA:6F 2024-07-03 21:55:55.153646500 ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble ...

Additional information - Jkbms: Hardware Ver.: V11.XW Software Ver.: V11.26

After several reboots a I was able to restore a connection. Periodical a reconnect-beep each roughly minute accorse.

Log:

2024-07-03 22:22:30.084866500 [CHG] Device C8:47:8C:EC:BA:6F RSSI: -77 2024-07-03 22:22:30.084874500 [CHG] Device C8:47:8C:EC:BA:6F RSSI: -78 2024-07-03 22:22:30.084879500 [CHG] Device C8:47:8C:EC:BA:6F RSSI is nil 2024-07-03 22:22:32.023222500 Starting bluetooth: bluetoothd. 2024-07-03 22:22:32.046447500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:23:42.869651500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:23:42.872635500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:23:44.969469500 Starting bluetooth: bluetoothd. 2024-07-03 22:23:44.991916500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:24:55.866244500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:24:55.868883500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:24:57.961846500 Starting bluetooth: bluetoothd. 2024-07-03 22:24:57.980363500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:26:02.896132500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:26:02.898873500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:26:04.992019500 Starting bluetooth: bluetoothd. 2024-07-03 22:26:05.010720500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:27:09.902714500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:27:09.904826500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:27:11.997207500 Starting bluetooth: bluetoothd. 2024-07-03 22:27:12.015723500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:28:16.897239500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:28:16.899233500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:28:18.990674500 Starting bluetooth: bluetoothd. 2024-07-03 22:28:19.009483500 INFO:SerialBattery:System Bluetooth daemon should have been restarted 2024-07-03 22:29:23.907271500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit 2024-07-03 22:29:23.909872500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered 2024-07-03 22:29:26.004568500 Starting bluetooth: bluetoothd. 2024-07-03 22:29:26.025009500 INFO:SerialBattery:System Bluetooth daemon should have been restarted

I have the same issue. I turned off the bluetooth in the Venus GX device (serial battery turns it on itself) so it worked better. However, it still hung from time to time. The solution for me so far is to switch off NodeRed. I don't understand why and how NodeRed has an influence, CPU load is good, temperature too and I only have a few nodes for displaying voltage and current or for day/night adjustment of the feed.

What kind of system do I have? Three battery blocks (16S 280Ah) each with a JKB2A20S20P, connected via Bluetooth, three Multiplus 3000 and three MPPT charge controllers.

With NodeRed switched off, it runs quite stable, regulates and limits the voltages perfectly to a maximum of 3.45V, then drops to 3.35V. So far so good. But what is still a problem are the many cell imbalance warnings, even though there is no load and a real maximum difference of 5mV.

Unfortunately my knowledge of Bluetooth connections is very limited and I'm not able to solve and troubleshoot this problem. Any help is very welcome!

I'm having a similar problem. First thing I tried to do is run the /etc/init.d/bluetooth restart script to restart bluetoothd, but this doesn't seem to work.

I just started having this problem. I used to lose connection every couple weeks, and a restart of the Cerbo would solve it. This morning, it has happened three times already. A restart solves it for a bit.

I am using Large OS. Updating now to 3.41 to see if that helps. Next step is to try a bluetooth dongle instead of built-in bluetooth.

I just started having this problem. I used to lose connection every couple weeks, and a restart of the Cerbo would solve it. This morning, it has happened three times already. A restart solves it for a bit.

I am using Large OS. Updating now to 3.41 to see if that helps. Next step is to try a bluetooth dongle instead of built-in bluetooth.

I also started having connection disrupts. I believe it was with updating to 3.41. I try to go back to 3.40. Could you find any solutions? I need to power cycle the cerbo gx every day. Sometimes if I can still reach it, it says no battery manager found. It was running more or less stable before. I also suspect some shelly dms or mqtt connection problem to have an influence as the problem increased since my home assistant instance with a mqtt broker stopped working because of an update.

I dont really know how to trouble shoot as i can barely reach the device.

I've got the same Problem, but I belive the BMS is the problem. What makes me think of that? Even rebooting or disconnect the Raspberry PI3b from the power source doesn't help. But if I press the button on the BMS for 5 seconds, the dbus serialbattery is able to connect automatically.

I'll check if there is a firmware update for the BMS.

This is the endless loop tring to reconnect:

2024-10-01 15:58:47.650939500 INFO:SerialBattery:
2024-10-01 15:58:47.651412500 INFO:SerialBattery:Starting dbus-serialbattery
2024-10-01 15:58:47.652900500 INFO:SerialBattery:Venus OS v3.42
2024-10-01 15:58:47.653332500 INFO:SerialBattery:dbus-serialbattery v1.4.20240928
2024-10-01 15:59:03.999950500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:80:03:B1:8D
2024-10-01 15:59:04.000444500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:80:03:B1:8D
2024-10-01 15:59:05.920678500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-10-01 15:59:05.921429500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-10-01 15:59:05.927431500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-10-01 15:59:06.019008500 [CHG] Device C8:47:80:03:B1:8D RSSI: -57
2024-10-01 15:59:06.019016500 [CHG] Device C8:47:80:03:B1:8D RSSI: -57
2024-10-01 15:59:06.019020500 [CHG] Device C8:47:80:03:B1:8D RSSI is nil
2024-10-01 15:59:08.037842500 Starting bluetooth: bluetoothd.
2024-10-01 15:59:08.071667500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-10-01 15:59:11.260295500 INFO:SerialBattery:--> asy_connect_and_scrape(): error while connecting to bt: BleakDBusError('org.bluez.Error.Failed', 'Software caused connection abort') of type <class 'bleak.exc.BleakDBusError'> in /opt/victronenergy/dbus-serialbattery/bms/jkbms_brn.py line #474
2024-10-01 15:59:11.260792500 INFO:SerialBattery:--> asy_connect_and_scrape(): Exit
2024-10-01 15:59:11.265866500 INFO:SerialBattery:Reset of system Bluetooth daemon triggered
2024-10-01 15:59:13.364495500 Starting bluetooth: bluetoothd.
2024-10-01 15:59:13.385058500 INFO:SerialBattery:System Bluetooth daemon should have been restarted
2024-10-01 15:59:13.513742500 ERROR:SerialBattery:No BMS found at C8:47:80:03:B1:8D
2024-10-01 15:59:13.516017500 ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble
2024-10-01 15:59:15.811012500
2024-10-01 15:59:15.811211500
2024-10-01 15:59:15.811438500 INFO:Preparing Bluetooth for connection to BMS
2024-10-01 15:59:15.811625500 INFO:Bluetooth details
2024-10-01 15:59:15.849032500 Attempting to disconnect from C8:47:80:03:B1:8D
2024-10-01 15:59:15.849039500 Successful disconnected
2024-10-01 15:59:20.901560500 Device C8:47:80:03:B1:8D (public)
2024-10-01 15:59:20.901566500   Alias: A2H
2024-10-01 15:59:20.901567500   Paired: no
2024-10-01 15:59:20.901569500   Trusted: no
2024-10-01 15:59:20.901571500   Blocked: no
2024-10-01 15:59:20.901573500   Connected: no
2024-10-01 15:59:20.901574500   LegacyPairing: no
2024-10-01 15:59:20.901576500   UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
2024-10-01 15:59:20.901581500   RSSI: -57
2024-10-01 15:59:20.903545500
2024-10-01 15:59:23.989540500 INFO:SerialBattery:
2024-10-01 15:59:23.989979500 INFO:SerialBattery:Starting dbus-serialbattery
2024-10-01 15:59:23.991427500 INFO:SerialBattery:Venus OS v3.42
2024-10-01 15:59:23.991874500 INFO:SerialBattery:dbus-serialbattery v1.4.20240928

I troubleshooted the Bluetooth problems now way over 100 hours and found no real solution to all this problems. Therefore I decided to not put any other effort into the Bluetooth part. Another reason is, that the users apparently do not appreciate the work I do and they cannot immagine how much time consuming this all is.

For that 1-2 donations, if at all, a month on over 9.000 dbus-serialbattery installations it is not worth it. If everyone would donate 1 €/year then the motivation would be another, but that is not the case.

Feel free to open a PR in my repository to help me with this :-)

So, I have this script running as a cron job every 5 minutes. The bluetooth connection has been pretty dang stable since adding this script. I wonder if this check can somehow be written into the driver. I don't really have time to dig through the code and submit a PR. However, I'd be happy to submit a PR with this script and a short addition to the docs describing in what scenarios to use the script.

#/usr/bin/bash

date -d @$(($(date +%s) - 7*3600)) '+[%Y-%m-%d %H:%M:%S]'
/etc/init.d/bluetooth status
if [ $? -eq 3 ]; then
        /data/etc/dbus-serialbattery/restart-driver.sh
        echo "dbus-serial battery restarted"
fi

We already had once a workaround like this. Since this is not really a real solution I will not add it, since restarting the driver too many times can cause even more issues and you need to reboot the device.

This looks more like a kernel / bluetooth driver issue. I've just dumped the onboard bluetooth controller for a USB one and it seems to be far more stable. The internet has plenty of similar scenarios where the connection just randomly drops.
I note that in my case, I see all the logs above. Running bluetoothctl command and trying anything results in "org.bluez.Error.NotReady" and any attempt to recover it appears futile. I just have to reboot... I installed a realtek usb bluetooth dongle, blacklisted the driver module for the onboard Bluetooth and enabled BLUETOOTH_USE_USB = True in the config.ini file

This might be a "hurry up and wait" for improvement on the support for it on a kernel level. I've found with my raspberry pi 4, connecting via bluetooth to be impossible - its flakey as hell. I could only connect via network cable and do the config there.

@mr-manuel I feel your pain. I worked on a project for years and received very little reward for it. For what its worth, I appreciate your efforts on this project. Thankyou.

Has anyone tried changing the Bluetooth Poll rate? I updated my serialbattery today to the current stable version, was running one a couple months old, and it went from disconnect every couple days to not staying connected for even an hour.

I tried polling at every 1.2 seconds, but it made no tangible difference - at least not using the onboard RPI Bluetooth. I have 2 of these setups One on a Cerbo and one on a Raspberry Pi 4 both with JKBMS 11.X BMS x 2. I note now that both setups seem to run pretty similarly now since I stopped using the RPI onboard Bluetooth. I also recently updated from an older version too. I don't believe this newer version is any less stable than the old one I updated from, but I never saw a dropout on the older version where I have seen it on the odd occasion now. I get the occasional dropout for a minute or so (on both setups) before it comes good. I might try a few different Bluetooth dongles to see if one is better than another. But the jury is in for me - at least for now - I wouldn't stake my life on using the onboard Bluetooth on this raspberry Pi 4 that I am using right now. It's one of a few that I own, and it caused issues from the day I bought it for use as a Victron clone....

I tried polling at every 1.2 seconds, but it made no tangible differenc

How did you change the polling interval? I set 10s as the Poll_Interval in the config.ini but I can still see updates roughly every second in the remote console. Did I miss something or is that parameter broken?

I did the same as you. Even without a setting there (should default to 1 second), I see updates better than a second. After looking at the code, there is a "use_callback" function ->

 def use_callback(self, callback: Callable) -> bool:
        """
        Each driver may override this function to indicate whether it is
        able to provide value updates on its own.

        :return: false when battery cannot provide updates by itself and will be polled
                 every poll_interval milliseconds for new values
                 true if callable should be used for updates as they arrive from the battery
        """
        return False

I've not spent a lot of time in the code yet, but I'd suggest that POLLING only works where/when the BMS doesn't provide updates...

This is called in dbus-serialbattery.py by

# try using active callback on this battery
    if not battery.use_callback(lambda: poll_battery(mainloop)):
        # if not possible, poll the battery every poll_interval milliseconds
        gobject.timeout_add(battery.poll_interval, lambda: poll_battery(mainloop))

    # print log at this point, else not all data is correctly populated
    battery.log_settings()

So I think, it's pointless to try setting a polling time. I still don't think the issue is anything to do with the code.

I got regular reconnection that i never had before (BMS beeping at each BTooth reconnection), today i tried updating VenusOS from 3.3 to 3.42 .. it failed .. rebooted ... tried again .. failed at 4% install each time. I suspected dbus-serialbattery, disabled it, reboot... upgraded to VenusOS 3.42 without problem. Somethig is wrong with the driver.

I downgraded to v1.1.20240121 ~7 hours ago and both BMS's still show a connection, without reboot. This is not exactly a long term observation, but right now I suspect the behavior got worse from v1.1 to v1.4. Misconfiguration? (the config file changed) Or did the polling/timing behavior change?

For me v1.1 has a more stable connection to the BMS. I also didn't hear the reconnect beep from the BMS when near the battery (which is seldom). Comparing v1.1 to the later releases, I noticed Line 23 changed in the init function in jkbms_ble.py: From self.jk = Jkbms_Brn(address) To self.jk = Jkbms_Brn(address, lambda: self.reset_bluetooth())

Didn't look any further into it, but maybe the bluetooth reset is causing issues / called too often.

Here is the whole function a little more down.

def reset_bluetooth(self):
        logger.info("Reset of system Bluetooth daemon triggered")
        self.resetting = True
        if self.jk.is_running():
            if self.jk.stop_scraping():
                logger.info("Scraping stopped, issuing sys-commands")
            else:
                logger.warning("Scraping was unable to stop, issuing sys-commands")

        # process kill is needed, since the service/bluetooth driver is probably freezed
        os.system('pkill -f "bluetoothd"')
        # stop will not work, if service/bluetooth driver is stuck
        # os.system("/etc/init.d/bluetooth stop")
        sleep(2)
        os.system("rfkill block bluetooth")
        os.system("rfkill unblock bluetooth")
        os.system("/etc/init.d/bluetooth start")
        logger.info("System Bluetooth daemon should have been restarted")

It is called as part of refresh_data too

if not self.resetting and last_update >= 60:
                logger.error(
                    "Jkbms_Ble: Bluetooth died. Restarting Bluetooth system driver."
                )
                self.reset_bluetooth()
                sleep(2)
                self.jk.start_scraping()
                sleep(2)

The underlying issues seems to be a segmentation fault that occurs. I saw it last week before I went off to work. Only got back last night so haven't had time to troubleshoot it more. It's fair to say that when the driver falls over, this function doesn't always (or perhaps never) successfully restart the driver properly.

will try to look into it this week.

I've rolled back to v1.2.20240408 and pretty stable for the day. Will keep running for the few days and report back. I had to roll back on the Pi and the Cerbo as both fell over in the end on a later version. Hopefully can get to a point where I can understand the difference between the latest version and this working version to see what is causing the dropouts.

etooth driver issue. I've just dumped the onboard bluetooth controller for a USB one and it seems to be far more stable. The internet has plenty of similar scenarios where the connection just randomly drops. I note that in my case, I see all the logs above. Running bluetoothctl command and trying anything results in "org.bluez.Error.NotReady" and any attempt to recover it appears futile. I just have to reboot... I installed a realtek usb bluetooth dongle, blacklisted the driver module for the onboard Bluetooth and enabled BLUETOOTH_USE_USB = True in the config.ini file

This might be a "hurry up and wait" for improvement on the support for it on a kernel

I used 1.3.2.2024 for months without any disconnection on JKBMS/Bluetooth. The last 1.4 failed after minutes only and would not be stable at all... I used poll of 10s ... would apparently change nothing to the data refresh speed...

I've rolled back to 1.3.2 and even if i restarted twice .. it work since a week now without any BT issue, something wrong has been done between those versions 1.3.2-1.4.

Resetting bluetooth for whatever small reason, is an shortcut i would not take.... the underlying cause need to be found and solved. Specially when this is a regression vs previous version.

I'm a bit confused, was this now closed without an actual fix to the problem? As we mentioned above, somehow the behavior got worse in the newer releases, I think this is not just related to "unstable onboard Bluetooth".

Louisvdw / dbus-serialbattery