Bluetooth pairing

[kareltucek]

What do you think?

Frankly?

Looking at that wall of unstructured text, I think that only a recording of your megalomaniacal laugh is missing at the end.

And of course that you need to learn to put your ideas forward in a structured, concise and brief manner.

---

Regarding actual content:

I’d like to be able to pair my UHK80 to all of them, and then switch between the connections using something like Fn2+1, Fn2+2, Fn2+3.

Well, right, I guess we can assign new connections into regular host connection slots, so switching between them this way would be possible, however with a reconnection delay.

• (Uhk cannot keep multiple ble hid connections alive atm, although it may be worth to ask Benedek about that. Thence the delay.)
• (For some reason, direct advertising doesn’t work with ble hids very well and UHK, so expect the devices to furiously fight for the UHK.)

Instead of calling it “New Bluetooth device” it would use the device name (you can retrieve that over BT, can’t you?) and name the new Connection “New <>”.

Unfortunately, as far as we know, while it is possible for the central to retrieve peripheral’s name in BLE, it is not possible for the peripheral to retrieve the central’s name. So the best we could do is to name them “New ble device 1”, “New ble device 2”, etc..

I would also get rid of the triangle error that you get when you switch to a connection slot that has not been assigned yet.

We can do that.

i.e. a message on the OLED that just pops up for a second or two in place of the current connection name: “Unassigned connection”

Sounds sensible.

Also, I would allow a shortcut combination to be able to clear a connection slot, and remove the pairing info for that device.

That is also possible I guess.

you could prompt the user on the OLED to confirm the unpairing with Y/N, or to make it keymap independent, to confirm with Enter and cancel with Escape.

Overcomplicated.

[maexxx]

I have decided to ignore my initial reactions to your comment that I would need to learn to put ideas forward in a structured, concise and brief manner. I will only state that I disagree with your statement.

By choice I wrote a longer text to describe use cases and my thinking process. It was not meant to be only a list minimal requirements. I find that given only the bare requirements for implementation, often the actual use case is lost that is supposed to be fulfilled. So I elaborated, and gave some options, in the hope of stirring up a conversation to derive the best solution.

I can supply you with a recording of a megalomaniacal laugh, though, if you so wish.

Now to the content:

@kareltucek

I guess we can assign new connections into regular host connection slots, so switching between them this way would be possible

Perfect.

I understand about the reconnection delay, and that is how it currently works. This is completely independent of whether you use Agent or not; it’s just how the UHK BT & USB stacks currently work. So the delay happens even if you don’t implement my proposed changes. Removing that switchover delay would be a separate proposal / set of changes.

@kareltucek

Unfortunately, as far as we know, while it is possible for the central to retrieve peripheral’s name in BLE, it is not possible for the peripheral to retrieve the central’s name.

I seem to find different information:

How in a bluetooth connection can the Peripheral get the Central device name

The gist in that thread is:

Just read the Device Name in the remote GATT server. The peripheral must support GATT client in order to be able to read the device name.

Peripheral/central is a concept in GAP and relates to advertising, scanning and connection establishment. It has nothing to do with GATT. As can be read in Bluetooth Core specification v5.2, Vol 3 Part C (Generic Access Profile), section 15.2: Devices implementing either the LE Peripheral or LE Central role must always implement a GATT Server (mandatory). GATT Client is optional. So yes a peripheral can also be GATT client.

@kareltucek

I would also get rid of the triangle error […] when you switch to a connection slot that has not been assigned yet.

[Instead, show…] a message on the OLED […] for a second or two in place of the current connection name: “Unassigned connection”

We can do that. […] Sounds sensible.

@kareltucek

Also, I would allow a shortcut combination to be able to clear a connection slot, and remove the pairing info for that device.

That is also possible I guess.

I think with these changes, BT usability of the UHK would improve substantially. It removes the need to use Agent and USB to manage your Connection slots, and be able to switch between them.

[Kyle-D-616]

Great proposal, quite frankly a lot of these ideas are pretty standard for multi device supported Blue tooth.

For the cost of the keyboard I was surprised to not see a lot of this.

[kareltucek]

retrieving ble device name

Interesting!

Well, feel free to try to stir up the discussion at Read BLE device name upon pairing · Issue #963 · UltimateHackingKeyboard/firmware · GitHub .

[pcooke9]

@maexxx

I can supply you with a recording of a megalomaniacal laugh, though, if you so wish.

I would absolutely love if you guys would start a dedicated thread composed of ever-increasingly megalomaniacal laughter, in a proper call/response format.

And I’d also appreciate an “Annoyed Dev Sounds” thread; wherein a snippet of troublesome code is accompanied by indecipherable utterances of frustration .

I’m sure both topics would point to each other quite often. I think we have a real opportunity to make forum history here. Let’s make it happen, yeah?

If you have the time, of course…

I could use a new sound theme for my phone. Since I spend a significant portion of my day yelling at my phone to shut up, I think it would be rather fitting to change all my notification sounds to wild laughter, disgruntled groans, and smashing keebs.

---

Seriously though, Max makes some good points. Being able to manage connections both within and outside of Agent is probably a good move, IMO.

[mlac]

@maexxx Thanks so much for elaborating! These are great suggestions, and they make practical sense.

In retrospect, it’s obvious that my original specification for adding connections was flawed from a usability standpoint. Even though they allow for specifying the connection name, priority, and switchover flag from the get-go, these properties are not necessary, and using Agent is often a burden when adding BLE devices.

As for removing connections, I think we should make the behavior as simple as possible. I propose requiring pressing a connection switch key, such as Fn2+u, for at least 5 seconds to remove the relevant connection. When removed accidentally, one can always re-add it.

I’ll ask Benedek about the BLE-related constraints, then based on his answers, I’ll create a GitHub issue including these suggestions.

@kareltucek Please don’t be so hard on @maexxx. I think he articulated excellent ideas clearly and cares deeply. Let’s be excellent to each other!