BLE HID pairing

[mondalaci]

BLE HID pairing already works to some extent. The pairing code appears on the OLED display, it's accepted/refused, and the relevant security keys are created on the settings partition.

However, the paired device should also be added to host connections, which is not trivial because it changes the user configuration, which should be updated by Agent.

1. The firmware calculates new addresses by reading the pairing keys on the settings partition (which I believe are of the bt/keys/e89c2557115f0 format, but double-check it), and checking whether they're present in host connections.
2. If there are new addresses, expose a new newBleAddressesPresent bit via getDeviceState's response.
3. When Agent detects this bit, it'll call the newly added getNewBleAddresses getDeviceProperty command. The first response byte is the number of new BLE addresses, followed by the 6-byte addresses. Assuming a maximum 64-byte packet with a return status byte and a count byte, only 62 bytes are available for addresses, allowing up to 10 addresses, so maximize the number of addresses in 10. This process will naturally repeat for the rest of the addresses on the rare occasion of more unpaired addresses.
4. Agent will display a yellow notification bar at the top containing "A new Bluetooth device has been paired to this UHK. Let's [add it to connections] so that you can switch to it." or its plural form "New Bluetooth devices have been paired to this UHK. Let's [add them to connections] so that you can switch to them."
5. When clicking on the above [add[s] it/them to connections] link, Agent jumps to the connections screen, adds the new addresses to connection targets, and saves the configuration. The firmware should expose the updated values, making the notification bar disappear.

[kareltucek]

If there are paired dongles that are not in host connections (e.g., because I have imported another user config), those dongles will be reported in the getNewBleAddresses which is pain because we don't know whether a reported address is a dongle or a ble hid device.

The main idea is to ask the user whether such a device should be added or removed, but we will have to recognize dongle connections somehow. For this reason we will also have to change the protocol format - so that it contains a flag that indicates whether such an address is a dongle or a ble hid device.

🤦

[kareltucek]

Maybe we should just keep this information in RAM (as part of the host_connections list, just with a new "dirty" flag) and clean up all unknown bonds on device reboot?

[kareltucek]

Actually I think I should remove all unrecognized bonds whenever a user config is applied? (i.e., automatically in firmware)

I am not sure if I should do the same for new/"new" ble hosts? But probably yes.

[mondalaci]

Removing unrecognized bonds is a surefire way of preventing settings partition overflow, and it's a reasonable solution, although if a user restores older configuration versions, (s)he may have to re-pair some devices.

Based on the BLE address, can it be deduced whether it's a Nordic device? If so, no extra flag would be needed.

[kareltucek]

Not sure. Nus client actively initiates NUS communication, so we probably can recognize dongles, although not immediately after connection.

Given that deleting the bond from the peripheral side prevents the connection, we too don't have to deal with unknown but bonded dongles.

Furthermore if we remove unrecognized bonds of both kinds, then the host connections list always tells us which type of device that is.

[mondalaci]

As for cleaning up bonds on device reboots, who knows when that will happen for regularly charged battery-powered UHKs, so I favor always removing unrecognized bonds upon every configuration save. Users may encounter usability issues when restoring configurations, having to repair some devices, but we'll see whether it's actually an issue. Always removing unrecognized bonds is a surefire way to prevent settings partition overflow, so I like this solution. Agreed?

[kareltucek]

Yes!

[mondalaci]

How will additional dongle/BLE host connections be handled upon imports without corresponding bonds?

[kareltucek]

Well, Agent has api sufficient to handle that, but a pretty clumsy one (Robi would have to query all host connections one by one.), so we should probably provide a more convenient api.

As for UI, I imagine Agent showing an indicator next to each connection indicating whether the connection is paired, and if it is not paired, is a dongle, and is connected, then either show a pair button next to it, or maybe automatically pair all dongles one by one using current pop-up bar solution.

[kareltucek]

So I guess I should add a new command that returns an array of all host connection states? It would provide 22 8bit state mask that would convey whether each host connection is known, paired, and connected.

Agreed on this?

[mondalaci]

Would Agent query every non-USB host connection to ensure they are paired? If yes, exactly on which occasions? Please elaborate on the current "clumsy" solution.