zmk
zmk copied to clipboard
Disconnect old BLE profile when selecting new one
This disconnects the current bluetooth profile when switching to a new one. I noticed that after switching profiles, my old computer would occasionally wake from sleep. This seems to be caused by battery notifications being sent to every connected profile.
I think this might help a bit with battery life? I imagine maintaining active connections to multiple computers must be using some energy.
ZMK intentionally stays connected to each profile to allow for immediate switching between them. An option to only be connected to the active profile might be useful, but I don't think we want to change the default behavior here.
If we were to add that as an option, I expect we'd want it to not connect to the other profiles to begin with as well. I can't say I'm too well versed in the BLE code, so I could be wrong about this, but I believe with just this change it will disconnect from a profile when switching away from it, but when the keyboard boots it will still connect to every profile right away.
An option to only be connected to the active profile might be useful, but I don't think we want to change the default behavior here.
I'd be happy with a compile time config value that disabled fast-switching, if that's what you're suggesting.
If we were to add that as an option, I expect we'd want it to not connect to the other profiles to begin with as well… when the keyboard boots it will still connect to every profile right away
You're correct, and I didn't check this. If we do a config value, I think we could skip the connect step during boot.
Actually, this may be possible already by setting CONFIG_BT_MAX_CONN=1
. That will hopefully fix my problem and reconnect on boot.
this may be possible already by setting
CONFIG_BT_MAX_CONN=1
This doesn't work as intended. For a split keyboard, the peripheral never connects to the central, and it doesn't disconnect the old profile when activating the new one. I think this needs to be on ZMK's side.
@joelspadin I've updated this to use a CONFIG_ZMK_BLE_FAST_SWITCHING
config value (enabled by default).
There's a bit of complication with our bluetooth startup. We use an open advertisement when the active_profile hasn't yet connected due to a bug with direct advertisements and privacy bluetooth connections. So we'll end up connecting to all paired profiles within range when we startup (and we'll keep open advertising until the active connects). The only way to really fix this is to disconnect all non-active profiles after the active one connects. It's a bit hacky, and will still wake my non-active computers, but at least the connection won't be maintained.
It would be nice to add a new BLE test to cover this scenario and verify the behavior against future refactors.
This will be a nice option to have. I'm looking forward to this being merged. I was looking for existing work before I start digging into the code myself as I was considering implementing this feature myself had it not already existed as a PR/assigned issue.
This will allow people to trade the fast switching feature for the convenience of ensuring the on-screen keyboard appears when switching away from devices like phones and tablets without actively having to trigger a disconnect via BT_DISC #
all the time.
It may be an idea to be able to set this on a per-profile basis rather than globally. The issues seem to be more on the end of the target profile and won't necessarily apply to all, so it would make sense to tie it to profiles I think.