Hi,
I need to connect to a non-standard remote GATT service. We don't plan
to submit the resulting client code for the time being (it would be of
little interest for the general public), for which it would be good to
keep it as decoupled as possible from bluetoothd.
As I see it, I have two options:
1) Create a BlueZ plugin. bluetoothd supports external plugins through
shared objects but that's not enough to decouple them from bluetoothd:
* Is bluetoothd's API supposed to be respected across versions?
* Even if the answer is true, which I doubt, without a decoupled set
of header files which the plugin can use, I don't see a way to build
it outside of BlueZ's tree.
2) Use the experimental D-Bus GATT API.
Even if the API is likely to change, it would allow to build and
implement the client in a separate process.
Its documentation (doc/gatt-api.txt) made me assume that the API would
be automatically exposed for all services in remote devices since we
discover them when pairing or connecting to a device for the first
time. However, that doesn't seem to be the case. Is there a reason not
to do it?
Comments? Thoughts?
Thanks,
Fons
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
Hi Arman,
> For client the quickest way for you might be to actually write a
> plugin (using the GAttrib code). I would just look at some of the
> profile code, like input/hog or heartrate and maybe add your
> implementation as a profile and expose a simple D-Bus API for it if
> necessary. Since you're not going to submit this upstream, this might
> be the quickest approach for the short term.
That's exactly what I had in mind before I learned about the GATT API.
We will go with this, at least until the GATT API is automatically
exposed.
Thanks,
Fons
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
Hi Marcel & Alfonso,
> I did start it with -E . In fact "gdbus introspect -r --system -o /
> -d org.bluez" shows the GattManager1 interface, but no
> dev_XX_XX_XX_XX_XX_XX/serviceXX(/charYYYY) object exposing
> GattService1 or GattCharacteristic1, not even while connecting to
> a bonded BLE device with GATT services.
The experimental D-Bus API is not implemented, so yeah you won't see
any of those objects. It is in the timeline to get that support built
in the upcoming months but currently everyone who's using that API
went and wrote their forked implementation of it. Some of the GATT
server side support is there, so building and running with -E should
expose a GattManager1, though I don't think that's fully implemented
either.
For client the quickest way for you might be to actually write a
plugin (using the GAttrib code). I would just look at some of the
profile code, like input/hog or heartrate and maybe add your
implementation as a profile and expose a simple D-Bus API for it if
necessary. Since you're not going to submit this upstream, this might
be the quickest approach for the short term.
Cheers,
Arman
> You might have to start the daemon with -E flag. I am also not sure that it is fully hooked up yet. However that would an easy fix I guess.
I did start it with -E . In fact "gdbus introspect -r --system -o /
-d org.bluez" shows the GattManager1 interface, but no
dev_XX_XX_XX_XX_XX_XX/serviceXX(/charYYYY) object exposing
GattService1 or GattCharacteristic1, not even while connecting to
a bonded BLE device with GATT services.
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
Hi Alfonso,
> I need to connect to a non-standard remote GATT service. We don't plan
> to submit the resulting client code for the time being (it would be of
> little interest for the general public), for which it would be good to
> keep it as decoupled as possible from bluetoothd.
>
> As I see it, I have two options:
>
> 1) Create a BlueZ plugin. bluetoothd supports external plugins through
> shared objects but that's not enough to decouple them from bluetoothd:
>
> * Is bluetoothd's API supposed to be respected across versions?
> * Even if the answer is true, which I doubt, without a decoupled set
> of header files which the plugin can use, I don't see a way to build
> it outside of BlueZ's tree.
the internal plugin API is not guaranteed. You can build an external plugin and the daemon will load it. That is technically possible.
> 2) Use the experimental D-Bus GATT API.
>
> Even if the API is likely to change, it would allow to build and
> implement the client in a separate process.
That is the intention here. We want to explicitly allow 3rd party application to operate as GATT client and GATT servers. So that is the way to go.
> Its documentation (doc/gatt-api.txt) made me assume that the API would
> be automatically exposed for all services in remote devices since we
> discover them when pairing or connecting to a device for the first
> time. However, that doesn't seem to be the case. Is there a reason not
> to do it?
You might have to start the daemon with -E flag. I am also not sure that it is fully hooked up yet. However that would an easy fix I guess.
Regards
Marcel