Discover service list of peripheral

[JohnAZoidberg]

Just like discovering the characteristics of a peripheral, we need to be able to discover its services.

It looks like it's quite similar to characteristic discovery, so I'll try to implement it myself for BlueZ.

[qdot]

@JohnAZoidberg are you referring to enumerating services post GATT server connect to a peripheral, or when peripheral services are listed as part of advertisements?

[JohnAZoidberg]

The former, post connect service enumeration. Just like Peripheral::discover_characteristics currently does it for characteristics.

[qdot]

Thanks for clarifying. :D

[Moret84]

Hi, just looking at this issue.

@JohnAZoidberg are you referring to enumerating services post GATT server connect to a peripheral, or when peripheral services are listed as part of advertisements?

About the latter,

I have a bluetooth device (a thermometer btw) that broadcast some data as advertisement.

@qdot Is there any plan to implement a way to get those data in PeripheralProperties ?

edit: I've found a PR that implement something like that, and another issue in which you expose your plans for the future of the crate. I will stay tuned.

[JohnAZoidberg]

Your device probably also has this data as a characteristic. You can connect and let yourself be notified of changes in that characteristic.
You don't need to discover the services at all, just the characteristics.

[qdot]

At some point it would be nice to support service advertisements, but it's not on the roadmap yet (mostly because there's not a roadmap period, yet. I'm hoping to get back to planning improvements on btleplug sometime in the next few weeks)

[JohnAZoidberg]

I took up the service discovery again and I thought that I'll combine it with the characteristic discover.
We can just read all of the attributes at once and then create our Rust service and characteristic structs from them. What do you think @qdot?

[Moret84]

Your device probably also has this data as a characteristic. You can connect and let yourself be notified of changes in that characteristic.
You don't need to discover the services at all, just the characteristics.

Not exactly the same data, actually. There is indeed a characteristic where we can read temperature + hygrometry and subscribe to notification (data are string-encoded).

But the advertised payload periodically changes and contains alternatively humidity+ temperature, temperature, or battery level (as byte array). Furthermore, it is impossible to read battery through a characteristic.

Sometimes it can be useful to read advertisement data because it does not require to connect to the device.

[qdot]

Ok, so as of 0.8 I think we handle both of these things now. We'll do service detection on connect and fill out our peripheral properties struct with that info, and we can also pick it up from advertisements there when they happen. Going to close this, but feel free to reopen or yell at me if I've gotten this wrong.

[qwandor]

I don't think we currently expose services, we just heap all the characteristics from all the services together in one big list.