Bluetooth keeps reconnecting even after manual disconnection

[cvcore]

Hi,

When using the ADV360PRO keyboard on my MacBook, I occasionally need to take the laptop to other rooms and in this case, I often observe a very high latency when typing on the internal keyboard. This issue can be resolved after powering off the ADV360 before leaving the room. So I believe the high latency was caused by the poor bluetooth connection between the keyboard and laptop.

Due to this reason, I need an easy way to disconnect the keyboard. However, I'm simply not able to disconnect it from macOS's bluetooth dropdown menu. After clicking the Adv360 Pro icon for disconnection, after 1 second it automatically reconnects itself, which is quite annoying when you cannot leave the room to turn off the keyboard physically. Switching the keyboard to other profiles also doesn't help, since the keyboard always attempt to connect to all paired devices.

So with this github issue, I would like to request the following fixes:

• Ability to disconnect the keyboard from bluetooth host, without having to disable bluetooth completely
• Option to just connect to one host at a time from the keyboard

Bildschirmaufnahme.2023-06-16.um.11.12.26.mov

[ReFil]

This is the standard behaviour of ZMK, but i can understand why it would present an issue in your use case. I will investigate the code to see if this can be changed

[cvcore]

@ReFil gentle bump on this topic ;)
Hopefully this weekend I can find some time to also look into the zmk firmware. Could you also give me some pointers to start with?

[ReFil]

The adv360 uses a fork of ZMK stored here https://github.com/ReFil/zmk/tree/adv360-z3.2
For development you can fork my repo and change your config repos west.yml file to point to your fork.

The underlying zephyr RTOS has absolutely excellent documentation but remember to select the right zephyr version as ZMK lags the latest available version (there's a drop down menu on the left side)

All the relevant bluetooth stuff is in app/SRC/ble.c
You might be able to make it disconnect when it changes profile but I'm not sure how best to do that, I haven't given it much thought

Sorry I haven't had the time to look into it as I've been very busy with lots of work.

[cvcore]

@ReFil Thanks for the pointers and from app/SRC/ble.c I believe there is something we can do about the advertising. The current logic will keep broadcasting when the current profile is open or loses connection. I believe that's probably something making the host computer keep reconnecting to the keyboard.

Maybe we can check the standby status of the keyboard and disable BLE advertising when it's in sleep mode (when the LEDs are off). In that way we can save some batteries, too.

Which function is best suited for reading the current standby status of the keyboard?

[ReFil]

You'd do that by using the events system in zephyr. If you look at the end of rgb_underglow.c you can see how the Auto off on idle mechanic works. Anything conditional on CONFIG_ZMK_RGB_UNDERGLOW_AUTO_OFF_IDLE takes input from the sleep state of the board

[cvcore]

Thanks for the reply @ReFil and today I got some time to look deeper into the code. So far I was able to implement the desired behavior with some minor logic changes of the code. Would be great if you could look into it and IMO it's better to make it as a standard behavior.

[ReFil]

I'm not sure about introducing a drastic change in the Bluetooth behaviour as default. It would be better if it were to be behind a kconfig option you can enable in adv360_left_defconfig

[KinesisCorporation]

@cvcore Please try again with today's update. We tested this exact scenario and didn't have any problems.

[cvcore]

@cvcore Please try again with today's update. We tested this exact scenario and didn't have any problems.

@KinesisCorporation :
Latest update didn't work well for me. Please refer to: #198 (comment)

And there is still no bluetooth disconnection handling implemented in the latest firmware:

Bildschirmaufnahme.2023-10-27.um.22.57.41.mov

[ReFil]

There are a few upstream ZMK PRs that stand to implement a behaviour to explicitly disconnect and handle disconnections better

[ReFil]

zmkfirmware/zmk#1638 This now merged PR should perform the functionality you want, in the next minor 360 pro update it will be brought into the 360 pro

[ReFil]

Please try recreating the problem now, there are also new bluetooth behaviours to allow you to disconnect from a host with a keypress

[cvcore]

Hi @ReFil , happy new year and great to hear the new features are here! I will try to update my kb to the new fw version on the upcoming weekend and let you know the test results.

[ReFil]

Thank you, hopefully the improved connection management will resolve your issue. Here's the documentation on the keycode to disconnect a bluetooth profile https://zmk.dev/docs/behaviors/bluetooth

[cvcore]

Hi @ReFil ,

I'm able to recompile and flash the latest firmware with BT_DISC behavior implemented (zmkfirmware/zmk#1638), however it didn't solve the issue for me after some testing.

From my understanding, the PR implements the functionality which allows you to disconnect a profile from the keyboard, but not from the computer. To make it work, you need to have a second profile paired and connected, select this profile and only then it's possible to disconnect the first profile by hitting the key BT_DISC. Otherwise, the keyboard will still try to reconnect itself forever.

To me, this behavior is not useful given I need to disconnect the BT connection when I'm away from the keyboard. Additionally it seems for me the repeating key issue is back for this version.

zmk: cvcore/zmk@e6a9407
adv360-pro-zmk: cvcore@24a6b17

[ReFil]

For the repeating key issues try this fix #349 (comment)

[cvcore]

For the repeating key issues try this fix #349 (comment)

Thanks for the hint. Actually I took another approach by implementing bt_conn_disconnect calls during profile switch. In addition switched back to ADV_DIR instead of ADV_CONN for advertising to paired devices. cvcore/zmk@b281cb4...8996f95

It works for MacBooks, but far from perfect as now iPad can't recognize ADV_DIR broadcasts. For that I have to switch to an open profile to force ADV_CONN and then switch to the profile paired with iPad.

For anyone interested in this (experimental) patch, here is the link: cvcore/adv360-meta-configs@59d565c

[ReFil]

That's a neat solution, it's certainly an interesting implementation. It might be worth submitting this feedback as a feature request to upstream ZMK main.

The reason ADV_DIR doesn't work is because apple don't permit it, as per section 49.3 of the (Accessory device specifications)[https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf], Directed advertising isn't technically permissible for connecting to apple devices