search

hbldh / bleak

A cross platform Bluetooth Low Energy Client for Python using asyncio
MIT License
1.77k stars 294 forks source link

Multiple services/characteristics with the same UUID should not be an error #362

Closed AGlass0fMilk closed 3 years ago

AGlass0fMilk commented 3 years ago

Description

There is no universal requirement in the BT specification that a GATT Server cannot have multiple instances of the same service in its profile, or multiple instances of the same characteristic in a service. This restriction may be specified by a GATT Service specification, but it is not the default nature of GATT services.

Currently, bleak stores services in the client object inside a dictionary using the UUID as the key. This innately disallows multiple services with the same UUID. In fact, it raises an exception here:

https://github.com/hbldh/bleak/blob/d7e9558825330d1f09fb7ad4a64096d33586434e/bleak/backends/service.py#L107-L117

I am implementing a DFU Service for Mbed OS and I was planning to use bleak as the platform for a desktop-based update tool. Through our discussion of the DFU Service specification, we want to allow multiple DFU Services to exist on the GATT Server so that different embedded devices within the same product may be updated over BLE.

This limitation of bleak will make it impossible to support multiple DFU services on the same GATT server. Another example of a service (one that is BT SIG specified, in fact) that allows multiple instances in this way is the common Battery Service:

ble-battery-svc

The suggested fix would be to:

  1. Change from storing any attributes (services/characteristics/descriptors, etc) in a map using their UUID as a key. The key should be the handle of the attribute.
  2. Implement new functions get_services_by_uuid(), get_characteristics_by_uuid(), and so on to return Lists of BleakGattService, BleakGattCharacteristic, ...
  3. Deprecate the get_service(), get_descriptor(), etc functions and in the mean time have them return the first occurrence of a service/descriptor by UUID (ie: return `get_services_by_uuid(uuid)[0])
hbldh commented 3 years ago

Characteristics and descriptors already use handles, but for services I was not sure I could get handles in a good fashion in all OS backends, so I let that remain as uuids. I assumed that no one would ever want to split characteristics over two different services with the same uuid...

I haven’t got time to fix this in the foreseeable future, but feel free to have a go by yourselves! It does seem to be an error in implementation since it apparently says that it should be allowed in some spec.

AGlass0fMilk commented 3 years ago

Characteristics and descriptors already use handles, but for services I was not sure I could get handles in a good fashion in all OS backends, so I let that remain as uuids. I assumed that no one would ever want to split characteristics over two different services with the same uuid...

I haven’t got time to fix this in the foreseeable future, but feel free to have a go by yourselves! It does seem to be an error in implementation since it apparently says that it should be allowed in some spec.

I'll take a look into fixing this as I develop my DFU tooling. Hopefully the service handles are available on all OS's... I do not have a Mac to test with but I can test on Ubuntu 20.04 and Windows 10.