BLE API: returning the address for an existing connection

[ThomasAtBBTF]

This request is a result of a support topic in the forum under https://forums.adafruit.com/viewtopic.php?f=60&t=187178
And also relates to the issue: #4639

To be able to implement a good HID-keyboard solution it is necessary to be able to pair with multiple centrals on the one hand,
on the other hand, it does not make sense to send keystrokes to every connected central simultaneously. Managing the connection from the UI of the central is tedious and sometimes impossible.

So there must be a way to understand in the HID-Keyboard code to which centrals the keyboard is currently connected and disconnect from the undesired ones.

When trying to change the central, I think the keyboard shall disconnect from all centrals, then start to advertise and look if the desired central connects. After that, advertising can stop and the connection to all centrals except the desired one can be disconnected.

[tannewt]

BLE also has directed advertising that could be used to request a specific client connect. I think I wired it up in the code but ended up not needing it. So, it may work already.

[dhalbert]

@tannewt I was wondering where you were getting the addresses for the directed advertising.

[tannewt]

I may have had special access because I was internal in C.

[ThomasAtBBTF]

Yesterday it was mentioned / suggested in "Deep Dive w/Scott: #CircuitPython2022" that DeviceInfoService() could be used for identifying the "partner" in a connection.
Checking this I did not find a way to obtain the DeviceInfo from a connection.
It seems to be only available during the start scan phase in the result of ble.start_scan.
A keyboard advertises its services and "gets connected" by one or more centrals.
Because it absolutely does not make sense for a keyboard to be connected to more than one central in parallel and send same keystrokes to them, there should be a way to disconnect from all centrals except the one the user wants to focus to!
So I think, more information about the central should be available in the Connection class.

[tannewt]

@ThomasAtBBTF What centrals are you using? I want to replicate it here and provide a DeviceInfo example for you.

[ThomasAtBBTF]

I would like to use an iPhone and a iPad and a Mac and a Windows PC from time to time as the user likes to.
But mainly iPhones and iPads.
And always only connect to one central even if the others are close and running.
The peripheral shall be able to decide to whom he wants to talk to.
(this seems to be hard or almost impossible)
But disconnecting from a connection should be easy (and is working in my code), if I only would know which connection to disconnect.

[tannewt]

Ok thanks. I've got an iPhone that I tested this with.

Example code (will PR to the BLE repo too):

# SPDX-FileCopyrightText: 2022 Scott Shawcroft for Adafruit Industries
# SPDX-License-Identifier: MIT

"""
This example does a generic connectable advertisement and prints out the
manufacturer and model number of the device(s) that connect to it.
"""

import time
import adafruit_ble
from adafruit_ble.advertising.standard import Advertisement
from adafruit_ble.services.standard.device_info import DeviceInfoService

radio = adafruit_ble.BLERadio()
a = Advertisement()
a.connectable = True
radio.start_advertising(a)

print ("advertising")

while not radio.connected:
    pass

print("connected")

while radio.connected:
    for connection in radio.connections:
        if not connection.paired:
            connection.pair()
            print("paired")
        dis = connection[DeviceInfoService]
        print(dis.manufacturer)
        print(dis.model_number)
    time.sleep(60)

print("disconnected")

Prints:

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
advertising
connected
paired
Apple Inc.
iPhone14,2

So, this will work with different devices but not identical ones. The serial number isn't made available on my iPhone.

[tannewt]

Here is a slightly improved version that sets values the other device can read:

# SPDX-FileCopyrightText: 2022 Scott Shawcroft for Adafruit Industries
# SPDX-License-Identifier: MIT

"""
This example does a generic connectable advertisement and prints out the
manufacturer and model number of the device(s) that connect to it.
"""

import time
import adafruit_ble
from adafruit_ble.advertising.standard import Advertisement
from adafruit_ble.services.standard.device_info import DeviceInfoService

radio = adafruit_ble.BLERadio()
a = Advertisement()
a.connectable = True
radio.start_advertising(a)

# Info that the other device can read about us.
my_info = DeviceInfoService(manufacturer="CircuitPython.org", model_number="1234")

print ("advertising")

while not radio.connected:
    pass

print("connected")

while radio.connected:
    for connection in radio.connections:
        if not connection.paired:
            connection.pair()
            print("paired")
        dis = connection[DeviceInfoService]
        print(dis.manufacturer)
        print(dis.model_number)
    time.sleep(60)

print("disconnected")

[ThomasAtBBTF]

Yes, maybe.
But the other device is an IPhone / IPad and IOS connects to a keyboard if the user selects this in the Bluetooth Settings.
The use case is:
The (Blind) user has one Braille-Keyboard and an IPhone and one IPad he want's to pair his Braille keyboard with his IPhone and his IPad.
The user is using Voiceover as the screen reader on both devices to get Speech feedback and maybe a Braille Display to get braille dots from Voiceover. All this works if he also has two Braille Keyboards.
But now he wants to hold on only to one braille keyboard and switch by a key press between his two IOS devices.
If the manufacturer info and the modelnumber is different enough between the devices he can use this method.
But if they are too similar (like a work phone and a private phone) then this method fails.
And what if his Windows-PC (PC's) does (do) not show manufacturer and or model info.
I think this is what MAC addresses are for......

[tannewt]

My point is that it's possible now.

I'm not arguing we shouldn't add an accessor to the mac address of a connection. I'm arguing why it isn't a priority.

[ThomasAtBBTF]

Ok,
I checked out the code and tested it in the CP application for our keyboards and I can use it to decide which one connection to keep and to disconnect the others.

I had hoped, that the .serial_number member of the DeviceInfoservice object would hold the serial_number of the IOS devices, but it didn't.

A quick (and dirty) fix for my problem would be to either put the mac-address string into the serial_number member if the serial number is not available for the device.
Or not so quick (and dirty) to add a Mac Address member to the DeviceInfoservice class.
I think this would mean very little API change, limited testing requirements, and almost no risk to break any existing code.

What do you think?

[ThomasAtBBTF]

May I "pull up" my desire to get the MAC-Address of an established connection here again?

Is there somewhere a "make a whish site" for features in CP.

Currently, with the example of Scott I can differentiate between different Apple IOS models, but not devices.
(If a user has for example two iPhones of the same model, maybe one private and one business phone)
Also so far I did not find in any Bluetooth connection to Windows PC a DeviceinfoService.

For me to have a member MAC-address of the paired partner in a connection object is an obvious necessity !

So please reconsider this feature request.