More information on client for callback (read and write)

[mklemarczyk]

Describe the solution you'd like
I work on the specific application for BLE logging device. I would like to have several dedicated characteristics, that are write only. I would like to track device MAC without need to add extra data into the exchange.

Describe alternatives you've considered
Alternativly I can add each time the device name or device MAC directly into the value wrote to the characterisitics. That will be against BLE, as it will make payload bigger.

Additional context
The data is already on the BLUEZ transport object. But it is not forwarded into the bless API.
I wonder how is situation for other platforms. I work primarlly with linux based servers.

Extract of the options that are available from bluez {'device': <dbus_next.signature.Variant ('o', /org/bluez/hci0/dev_44_03_2C_91_DF_39)>, 'link': <dbus_next.signature.Variant ('s', LE)>, 'mtu': <dbus_next.signature.Variant ('q', 517)>} logged from the BlueZGattCharacteristic.ReadValue method.

[mklemarczyk]

Do we have someone work on the topic ?
I think it might be useful to agree what data structure could be used in solution. I can prepare some PR with it.

[kevincar]

Just getting around to cleaning up the repository. I think we can make this work—with some caveats. MacOS and Windows both hide the device-specific MAC for the connecting device, but still provide a randomized UUID, used by the server to identify the specific device. In addition to Linux, as you've pointed out, both CoreBluetooth and WinRT seem to provide this information in their requests.

The callbacks now actually have a second parameter options that is used to gather information like the MTU from the client central device, so we can totally just pack all the information there and propagate it to the developer-specific callback to allow you to use it however you want.

As you also pointed out, we'll just need to settle on a data structure that all backends share.

For reference, here is how all the backends get this info:

CoreBluetooth: CBCentral via the CBATTRequest
WinRT: GattSession
BlueZ: Deivce Object within the options dictionary

At a minimum, we can certainly expose the Device address from each these mechanisms.

[kevincar]

@mklemarczyk

I've gone ahead and added a second parameter that is passed to all read/write callbacks using a new BlessGATTRequest. This is simply an object that provides the device MAC/UUID, MTU, read/write offset, and whether a response is requested on write.

This will likely be a breaking change in the next update.