vesmart-server disconnects ALL BLE devices on ALL adapters when keepalive timer fires

[cgoudie]

Summary

The vesmart-server service (/opt/victronenergy/vesmart-server/) disconnects all BLE devices known to BlueZ when its internal 60-second keepalive timer expires — regardless of which adapter the devices are connected to, and regardless of whether the devices are VE.Smart Networking participants.

This makes it impossible to maintain persistent BLE connections to third-party devices (e.g., BLE battery management systems) on a Cerbo GX, even when using a separate USB Bluetooth adapter (hci1).

Environment

• Device: Cerbo GX
• Venus OS: v3.x (observed on current firmware)
• vesmart-server version: 0.5.9 (/opt/victronenergy/vesmart-server/vesmart_server.py)
• Bluetooth adapters: Built-in hci0 + USB dongle hci1

Root Cause

The keepalive timer in /opt/victronenergy/vesmart-server/gattserver.py fires every 60 seconds when no VE.Smart device has written to the GATT service. When it fires, the timeout handler:

1. Calls bluezutils.get_devices(self.bus) — which returns all devices across all adapters
2. Iterates through every device and calls device_interface.Disconnect() on each one

There is no filtering by:

• Adapter — devices on hci1 are disconnected even though vesmart-server was started with -i hci0
• Device type — non-VE.Smart devices (BMS units, sensors, etc.) are disconnected even though they never interacted with the VE.Smart GATT service

How to Reproduce

1. Connect any BLE device to the Cerbo GX on any adapter (including a USB adapter on hci1)
2. Ensure no VE.Smart devices are connected (so the keepalive timer is never reset)
3. Monitor with dbus-monitor --system filtering for org.bluez.Device1.Disconnect
4. After exactly 60 seconds, observe the Disconnect() call being made on your device by the vesmart_server.py process

Confirmed via btmon traces showing Disconnect Complete events with reason Connection Terminated By Local Host at exactly 60-second intervals, and via dbus-monitor tracing the D-Bus Disconnect() calls back to the vesmart_server.py PID.

Expected Behavior

vesmart-server should only disconnect devices that it is managing — i.e., devices that have connected to and are participating in the VE.Smart Networking GATT service. Devices that were connected by other processes (other Venus OS services, third-party drivers, etc.) should not be affected by the VE.Smart keepalive lifecycle.

Non-VE.Smart devices, and devices on other adapters, should never be touched.

Impact

This bug affects anyone running persistent BLE connections alongside vesmart-server, including:

• Third-party BLE battery management systems (via projects like dbus-serialbattery)
• BLE sensors connected through a secondary adapter
• Any future Venus OS feature that maintains long-lived BLE connections

The current workaround is to disable vesmart-server entirely, which also disables Victron Connect BLE access and VE.Smart Networking.

[jhofstee]

The vesmart server its watchdog did disconnect all connected Bluetooth devices, this is changed to only disconnect the device on the adapter it is using.

[cgoudie]

@jhofstee it should only disconnect devices it connected, correct? It shouldn't arbitrarily disconnect bluetooth connections it has no authority over

[ThiemoVanEngelen]

I believe there is no way to know via the Bluez dbus API which device is a connection coming from outside of the GX and which connections are made by some process on the GX itself to a remote BLE device.

[cgoudie]

@ThiemoVanEngelen That goes back to my point though:

vesmart-server should only disconnect devices that it is managing — i.e., devices that have connected to and are participating in the VE.Smart Networking GATT service. Devices that were connected by other processes (other Venus OS services, third-party drivers, etc.) should not be affected by the VE.Smart keepalive lifecycle.

Either capabilities on the GX should register (possibly through interacting with the VE.Smart GATT service) that they want this behavior, or individual capabilities should self manage their heartbeat and connections.

I have no devices interacting with the VE.Smart GATT service, but I still get this behavior.

when no VE.Smart device has written to the GATT service
Or go by mac addresses that are in scope as GATT VE.Smart devices? I do have to question though. Do those exist? I thought the only way to pair a VE.Smart device was by hardwire. I dont know of any way to pair one over bluetooth to the GX.

This tear down of connections is super destructive to any Bluetooth integration either on our off the GX as it's done widely... It's also not ideal to force integrations to use another bluetooth adapter, and it's not always clear which one the GX will try to use if you add another.

[cgoudie]

Related: #1597 — dbus-ble-sensors raw HCI socket scanning corrupts BlueZ D-Bus discovery state

These two issues compound each other to make third-party BLE services unworkable on Venus OS:

• This issue (vesmart-server disconnects ALL BLE devices on ALL adapters when keepalive timer fires #1587): vesmart-server disconnects all BLE devices every 60 seconds
• dbus-ble-sensors raw HCI socket scanning corrupts BlueZ D-Bus discovery state, causing org.bluez.Error.InProgress for other BLE services #1597: dbus-ble-sensors corrupts BlueZ adapter state every 10 seconds via raw HCI commands, causing org.bluez.Error.InProgress for any service trying to use StartDiscovery

A third-party BLE service gets forcefully disconnected by vesmart-server, then cannot rediscover or reconnect because dbus-ble-sensors has corrupted the BlueZ discovery state. The combination effectively prevents any persistent BLE connections on a Cerbo GX.

[cgoudie]

@pawelwod

[cgoudie]

@ThiemoVanEngelen You're right that BlueZ's D-Bus API doesn't distinguish connection origin — but vesmart-server doesn't need BlueZ to tell it. The GATT service itself already knows which devices are VictronConnect clients, because only VictronConnect clients interact with vesmart-server's own GATT characteristics.

To be clear: other BLE devices on the Cerbo absolutely use GATT — batteries, sensors, etc. all have their own GATT services. But the relationship is reversed: the Cerbo connects outbound to their GATT services as a client. Those devices never connect inbound to vesmart-server's GATT service (306b0001-b081-4037-83dc-e59fcc3cdfd0). Only VictronConnect does that.

Here's how the information flows today:

1. Any BLE device connecting (inbound or outbound) triggers _adapter_properties_changed → _device_connected() → Vesmartserver.connected() → starts the 60s keep-alive timer (gattserver.py:744). This is the root cause — the timer starts for connections that have nothing to do with VE.Smart.

2. Only VictronConnect clients actually read/write vesmart's GATT characteristics. Specifically:

   • They read ControlChr.read_value(options) (gattserver.py:924) — the VictronConnect handshake
   • They write VE_REG_CONNECTION_KEEP_ALIVE (gattserver.py:353) — which resets the keep-alive timer

3. BlueZ passes an options dict to every ReadValue/WriteValue call that includes a device key containing the D-Bus object path of the client device. The code already reads mtu from this dict (options.get("mtu", 23)) but discards the device identity.

A battery BMS connected via GATT (e.g., Nordic UART service 6e400001-...) shows up as "Connected" in BlueZ — but it never touches vesmart's 306b* characteristics, because the Cerbo is the client in that relationship. So vesmart's characteristic callbacks never fire for it. That's the distinguishing signal.

Suggested fix:

1. Track device paths that have actually interacted with vesmart's GATT service (e.g., add options["device"] to a set when ControlChr.read_value() is called)
2. Don't start the keep-alive timer in connected() (which fires for all BlueZ connections) — instead, start it when the first GATT characteristic interaction occurs (or when VE_REG_CONNECTION_KEEP_ALIVE is first written)
3. In _keep_alive_timer_timeout(), only disconnect device paths in the tracked set, not everything returned by bluezutils.get_devices()

This would be a minimal change — a set, a couple of .add() calls, and a filter in the timeout handler — and would completely eliminate the collateral disconnects without affecting VictronConnect functionality.

[cgoudie]

@jhofstee tagging you on the above as well — the GATT characteristic callbacks already provide the device identity needed to scope the disconnects to actual VE.Smart clients only.