Some kind of memory leak in dbus-daemon on BLE reconnection

[pawelwod]

I have setup BLE connection from Multiplus II GX to JK BMS. It's very very unstable. I have reconnection every 30s or less. I would live with that if it was not leading to constant reboots of the whole GX device. Every couple of hours system is staring to be unresponsive and in the end watchdog kicks in and reboots the system.

I was just to blame the dbus-serialbattery and prepared PR to use separate adapter but in long term it won't helpfull.
By accident I discovered following things:

1. when dbus-serialbattery is enabled, connections got dropped and reconnected every 30s-60s
2. the dbus-daemon memory usage constantly increase. About 0.1% every 2-3 minutes.
3. when dbus-daemon hits ~34% memory usage, system gets unresponsive end watchdog reset it.

Ok, so far so good.

Then I tried to triage what might be the reason of that.

First: it looks like this bug in BLEAK hbldh/bleak#90 (@mr-manuel pls check if this fix is pulled in).

Second and more interesting thing:

• After reboot dbus-daemon is using about 0.5% of the memory.
• With dbus-serialbattery enabled I waited some time so the dbus-daemon eate up about 10% of memory, then I did stop dbu-serialbattery by using disable.sh in hope it will free the memory and I can blame the dbu-serialbattery. But the dbus-daemon was at 10%.
• In desperation I have issued following commands:

     service bluetooth restart
     service dbus-1 restart
     /data/apps/dbus-serialbattery/enable.sh
  

And now I have

1. dbus-daemon stays at initial 0.5%
2. no BLE reconnections from about 3h (when using separate BLE adapter just for BMS)

When I looked at it again I realized that with additional adapter I did seen the Multiplus GX twice in VictronConnect. After above commands I see only one instance. Then suddenly It became clear that:

1. By accident I made Venus OS to stop using second BLE adapter.
2. yes, there is something wrong in dbus-serialbattery (possibly with BLEAK library) which makes dbus-daemon to consume more and more memory on every reconnection (maybe the issue I've pointed out)
3. yes, there is something wrong with Venus OS, that it is messing with BLE connections
4. yes, it does consume every BLE adapter plugged into the system

I will ask Victron about 1, 3, 4.
@mr-manuel pls check 2.

Thanks

[mr-manuel]

It is as it is and Victron will not answer you to your questions. I already spend over 100 hours to troubleshoot this. I have many hope to solve it with #313.

[pawelwod]

@mr-manuel yes, looks like this is the case. When Venus is using BT the BMS gets disconnected often. I tested it like this

1. Disabled dbus-serial battery
2. connected JKBMS@hci1 using bluetoothctl, default hci0 left alone.
3. after a while (30s or so) observed disconnection

Then I:

1. disabled BT in WebUI. Default system adapter (hci0) was still functional but unused.
2. Connected JKBMS@hci1 again
3. observed no disconnections at all over about 4 minutes. It was rly late so ended this test.

Then

1. while BT was disabled in WebUi, enabled dbus-serialbattery with JKBMS @ hci1
2. observed no disconnections over ~10minutes, dbus-daemon memory consumption was constant
3. Then I went into low power mode till next day ;)
4. next day after about 13h, no change, observed no disconnections in logs, dbus-daemon memory consumption was as before.

I will let it running for day or two before rebooting hoping it will stay working.

Have no time to check if this will work when using only system BT adapter. When I'm back on spring I can also look into this configuration. For now, if it keep work with external adapter and BT disabled in WebUI then it's fine for me for now.

Will keep informing about system status tomorrow.

BTW: regardless of the BT working or not, there should be no memory leaks in dbus-daemon. This is quite crappy situation :(

[pawelwod]

Update: from 11pm till 5pm next day one reconnection, but looks like it is not related to original issue. dbus-daemon memory usage no change. Good enough, rebooting system and letting it run next day or so.

2025-09-28 23:44:06.659267500 INFO:SerialBattery:> CHARGE FET: True  | DISCHARGE FET: True | BALANCE FET: True
2025-09-28 23:44:06.660183500 INFO:SerialBattery:Serial Number/Unique Identifier: 405162F018
2025-09-29 17:19:51.782417500 INFO:SerialBattery:|- Try to connect to Jkbms_Ble at C8:47:80:19:21:9D using hci1 adapter
2025-09-29 17:19:59.074084500 INFO:SerialBattery:Jkbms_Ble: Bluetooth connection interrupted. Got no fresh data since 15 s.
2025-09-29 17:19:59.196195500 INFO:SerialBattery:Device C8:47:80:19:21:9D not available
2025-09-29 17:19:59.196206500 DeviceSet C8:47:80:19:21:9D not available
2025-09-29 17:19:59.196208500 
2025-09-29 17:20:01.857782500 INFO:SerialBattery:BLE client not found: C8:47:80:19:21:9D - is it turned on and nearby?
2025-09-29 17:20:03.863185500 INFO:SerialBattery:|- Try to connect to Jkbms_Ble at C8:47:80:19:21:9D using hci1 adapter
2025-09-29 17:20:04.682640500 INFO:SerialBattery:|- Device connected, check if it's really a JKBMS
2025-09-29 17:20:05.938496500 INFO:SerialBattery:Processing frame with settings info

[mr-manuel]

You can manually try with https://github.com/patman15/aiobmsble, which I'm implementing right now and will be replacing the current BLE drivers.

[pawelwod]

You can manually try with https://github.com/patman15/aiobmsble, which I'm implementing right now and will be replacing the current BLE drivers.

I don't have a time right now to play with this. Maybe on spring when I'm back. For now 1day 9h running without BLE connection drop. Everything looks fine. I had one restart 2 days ago that looks like original issue, but since that everything is working fine.

[mr-manuel]

If you are in Australia, spring is comming right now ;)