GATT Service paradigm / Generic Access characteristics
thecubic opened this issue · comments
Hi, I'm trying to use a GATT device (a CGM transmitter, a "Dexcom G6")
discovering characteristics shows this:
Characteristic { uuid: 00002a05-0000-1000-8000-00805f9b34fb, properties: INDICATE }
Characteristic { uuid: 00002a29-0000-1000-8000-00805f9b34fb, properties: READ }
Characteristic { uuid: 00002a24-0000-1000-8000-00805f9b34fb, properties: READ }
Characteristic { uuid: 00002a26-0000-1000-8000-00805f9b34fb, properties: READ }
Characteristic { uuid: f8083533-849e-531c-c594-30f1f86a4ea5, properties: READ | NOTIFY }
Characteristic { uuid: f8083538-849e-531c-c594-30f1f86a4ea5, properties: READ | NOTIFY }
Characteristic { uuid: f8083534-849e-531c-c594-30f1f86a4ea5, properties: WRITE | INDICATE }
Characteristic { uuid: f8083535-849e-531c-c594-30f1f86a4ea5, properties: WRITE | INDICATE }
Characteristic { uuid: f8083536-849e-531c-c594-30f1f86a4ea5, properties: NOTIFY }
Characteristic { uuid: f8083537-849e-531c-c594-30f1f86a4ea5, properties: READ }
the problem is that this is across 3 different services, and a fourth service - the generic access service, mandatory by the GATT spec, is somehow missing, along with 4 characteristics. Manually constructing a characteristic in that service (e.g. 0x2a00) structs and attempting a read fails.
The generic access service is advertised:
ServicesAdvertisement:<addr>, ["0x1800", "0x1801", "0x180a", "f8083532-849e-531c-c594-30f1f86a4ea5"]
I think the standard paradigm is device -> N services -> N characteristics -> N descriptors, but this seems to go straight from device to characteristics. I can read those characteristics from other BLE packages (using BlueZ as a provider)
Thanks for pointing this out! I'll see if I can repro over here, should be possible since anything the library connects to should expose that service.
@qwandor Does the BlueZ core do any sort of filtering around standard services?
I'll look into it. The other issue here is that we don't group characteristics by service in our API, which we should. I'll have a look at fixing that too, and adding descriptors.
Actually the grouping by services was #11 I think, but that was closed without being fixed.