Windows and Android issues with profile clearing

[dark nacelle]

I defined a basic zmk keyboard(added a board in the app/boards/arm folder). When I connect to windows via ble and later clear the profile(using BT_CLR) I can still see the board in my "Bluetooth & Devices->Devices" and it's status keeps on swithching between "connected" to "not connected" every couple of seconds when it is clearly not connected(nothing is printed via keystrokes). Also when I connect to my android phone and then use BT_CLR the keyboard keeps on sending a pairing request every 2-3 seconds. No matter how many times I click "cancel" a new request pops up making it impossible to use the phone without turning off the bluetooth. Is this a known bug or is there a way around this behaviour?
My board link:
https://github.com/ASingh-axio/zmk_fw/tree/main/app/boards/arm/axio

[cursive depot]

The connection goes both ways. Your phone/computer is attempting to reconnect to the keyboard using the key it still has. Android has gotten rather obnoxious about this, but unless something has changed in Win11, the Windows UI should allow you to select the device and forget it without issue.
You could try switching profiles on the keyboard (can also combine with BT_DISC) but for Android I would suggest disconnecting from and forgetting the device on the phone first.

You should also pull your board definition out into its own module, e.g. https://github.com/petejohanson/blank-slate-zmk-module

[dark nacelle]

Thanks. Yes I am able to forget the device from windows. Just felt it would be confusing for someone who doesn't know about zmk and tries to use a board built on zmk. I am trying to make the board for someone.
I am very very new to this so couldn't fully understand the comment about a new module. Is there something wrong in the way I defined the board in the zmk repo? Would making a module be more efficient/use less resources? Should I try copying the blank-slate module structure and then add my config, .dts files?

[cursive depot]

The person you're making this board for would need to become acquainted with ZMK in order to remap keys, unless you intend to do a lot of additional development. Broadly, it seems like ZMK's "profiles" don't behave exactly the same way your average proprietary wireless device does, so your recipient should at least be made aware of the info in the docs: https://zmk.dev/docs/behaviors/bluetooth
Creating a module means you don't need to maintain your own ZMK fork. It's part of the new shield instructions, which are also broadly applicable to new boards (...and can even be used with code enhancements like new behaviors: https://github.com/dhruvinsh/zmk-tri-state)

[dark nacelle]

Yes. I agree that the person will need to be familiar with zmk. But my final goal is to actually modify zmk by changing the source code. I want to be able to pair with multiple devices, save the profile and connect to them without the need for selecting different profiles. For eg if there are multiple paired devices in the vicinity the board should automatically connect to the most recently paired device. I am still pretty new to this...so just getting familiar with basic zmk first. Do you think it is possible to achieve these functionalities?

[neon peak]

A "simple" profile management is in the plans eventually, to add support in ZMK https://zmk.dev/blog/2023/10/05/zmk-sotf-6#coming-soon. I don't think it is currently the top priority item however. In any case, it will require significant work

[cursive depot]

Per the docs page I linked, the keyboard remains connected to all devices it has been paired with as long as you don't intentionally erase the pairing information (...or something goes wrong)
It will also continue sending input to the most recently-paired device, unless the user intentionally selects another profile after pairing with that device.
Are you perhaps suggesting an intentionally-invoked "rapidfire pairing" mode where, instead of ever sending input, the keyboard automatically moves to the next empty profile after the currently-selected one is paired with something?

[dark nacelle]

This is roughly the functionality I want.
I don't want to switch through multiple profiles. I need to connect to only a single device at a time. But the keyboard should save all these profiles and I should have a means to disconnect from one and connect to a different one if the need arises. Now zmk has a lot of the bluetooth functionality mapped to keypresses. I was wondering if it was possible to use bluetooth events instead of keypresses. For eg I am assuming if my keyboard goes out of range a GAP (Generic Access Profile) Disconnection Event is triggered. So we use that event to start advertising so that a new device can be paired. Just an example. Is it feasible to make such changes to zmk?

[cursive depot]

I couldn't tell you. Good luck with it, though.

[dark nacelle]

Thank you for you time. Really appreciate it.

[buoyant sparrow]

@cursive depot This state machine in the image above over complicates what we're trying to do here. The goal is to have ZMK not require the user to do manual BLE profile management. The keyboard should be able to pair to multiple devices, remember all of them, and pair with the most sensible one (most recent? nearest?)

If the keyboard is paired to the wrong device, the user should be able to request for pairing from the right device

Take Airpods as an example product that doesn't have manual BLE profile management. Don't need any user inputs from the Airpods except to enter discovery mode (if you want to pair to an entirely new device)

@neon peak When you say "A "simple" profile management is in the plans eventually" is this the problem you're referring to? If so do you know who might know the most about building something like that out?

[neon peak]

This is the detail that I could dig up: #help message

@wise cobalt is definitely the person to ask

[wise cobalt]

that is "roughly" the automatic profile management I implemented.

I need to dust off that branch.

[buoyant sparrow]

Copy pasting this detail here:

Rough plan:

1. If you enable "simple profile mode", then whenever a device connects, we switch to the profile that it's paired to automatically.
2. If you pair a new device, find the next open profile, assign the device there, and switch to it.
3. Enable "replace oldest key" feature in Zephyr, and use that to "free up" a profile if all taken.
4. Optional: Users can enable the Kconfig to allow re-pairing a host without first clearing from ZMK keyboard. This is a regression in security, so I won't suggest enabling by default, but support it in case folks do turn that on.

@wise cobalt This plan assumes storage is limited. In reality though, would say 100 profiles (essentially infinite in practice) fit easily into the non-volatile memory?

If so, we wouldn't need to worry about the eviction policy and could just maintain a growing list. Iterate through it when we want to reconnect, and append when we have a new device come in

[wise cobalt]

Crashing soon, but Zephyr's BT stack handles the actual key storage.

[buoyant sparrow]

2. If you pair a new device

Did we implement a "forced discovery" hotkey? I was reading from the ZMK docs that discovery is automatic (if not paired or no profile stored on current profile)

Would need some way to signal to the keyboard that we want to "append". I see other ZMK boards do this via clearing the current profile (which doesn't make sense if we're maintaining a list)

[wise cobalt]

And that includes persistence in settings subsystem

As well as things in volatile RAM.

You can definitely just bump the Kconfig to increase the available keys/profiles

[buoyant sparrow]

Yep, thinking just bump that up to something essentially infinite (maybe 100 devices) in practice, then enable this "simple profile mode" you have and that'd do what we're expecting

[wise cobalt]

And yes, my automatic profile mode introduced a "pairing mode"

Separate from normal advertising for reconnects.

[buoyant sparrow]

Crashing soon

No rush on this discussion, appreciate your responses. When you have time would love to take a look at that branch

[wise cobalt]

Bit busy tomorrow, but when I dig it up I'll post here.

[buoyant sparrow]

Sure no worries, thanks Pete!

[dark nacelle]

that would be really helpful

[buoyant sparrow]

Hey @wise cobalt would you have a link to that branch? Happy to help rebase/test or whatever else is needed to get it landed.

It's basically exactly what we're looking for so we're motivated to help out and save you time landing it

[wise cobalt]

It's ble/directed-adv-more-complete but it's really outdated, would need rebasing as a start.