Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable pairing timeout #1112

Open
mondalaci opened this issue Feb 2, 2025 · 19 comments
Open

Configurable pairing timeout #1112

mondalaci opened this issue Feb 2, 2025 · 19 comments

Comments

@mondalaci
Copy link
Member

Based on https://forum.ultimatehackingkeyboard.com/t/uhk-80-switch-off-battery-and-ble/1980/18?u=mlac

Add a new user config variable. I propose a int16 containing the number of minutes, or 0 (pairing disabled) or -1 (pairing allowed forever)

I also propose a start advertising device action that'd use the above variable or 5 minutes if the variable is 0 or -1.

@mhantsch
Copy link
Contributor

mhantsch commented Feb 5, 2025

Btw, another strategy that I have seen is that other devices automatically advertise themselves as connectable as long as they are currently not connected to a device. Once they are connected, they stop advertising. To connect them to a new device (and possibly store a new bluetooth connection profile) you have to disconnect them (but not unpair) from the current connection. Or you can press the "make it visible for a short while" button.

@pcooke9
Copy link

pcooke9 commented Feb 5, 2025

I just wanted to mention that in Windows 11, the UHK80 BLE connection doesn't offer a disconnect option. It only offers the option to remove it entirely. Then you need to restart the Bluetooth radio to pair it again.

@mhantsch
Copy link
Contributor

mhantsch commented Feb 5, 2025

I just wanted to mention that in Windows 11, the UHK80 BLE connection doesn't offer a disconnect option. It only offers the option to remove it entirely. Then you need to restart the Bluetooth radio to pair it again.

In that case you'd have to turn off Bluetooth for a moment on the Windows 11 system to get your device to become disconnected and restart advertising. But that's why a "make visible for a while" button makes sense.

Maybe the point is: as long as the keyboard is not connected at all then it should just keep advertising.

Once it's connected, the advertising stops, and only comes back if the "make visible for pairing" button (= smart macro) is used. (Or becomes disconnected again.)

@pcooke9
Copy link

pcooke9 commented Feb 5, 2025

In that case you'd have to turn off Bluetooth for a moment on the Windows 11 system to get your device to become disconnected and restart advertising

Pretty annoying if you have multiple devices connected to the same adapter though.
The two devices I have highlighted here are both connected to the same Bluetooth adapter:

Image

Anyone know if adding a disconnect button is something planned in the future? Sorry if it's been mentioned elsewhere. I don't remember seeing it, if so.

@mondalaci
Copy link
Member Author

The second strategy is also sensible, but given that the UHK 80 can connect to multiple devices, I'd keep advertisements on by default which should result in the best usability. If someone messes with connection attempts, the user can change the default behavior.

@mhantsch
Copy link
Contributor

mhantsch commented Feb 5, 2025

Yeah, I'd set mine to timeout after 5 or 10 minutes, and only turn BT advertisement on when I press some button (to run the appropriate smart macro action).

@RyanCwynar
Copy link

Related to this, in my case, I have two macbooks which I routinely switch between. In order to get to get the UHK to switch between them, I have to tell Macbook 1 to Disconnect. This seems to tell the UHK to stop seeking a connection with that device, which is good. But then Macbook 1 aggressively tries to reconnect and succeeds. So you actually have to turn off the bluetooth radio on Macbook 1 to stop this while the UHK is in the correct state to get it to advertise to Macbook 2.

Seems like it would be nice to be able to initiate the disconnect and then hold off the aggressive connection attempts from this known connection to allow time to switch to the second without depending on taking actions in the OS settings.

So... macro options to 1. Disconnect current BLE connection. 2. Block traffic from a specific connection

Doesn't sound like good UI for the general user, but seems like something that could be useful macro options.

@mondalaci
Copy link
Member Author

We could have a restricted and unrestricted advertising mode. In the former, only known devices that are part of host connections can connect to the UHK.

@kareltucek
Copy link
Collaborator

Well, thinking a bit about the requirements and current capabilities of our code I propose having following modes:

  • (Oob pairing mode. We use that to pair halves and dongles.)
  • Ble hid pairing mode.
  • Normal operation mode, plus an "always advertise" flag that would be set to true by default (current behavior).

And following macro controls:

COMMAND = pairBluetooth
COMMAND = set bluetooth.alwaysAdvertiseHid BOOL

And if you insist, then the pairing timeout. I don't see a need for it (see below) and would simply hardcode it to 5 minutes.

COMMAND = set bluetooth.pairingTimeout <seconds (INT)>

I.e., full set of bluetooth controls would be:

COMMAND = switchHost { last | next | previous | <host connection name (IDENTIFIER)> | <host connection name (STRING)> }
COMMAND = pairBluetooth
COMMAND = set bluetooth.enabled BOOL
COMMAND = set bluetooth.alwaysAdvertiseHid BOOL
COMMAND = set bluetooth.allowUnsecuredConnections BOOL
COMMAND = set bluetooth.peripheralConnectionCount INT

In ble hid pairing mode, uhk would disconnect all known connections, and allow only connections that are not yet paired.

In normal mode with an "always advertise" flag, it would always allow both pairing and incoming hid connections. (Current state of affairs.)

Without the "always advertise" flag, uhk would turn ble advertising on and admit ble hid connections only when:

  • pairBluetooth is called (the pairing mode would be exitted after a device is successfuly paired, or after a hardcoded timeout)
  • switchHost is called
mode allow known connections allow pairing
ble hid pairing no yes
normal mode, with always advertise yes yes
normal mode, without always advertise by manual host switch no

@kareltucek
Copy link
Collaborator

kareltucek commented Mar 13, 2025

(So far I have implemented the alwaysAdvertiseHid flag in #1180 . To be continued when we agree on some specification.)

@mhantsch
Copy link
Contributor

Why do you need the flag? I would use a timeout parameter of 0 to mean "no timeout = always advertise".

@kareltucek
Copy link
Collaborator

kareltucek commented Mar 13, 2025

You may not want to always advertise.

It is confusing, because it may as well mean never advertise.

@kareltucek
Copy link
Collaborator

Or maybe indeed understand it as 4 modes:

  • oob pairing
  • hid pairing
  • hid advertising
  • normal

With these controls:

COMMAND = bluetooth { pair | advertise }
COMMAND = set bluetooth.advertiseTimeout INT
COMMAND = set bluetooth.pairingTimeout INT

Where advertiseTimeout 0 would mean always advertise, and 1 would mean "never".

@mhantsch
Copy link
Contributor

1 would mean "never", or did you mean -1 would mean "never"?

@kareltucek
Copy link
Collaborator

I meant advertise for 1 second, meaning advertise almost never.

@mhantsch
Copy link
Contributor

"almost never", then 😉

@kareltucek
Copy link
Collaborator

(That's why the quotes were there 😃.)

@pcooke9
Copy link

pcooke9 commented Mar 14, 2025

1 would mean "never", or did you mean -1 would mean "never"?

MAX Concise ponders the question of ETERNITY (and fractional divisions thereof)...

@mondalaci
Copy link
Member Author

Do you guys want to specify the initial pairing timeout, or is a 5-minute hardcoded value sufficient? There'll also be a forever and never option. Please elaborate on your use case if you need a custom pairing timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants