Switch connection to specified target device?

[joedevsys]

Is your feature request related to a problem? Please describe.
When used from AAC software, particularly for people with accessibility needs, changing target device to a specific target is tricky if multiple targets are paired. The current method is switchBleConnection() which disconnects and waits for the next Central to initiate a connection. This is frustrating as it takes time and if several possible targets may need to keep changing to cycle to the desired one. This is compounded by Focus Assist issues #112 so user has to manually allow enough time for reconnection and then check what he's connected to.

Describe the solution you'd like
On the arduino: an unused parameter is already passed to switchBleConnection(char* myLine). Could this be used to specify the targetname, lookup bleDeviceNameList[] and set appropriate values of switchBleConnStartIndex, switchBleConnCurrIndex? Would this successfully cycle round until it got the right connection?

For debate: The problem here is a BLE peripheral advertises and waits for the central to connect, but the user wants to drive the connection from the peripheral. Another approach, instead of cycling around disconnection/connection cycles until the right one occurs, is it feasible to manipulate the advertising or device name so the each target only recognises the dongle when the dongle wants that target? e.g. When adding new device bleDeviceNameList[i] advertise/pair as "AceRK_i", then when wanting to connect to it change the advertising to this. The other devices won't connect until they see "AceRK_j" etc.???

Any thoughts?

[willwade]

Great - well detailed description @joedevsys. Thanks for that. I've felt the same but couldn't put it into words as good as that

@f1andrew @quaxalber have a look at the above. Any thoughts?

[quaxalber]

I share the sentiment that changing target devices ranges from cumbersome to frustrating UX wise. I really like the idea of target-specific device names. This could allow for a smoother switching.

[willwade]

There is a problem I think with just changing the advertising or device name. It basically didn't work when we did it this way. Well some OS/Bluetooth stack it did - but certainly not on iOS . Reason being is most systems don't really care what the heck the name is called - its the MAC address that matters. Am I recalling this correctly @f1andrew ? Maybe there is improvements to be made though like you say Joe

[joedevsys]

Reason being is most systems don't really care what the heck the name is called - its the MAC address that matters.

Makes sense to me for device name, though I'm thinking advertised service name if that makes a difference?

[quaxalber]

Fair point @willwade
Can't we increment the MAC address as well? Many devices alter their MACs for privacy reasons.

if that makes a difference?

I think in this context it doesn't. While some systems allow for changing the advertising/Bluetooth name different from the device name, the issue remains for systems that solely rely on the MAC. @joedevsys

[joedevsys]

Having spent an afternoon watching an AAC user trying to trigger the correct device to bother connecting itself and trying to do this through the limited features available in AAC software I think this needs to be a whole lot easier to drive and a whole lot easier to show what's going on.

[willwade]

What I’ve not considered is our new relaykeys receiver dongle code. I wonder if there’s anything we can do to help fix this IF the sender knows the receiver. Eg. Each receiving dongle has a known and fixed address. Maybe we can send some kind of packet data to the all bar the others to stop advertising. I don’t know.. random thoughts here!

[f1andrew]

Making command for switching to specific device can be made. I will do that.
It will help with this situation.

The thing that dongle is waiting for connection can't really be changed.
RelayKeys dongle is ble keyboard, which is always peripheral, and target devices(phone, PC, etc) are central.
So dongle can't make connection on its own.

And I have to check it more in detail about altering MAC address.

[f1andrew]

Here is first attempt of switching to specific device: #152
There might be some changes later if needed.

Switching to specific device is available via Serial and Cli.
In general if switch command sent without any arguments then then dongle switches to next device as previously,
if there is device argument then dongle switches specifically to that device.

Serial interface:
AT+SWITCHCONN # switch to next device
AT+SWITCHCONN="Devname" # switch to "Devname" device

Cli commands:
python relaykeys-cli.py ble_cmd:switch # switch to next device
python relaykeys-cli.py ble_cmd:switch="Devname" # switch to "Devname" device

I've tested by switching between three devices and it's working.
Let me know how it works on your side.

[willwade]

Amazing. Thanks @f1andrew .

If either of you want to test this on your own boards and cant be bothered to do the Arduino libraries - let me know what board you have and I'll create a UF2 file for your board.

For a short time here is a Windows build of the software: https://acecentreuk.sharepoint.com/:u:/s/AnonymousShares/ER5YRxu2YmdGmkx-lzonGz8BmUSzO7uiKGhBuODsbPaP_Q?e=439Q7h

[quaxalber]

Great stuff. I'd like to test on my nRF52840 USB Key with TinyUF2 Bootloader
Cheers

[willwade]

Great here you are @quaxalber
RaytacDongleSwitchConn.UF2.zip

[joedevsys]

Thanks @f1andrew. Looking good but I need to do more testing to be sure. So far a couple of minor issues:

1. Fails if Devname contains spaces even if in quotes e.g. >python relaykeys-cli.py ble_cmd:switch="Dev name"
   Later I changed the device name to remove spaces and re-paired and it works now. Spaces in the name are probably bad practice but was this device's default. (However >python relaykeys-cli.py ble_cmd:devremove="Dev name" worked so CLI is happy with spaces).

2. python relaykeys-cli.py ble_cmd:switch="Devname" --notify sends the notification "Default Message". Should notify either "Trying to Connect to Devname" or preferably wait for success/fail and send "Connected to Devname"/"Failed to connect" etc.
   Maybe send both messages "Trying to connect to DevName" followed later by "Connected to Devname"/"Failed to connect"?

I'll report back after more testing...

[edited for clarity]

[f1andrew]

@joedevsys

1. I have one device with space in name and switching to it is working for me.
   If devremove command is working then this isn't CLI problem.
   You can try to uncomment DEBUG in ardiuno code and then manually send switch command via Serial monitor, there might be more info about what is going on.
   But after this don't forget to comment DEBUG back before switching to relaykeys daemon and cli.

2. I've added "Trying to switch to "Devname"" notify message
   Relaykeys dongle doesn't send any info on its own, it responds only if received some command.
   You can poll what device dongle connected to(ble_cmd:devname) to check did it switch to other device.

[quaxalber]

Great here you are @quaxalber
RaytacDongleSwitchConn.UF2.zip

Thanks @willwade
Would've tested already but I'm having a hard time getting the UF2 file on the dongle:

1. I insert the dongle while pressing the button
2. I delete the CURRENT.UF2 (with an alleged 0 B size according to the confirmation dialog).
3. The file apparently gets deleted
4. I copy the UF2 file you provided to the dongle
5. The copying process fails after ~80% with an error message stating that the device is not available
6. The device automatically gets ejected
7. When I re-insert the dongle while pressing the button, the CURRENT.UF2 reappears.

Is this issue known to you? Any idea what might cause it?

[willwade]

Don't delete that uf2 file. Just drag and drop it on top!

[quaxalber]

Tried that too. It doesn't show the error but when I re-insert the dongle while pressing the button, the timestamps still show 2021 for created, accessed, modified. I guess it's not supposed to be that way? Or does it reset each time?

[willwade]

@quaxalber - sorry - it can be a right pain when it doesnt work. Its possible I've messed up that uf2 file. For now it would be wise doing the long way round and doing the arduino install. Its not that hard with the new Arduino software.. sorry! (I'm back next week when I can create another one..)

[joedevsys]

@f1andrew

1. I can't replicate this now, may have been some other problem.
2. Thank you for the message fix.
   I understand your comments about polling but polling is not possible from a Communication Aid because of poor scripting support. Is it possible for the daemon to poll after a suitable time period and raise a notification? (Perhaps this should be a new Feature Request Issue?)

[joedevsys]

This is working very well and much easier for the AAC user I'm working with. I created some buttons on the AAC device, one for each target, and it connects fairly quickly to desired device. Seems fairly reliable too, switching between 3 targets. The only disadvantage is polling to see the result after a delay causes issues on Communicator 5 so user needs to wait and then press another button to see the result, therefore Feature Request created for optional auto polling.
Many thanks @f1andrew

[willwade]

yeah. I too had some brief time to try and it looks great to me. (@quaxalber - apologies - i havent had time to try and get another uf2 for you.. but I should soon enough). @joedevsys Auto polling makes sense. What are you thinking it could do to check the connection? Send a key?

[joedevsys]

See #153