Hello All,
I am a developer using bluez via D-Bus to access GATT services and
characteristics [1] and I would like to argue that bluez should not
filter UUIDs of characteristics it handles by internal plugins.
I recently came across this with the battery service (BAS). Our BLE
device exports it, I can read it on Android, iOS and from other devices,
but reading it from Linux is impossible. The UUID doesn't even show up
in the list of characteristics! It took me a while to figure out, that
it is filtered out and that you are supposed to read it via a different
API on D-Bus [2].
It surely makes sense to provide this more generic API, but I'd argue
that all services and characteristics should be available via the normal
GATT-based API using org.bluez.GattCharacteristic1 as well.
One of my clients, for example, uses Linux/bluez as an interface for
Server-based reading and writing of GATT characteristics of several
managed devices. So I can read all those UUIDs, but why not the battery
level? What happens when Bluez learns other GATT services, will their
characteristics then also disappear? I think there is a strong argument
for maintaining a generic API for GATT reading/writing characteristics
independently.
I made the following change to the bluetoothd code to get access again
to all UUIDs, and I would like you to consider to include it upstream to
enable us to access all characteristics via the normal GATT API:
--- a/src/gatt-client.c
+++ b/src/gatt-client.c
@@ -2006,9 +2006,6 @@ static void export_service(struct
gatt_db_attribute *attr, void *user_data)
struct btd_gatt_client *client = user_data;
struct service *service;
- if (gatt_db_service_get_claimed(attr))
- return;
-
service = service_create(attr, client);
if (!service)
return;
Thank you,
bruno
[1] I published parts of that as an open source library:
https://github.com/infsoft-locaware/blzlib
[2]
https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux
