Hello all,
I am trying to write a simple GATT-based service of my own. Right now I don't really know which docs I should be looking at. I have skimmed through bluez sources (5.23) and found gatt-service.h and gatt.h, as well as the gatt-example plugin.
So far I am still trying to figure out whether I should be going the C API route or maybe use the D-Bus interface. Also gatt-service.c seems to suggest that there is a way to register a GATT service over D-Bus but running it gives me this:
RegisterService: Method "RegisterService" with signature "oa{sv}" on interface "org.bluez.GattManager1" doesn't exist"
Any pointers to help me get started would be appreciated. Thanks!
Kind regards,
Edmund
--
Mit freundlichen Gr??en
Edmund Urbani
Liland IT Team
Email: [email protected] <mailto:[email protected]>
Liland IT GmbH ...does IT better
Tel: +43 463 220111
Fax: +43 463 220111-33
Tel(GER): +49 221 65028588
Find us at Facebook http://facebook.com/Lilandit
http://green-badges.com
http://iventcloud.com
http://Lilandit.com
<http://www.LilandIT.com> <http://www.LilandIT.com>
Copyright ? 2014, Liland IT GmbH
Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This email may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this email. Any unauthorised
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Hi Edmund,
> On Fri, Nov 7, 2014 at 6:10 AM, Urbani, Edmund <[email protected]> wrote:
> On 11/05/2014 06:47 PM, Arman Uguray wrote:
>>
>> Hi Edmund,
>>
>>> On Wed, Nov 5, 2014 at 9:21 AM, Urbani, Edmund
>>> <[email protected]> wrote:
>>> On 11/04/2014 08:11 PM, Arman Uguray wrote:
>>>>
>>>> Hi Edmund,
>>>>
>>>> On Tue, Nov 4, 2014 at 4:04 AM, Urbani, Edmund
>>>> <[email protected]> wrote:
>>>>>
>>>>> On 11/03/2014 08:32 PM, Arman Uguray wrote:
>>>>>>
>>>>>> Hi Edmund,
>>>>>>
>>>>>>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund
>>>>>>> <[email protected]> wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I am trying to write a simple GATT-based service of my own. Right now
>>>>>>> I
>>>>>>> don't really know which docs I should be looking at. I have skimmed
>>>>>>> through
>>>>>>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as
>>>>>>> the
>>>>>>> gatt-example plugin.
>>>>>>>
>>>>>>> So far I am still trying to figure out whether I should be going the
>>>>>>> C
>>>>>>> API
>>>>>>> route or maybe use the D-Bus interface. Also gatt-service.c seems to
>>>>>>> suggest
>>>>>>> that there is a way to register a GATT service over D-Bus but running
>>>>>>> it
>>>>>>> gives me this:
>>>>>>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>>>>>>> interface "org.bluez.GattManager1" doesn't exist"
>>>>>>
>>>>>> The reason you're not seeing GattManager1 is because it's hidden
>>>>>> behind the "experimental" flag. So you need to configure and run bluez
>>>>>> with the --enable-experimental and the --experimental flags
>>>>>> respectively.
>>>>>>
>>>>>> That said, that API implementation isn't complete and isn't in fact
>>>>>> even wired up with the internal attrib-server. We're working towards
>>>>>> rewriting all of the C API and finally implementing the proposed D-Bus
>>>>>> API but until then, I would ignore doc/gatt-api.txt (it's only a
>>>>>> proposal at the moment and isn't even included in release tarballs).
>>>>>> So for now you have to use the C API route. There will probably be an
>>>>>> announcement once that D-Bus API is finally supported.
>>>>>
>>>>>
>>>>>>> Any pointers to help me get started would be appreciated. Thanks!
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Edmund
>>>>>>
>>>>>> Cheers,
>>>>>> Arman
>>>>>
>>>>>
>>>>> Thanks, I won't bother with the D-Bus interface then. But if the C API
>>>>> is
>>>>> being rewritten now, that sounds like there is currently no stable API
>>>>> available at all. :/ Or is it just the internals being rewritten?
>>>>>
>>>> The C API for GATT interactions is being rewritten, i.e. the code in
>>>> attrib/* is being deprecated in favor of code in src/shared/gatt*. You
>>>> can still keep using the existing APIs though at some point we will
>>>> rip out the existing attrib-server to be a combination of
>>>> shared/gatt-db and shared/gatt-server. So, make sure you keep track of
>>>> the patches going in.
>>>>
>>>> Keep in mind that if you're developing your code on top of the master
>>>> branch then things are meant to be in flight and unstable there, so
>>>> you should follow releases anyway. I think we'll figure out a way so
>>>> that the C based GATT server/client won't be entirely broken for
>>>> people in between official BlueZ releases.
>>>>
>>>>> So I assume, the fastest route the get a prototype that does something,
>>>>> would be to get gatt-example.c to run and then modify that, right?
>>>>>
>>>> Yes, that is the easiest way right now. When the new C APIs are mature
>>>> enough we will convert gatt-example to use the new code but that's
>>>> still a few months down the line.
>>>>
>>>>> Kind regards,
>>>>> Edmund
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-bluetooth"
>>>>> in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> Cheers,
>>>> Arman
>>>
>>>
>>> Thanks, Arman. I now have a basic service with one characteristic and a
>>> read-only value up and running (I can see and read its value from another
>>> system using gatttool... though my iOS app still fails to discover the
>>> service :/ ).
>>>
>>> What I actually need however is a read/write attribute and a way to react
>>> to
>>> write requests. The examples in gatt-service.c all seem to be read-only.
>>> How
>>> would I get a call-back for an incoming write request?
>>>
>> It's not obvious from reading the existing code but the
>> "gatt_service_add" function defined attrib/gatt-service.h allows you
>> to specify read/write handlers using options passed via its variable
>> length argument list. You can look at profiles/proximity/linkloss.c
>> for an example of this. Looking at the link_loss_register function, I
>> see the profile register both a read and a write callback for the
>> Alert Level characteristic (the functions link_loss_alert_lvl_read and
>> link_loss_alert_lvl_write). I think this is what you're looking for.
>>
>> That said, the new API will hopefully make this more readable by doing
>> away with the variable argument list and having explicit functions and
>> arguments for inserting characteristics into the database with
>> read/write handlers.
>>
>>> Kind regards,
>>> Edmund
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Cheers,
>> Arman
>
> Alright, I have a GATT service up and running with handlers for read and
> write requests, and an iOS app that acts as the client/central.
>
> The only thing that is still now working the way it should is service
> discovery. Currently the client finds the service by connecting to any
> device which advertises itself as connectable and then queries its service
> UUIDs. Apparently my service UUID (currently still 16 bit) is not
> advertised, and so I have to resort to this kind of slow, battery-consuming
> service discovery. How do I get BlueZ to include the service UUID in LE
> advertisements?
>
As far as I know, there is a mgmt command for this which you could
invoke directly from your plugin. I'm not sure if bluetoothd actually
advertises any of the UUIDs registered in profiles. There is
definitely no D-Bus API for this but others might be able to answer
the current state affairs regarding hosted GATT services and if the
daemon can advertise them. So, using the mgmt API directly might be
your best bet for now.
> This is the last obstacle to a demo-ready prototype for my project. Thanks
> for everything so far!
>
> And as for future development and production use - any guesses when a BlueZ
> version with a stable GATT service interface over D-Bus might be released?
>
I can't speak for certain regarding a specific BlueZ release. My hope
is to have a D-Bus API for GATT client role in the upcoming month (at
least as experimental) and one for GATT server role, along with
potential D-Bus APIs to put the device into advertising mode with
certain service UUIDs being advertised in the following months. At
least by the end of the year, we should have clean and easy to use C
APIs in src/shared for both client and server roles finished.
So, keep following the mailing list for patches and discussions that
fly by; there's certainly a lot of activity around completing GATT API
support now that we have most of the shared code in place.
> Kind regards,
> Edmund Urbani
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Arman
On 11/05/2014 06:47 PM, Arman Uguray wrote:
> Hi Edmund,
>
>> On Wed, Nov 5, 2014 at 9:21 AM, Urbani, Edmund <[email protected]> wrote:
>> On 11/04/2014 08:11 PM, Arman Uguray wrote:
>>> Hi Edmund,
>>>
>>> On Tue, Nov 4, 2014 at 4:04 AM, Urbani, Edmund
>>> <[email protected]> wrote:
>>>> On 11/03/2014 08:32 PM, Arman Uguray wrote:
>>>>> Hi Edmund,
>>>>>
>>>>>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund
>>>>>> <[email protected]> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I am trying to write a simple GATT-based service of my own. Right now I
>>>>>> don't really know which docs I should be looking at. I have skimmed
>>>>>> through
>>>>>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as
>>>>>> the
>>>>>> gatt-example plugin.
>>>>>>
>>>>>> So far I am still trying to figure out whether I should be going the C
>>>>>> API
>>>>>> route or maybe use the D-Bus interface. Also gatt-service.c seems to
>>>>>> suggest
>>>>>> that there is a way to register a GATT service over D-Bus but running
>>>>>> it
>>>>>> gives me this:
>>>>>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>>>>>> interface "org.bluez.GattManager1" doesn't exist"
>>>>> The reason you're not seeing GattManager1 is because it's hidden
>>>>> behind the "experimental" flag. So you need to configure and run bluez
>>>>> with the --enable-experimental and the --experimental flags
>>>>> respectively.
>>>>>
>>>>> That said, that API implementation isn't complete and isn't in fact
>>>>> even wired up with the internal attrib-server. We're working towards
>>>>> rewriting all of the C API and finally implementing the proposed D-Bus
>>>>> API but until then, I would ignore doc/gatt-api.txt (it's only a
>>>>> proposal at the moment and isn't even included in release tarballs).
>>>>> So for now you have to use the C API route. There will probably be an
>>>>> announcement once that D-Bus API is finally supported.
>>>>
>>>>>> Any pointers to help me get started would be appreciated. Thanks!
>>>>>>
>>>>>> Kind regards,
>>>>>> Edmund
>>>>> Cheers,
>>>>> Arman
>>>>
>>>> Thanks, I won't bother with the D-Bus interface then. But if the C API is
>>>> being rewritten now, that sounds like there is currently no stable API
>>>> available at all. :/ Or is it just the internals being rewritten?
>>>>
>>> The C API for GATT interactions is being rewritten, i.e. the code in
>>> attrib/* is being deprecated in favor of code in src/shared/gatt*. You
>>> can still keep using the existing APIs though at some point we will
>>> rip out the existing attrib-server to be a combination of
>>> shared/gatt-db and shared/gatt-server. So, make sure you keep track of
>>> the patches going in.
>>>
>>> Keep in mind that if you're developing your code on top of the master
>>> branch then things are meant to be in flight and unstable there, so
>>> you should follow releases anyway. I think we'll figure out a way so
>>> that the C based GATT server/client won't be entirely broken for
>>> people in between official BlueZ releases.
>>>
>>>> So I assume, the fastest route the get a prototype that does something,
>>>> would be to get gatt-example.c to run and then modify that, right?
>>>>
>>> Yes, that is the easiest way right now. When the new C APIs are mature
>>> enough we will convert gatt-example to use the new code but that's
>>> still a few months down the line.
>>>
>>>> Kind regards,
>>>> Edmund
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-bluetooth"
>>>> in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Cheers,
>>> Arman
>>
>> Thanks, Arman. I now have a basic service with one characteristic and a
>> read-only value up and running (I can see and read its value from another
>> system using gatttool... though my iOS app still fails to discover the
>> service :/ ).
>>
>> What I actually need however is a read/write attribute and a way to react to
>> write requests. The examples in gatt-service.c all seem to be read-only. How
>> would I get a call-back for an incoming write request?
>>
> It's not obvious from reading the existing code but the
> "gatt_service_add" function defined attrib/gatt-service.h allows you
> to specify read/write handlers using options passed via its variable
> length argument list. You can look at profiles/proximity/linkloss.c
> for an example of this. Looking at the link_loss_register function, I
> see the profile register both a read and a write callback for the
> Alert Level characteristic (the functions link_loss_alert_lvl_read and
> link_loss_alert_lvl_write). I think this is what you're looking for.
>
> That said, the new API will hopefully make this more readable by doing
> away with the variable argument list and having explicit functions and
> arguments for inserting characteristics into the database with
> read/write handlers.
>
>> Kind regards,
>> Edmund
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Cheers,
> Arman
Alright, I have a GATT service up and running with handlers for read and write
requests, and an iOS app that acts as the client/central.
The only thing that is still now working the way it should is service discovery.
Currently the client finds the service by connecting to any device which
advertises itself as connectable and then queries its service UUIDs. Apparently
my service UUID (currently still 16 bit) is not advertised, and so I have to
resort to this kind of slow, battery-consuming service discovery. How do I get
BlueZ to include the service UUID in LE advertisements?
This is the last obstacle to a demo-ready prototype for my project. Thanks for
everything so far!
And as for future development and production use - any guesses when a BlueZ
version with a stable GATT service interface over D-Bus might be released?
Kind regards,
Edmund Urbani
Hi Edmund,
> On Wed, Nov 5, 2014 at 9:21 AM, Urbani, Edmund <[email protected]> wrote:
> On 11/04/2014 08:11 PM, Arman Uguray wrote:
>>
>> Hi Edmund,
>>
>> On Tue, Nov 4, 2014 at 4:04 AM, Urbani, Edmund
>> <[email protected]> wrote:
>>>
>>> On 11/03/2014 08:32 PM, Arman Uguray wrote:
>>>>
>>>> Hi Edmund,
>>>>
>>>>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund
>>>>> <[email protected]> wrote:
>>>>> Hello all,
>>>>>
>>>>> I am trying to write a simple GATT-based service of my own. Right now I
>>>>> don't really know which docs I should be looking at. I have skimmed
>>>>> through
>>>>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as
>>>>> the
>>>>> gatt-example plugin.
>>>>>
>>>>> So far I am still trying to figure out whether I should be going the C
>>>>> API
>>>>> route or maybe use the D-Bus interface. Also gatt-service.c seems to
>>>>> suggest
>>>>> that there is a way to register a GATT service over D-Bus but running
>>>>> it
>>>>> gives me this:
>>>>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>>>>> interface "org.bluez.GattManager1" doesn't exist"
>>>>
>>>> The reason you're not seeing GattManager1 is because it's hidden
>>>> behind the "experimental" flag. So you need to configure and run bluez
>>>> with the --enable-experimental and the --experimental flags
>>>> respectively.
>>>>
>>>> That said, that API implementation isn't complete and isn't in fact
>>>> even wired up with the internal attrib-server. We're working towards
>>>> rewriting all of the C API and finally implementing the proposed D-Bus
>>>> API but until then, I would ignore doc/gatt-api.txt (it's only a
>>>> proposal at the moment and isn't even included in release tarballs).
>>>> So for now you have to use the C API route. There will probably be an
>>>> announcement once that D-Bus API is finally supported.
>>>
>>>
>>>>> Any pointers to help me get started would be appreciated. Thanks!
>>>>>
>>>>> Kind regards,
>>>>> Edmund
>>>>
>>>> Cheers,
>>>> Arman
>>>
>>>
>>> Thanks, I won't bother with the D-Bus interface then. But if the C API is
>>> being rewritten now, that sounds like there is currently no stable API
>>> available at all. :/ Or is it just the internals being rewritten?
>>>
>> The C API for GATT interactions is being rewritten, i.e. the code in
>> attrib/* is being deprecated in favor of code in src/shared/gatt*. You
>> can still keep using the existing APIs though at some point we will
>> rip out the existing attrib-server to be a combination of
>> shared/gatt-db and shared/gatt-server. So, make sure you keep track of
>> the patches going in.
>>
>> Keep in mind that if you're developing your code on top of the master
>> branch then things are meant to be in flight and unstable there, so
>> you should follow releases anyway. I think we'll figure out a way so
>> that the C based GATT server/client won't be entirely broken for
>> people in between official BlueZ releases.
>>
>>> So I assume, the fastest route the get a prototype that does something,
>>> would be to get gatt-example.c to run and then modify that, right?
>>>
>> Yes, that is the easiest way right now. When the new C APIs are mature
>> enough we will convert gatt-example to use the new code but that's
>> still a few months down the line.
>>
>>> Kind regards,
>>> Edmund
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Cheers,
>> Arman
>
>
> Thanks, Arman. I now have a basic service with one characteristic and a
> read-only value up and running (I can see and read its value from another
> system using gatttool... though my iOS app still fails to discover the
> service :/ ).
>
> What I actually need however is a read/write attribute and a way to react to
> write requests. The examples in gatt-service.c all seem to be read-only. How
> would I get a call-back for an incoming write request?
>
It's not obvious from reading the existing code but the
"gatt_service_add" function defined attrib/gatt-service.h allows you
to specify read/write handlers using options passed via its variable
length argument list. You can look at profiles/proximity/linkloss.c
for an example of this. Looking at the link_loss_register function, I
see the profile register both a read and a write callback for the
Alert Level characteristic (the functions link_loss_alert_lvl_read and
link_loss_alert_lvl_write). I think this is what you're looking for.
That said, the new API will hopefully make this more readable by doing
away with the variable argument list and having explicit functions and
arguments for inserting characteristics into the database with
read/write handlers.
>
> Kind regards,
> Edmund
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Arman
On 11/04/2014 08:11 PM, Arman Uguray wrote:
> Hi Edmund,
>
> On Tue, Nov 4, 2014 at 4:04 AM, Urbani, Edmund
> <[email protected]> wrote:
>> On 11/03/2014 08:32 PM, Arman Uguray wrote:
>>> Hi Edmund,
>>>
>>>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund
>>>> <[email protected]> wrote:
>>>> Hello all,
>>>>
>>>> I am trying to write a simple GATT-based service of my own. Right now I
>>>> don't really know which docs I should be looking at. I have skimmed
>>>> through
>>>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as the
>>>> gatt-example plugin.
>>>>
>>>> So far I am still trying to figure out whether I should be going the C
>>>> API
>>>> route or maybe use the D-Bus interface. Also gatt-service.c seems to
>>>> suggest
>>>> that there is a way to register a GATT service over D-Bus but running it
>>>> gives me this:
>>>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>>>> interface "org.bluez.GattManager1" doesn't exist"
>>> The reason you're not seeing GattManager1 is because it's hidden
>>> behind the "experimental" flag. So you need to configure and run bluez
>>> with the --enable-experimental and the --experimental flags
>>> respectively.
>>>
>>> That said, that API implementation isn't complete and isn't in fact
>>> even wired up with the internal attrib-server. We're working towards
>>> rewriting all of the C API and finally implementing the proposed D-Bus
>>> API but until then, I would ignore doc/gatt-api.txt (it's only a
>>> proposal at the moment and isn't even included in release tarballs).
>>> So for now you have to use the C API route. There will probably be an
>>> announcement once that D-Bus API is finally supported.
>>
>>>> Any pointers to help me get started would be appreciated. Thanks!
>>>>
>>>> Kind regards,
>>>> Edmund
>>> Cheers,
>>> Arman
>>
>> Thanks, I won't bother with the D-Bus interface then. But if the C API is
>> being rewritten now, that sounds like there is currently no stable API
>> available at all. :/ Or is it just the internals being rewritten?
>>
> The C API for GATT interactions is being rewritten, i.e. the code in
> attrib/* is being deprecated in favor of code in src/shared/gatt*. You
> can still keep using the existing APIs though at some point we will
> rip out the existing attrib-server to be a combination of
> shared/gatt-db and shared/gatt-server. So, make sure you keep track of
> the patches going in.
>
> Keep in mind that if you're developing your code on top of the master
> branch then things are meant to be in flight and unstable there, so
> you should follow releases anyway. I think we'll figure out a way so
> that the C based GATT server/client won't be entirely broken for
> people in between official BlueZ releases.
>
>> So I assume, the fastest route the get a prototype that does something,
>> would be to get gatt-example.c to run and then modify that, right?
>>
> Yes, that is the easiest way right now. When the new C APIs are mature
> enough we will convert gatt-example to use the new code but that's
> still a few months down the line.
>
>> Kind regards,
>> Edmund
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Cheers,
> Arman
Thanks, Arman. I now have a basic service with one characteristic and a
read-only value up and running (I can see and read its value from another system
using gatttool... though my iOS app still fails to discover the service :/ ).
What I actually need however is a read/write attribute and a way to react to
write requests. The examples in gatt-service.c all seem to be read-only. How
would I get a call-back for an incoming write request?
Kind regards,
Edmund
Hi Edmund,
On Tue, Nov 4, 2014 at 4:04 AM, Urbani, Edmund
<[email protected]> wrote:
>
> On 11/03/2014 08:32 PM, Arman Uguray wrote:
>>
>> Hi Edmund,
>>
>>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund
>>> <[email protected]> wrote:
>>> Hello all,
>>>
>>> I am trying to write a simple GATT-based service of my own. Right now I
>>> don't really know which docs I should be looking at. I have skimmed
>>> through
>>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as the
>>> gatt-example plugin.
>>>
>>> So far I am still trying to figure out whether I should be going the C
>>> API
>>> route or maybe use the D-Bus interface. Also gatt-service.c seems to
>>> suggest
>>> that there is a way to register a GATT service over D-Bus but running it
>>> gives me this:
>>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>>> interface "org.bluez.GattManager1" doesn't exist"
>>
>> The reason you're not seeing GattManager1 is because it's hidden
>> behind the "experimental" flag. So you need to configure and run bluez
>> with the --enable-experimental and the --experimental flags
>> respectively.
>>
>> That said, that API implementation isn't complete and isn't in fact
>> even wired up with the internal attrib-server. We're working towards
>> rewriting all of the C API and finally implementing the proposed D-Bus
>> API but until then, I would ignore doc/gatt-api.txt (it's only a
>> proposal at the moment and isn't even included in release tarballs).
>> So for now you have to use the C API route. There will probably be an
>> announcement once that D-Bus API is finally supported.
>
>
>>> Any pointers to help me get started would be appreciated. Thanks!
>>>
>>> Kind regards,
>>> Edmund
>>
>> Cheers,
>> Arman
>
>
> Thanks, I won't bother with the D-Bus interface then. But if the C API is
> being rewritten now, that sounds like there is currently no stable API
> available at all. :/ Or is it just the internals being rewritten?
>
The C API for GATT interactions is being rewritten, i.e. the code in
attrib/* is being deprecated in favor of code in src/shared/gatt*. You
can still keep using the existing APIs though at some point we will
rip out the existing attrib-server to be a combination of
shared/gatt-db and shared/gatt-server. So, make sure you keep track of
the patches going in.
Keep in mind that if you're developing your code on top of the master
branch then things are meant to be in flight and unstable there, so
you should follow releases anyway. I think we'll figure out a way so
that the C based GATT server/client won't be entirely broken for
people in between official BlueZ releases.
> So I assume, the fastest route the get a prototype that does something,
> would be to get gatt-example.c to run and then modify that, right?
>
Yes, that is the easiest way right now. When the new C APIs are mature
enough we will convert gatt-example to use the new code but that's
still a few months down the line.
> Kind regards,
> Edmund
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Arman
On 11/03/2014 08:32 PM, Arman Uguray wrote:
> Hi Edmund,
>
>> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund <[email protected]> wrote:
>> Hello all,
>>
>> I am trying to write a simple GATT-based service of my own. Right now I
>> don't really know which docs I should be looking at. I have skimmed through
>> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as the
>> gatt-example plugin.
>>
>> So far I am still trying to figure out whether I should be going the C API
>> route or maybe use the D-Bus interface. Also gatt-service.c seems to suggest
>> that there is a way to register a GATT service over D-Bus but running it
>> gives me this:
>> RegisterService: Method "RegisterService" with signature "oa{sv}" on
>> interface "org.bluez.GattManager1" doesn't exist"
> The reason you're not seeing GattManager1 is because it's hidden
> behind the "experimental" flag. So you need to configure and run bluez
> with the --enable-experimental and the --experimental flags
> respectively.
>
> That said, that API implementation isn't complete and isn't in fact
> even wired up with the internal attrib-server. We're working towards
> rewriting all of the C API and finally implementing the proposed D-Bus
> API but until then, I would ignore doc/gatt-api.txt (it's only a
> proposal at the moment and isn't even included in release tarballs).
> So for now you have to use the C API route. There will probably be an
> announcement once that D-Bus API is finally supported.
>> Any pointers to help me get started would be appreciated. Thanks!
>>
>> Kind regards,
>> Edmund
> Cheers,
> Arman
Thanks, I won't bother with the D-Bus interface then. But if the C API is being
rewritten now, that sounds like there is currently no stable API available at
all. :/ Or is it just the internals being rewritten?
So I assume, the fastest route the get a prototype that does something, would be
to get gatt-example.c to run and then modify that, right?
Kind regards,
Edmund
Hi Edmund,
> On Mon, Nov 3, 2014 at 7:38 AM, Urbani, Edmund <[email protected]> wrote:
> Hello all,
>
> I am trying to write a simple GATT-based service of my own. Right now I
> don't really know which docs I should be looking at. I have skimmed through
> bluez sources (5.23) and found gatt-service.h and gatt.h, as well as the
> gatt-example plugin.
>
> So far I am still trying to figure out whether I should be going the C API
> route or maybe use the D-Bus interface. Also gatt-service.c seems to suggest
> that there is a way to register a GATT service over D-Bus but running it
> gives me this:
> RegisterService: Method "RegisterService" with signature "oa{sv}" on
> interface "org.bluez.GattManager1" doesn't exist"
The reason you're not seeing GattManager1 is because it's hidden
behind the "experimental" flag. So you need to configure and run bluez
with the --enable-experimental and the --experimental flags
respectively.
That said, that API implementation isn't complete and isn't in fact
even wired up with the internal attrib-server. We're working towards
rewriting all of the C API and finally implementing the proposed D-Bus
API but until then, I would ignore doc/gatt-api.txt (it's only a
proposal at the moment and isn't even included in release tarballs).
So for now you have to use the C API route. There will probably be an
announcement once that D-Bus API is finally supported.
>
> Any pointers to help me get started would be appreciated. Thanks!
>
> Kind regards,
> Edmund
>
> --
>
> Mit freundlichen Grüßen
> Edmund Urbani
> Liland IT Team
>
> Email: [email protected] <mailto:[email protected]>
>
> Liland IT GmbH ...does IT better
> Tel: +43 463 220111
> Fax: +43 463 220111-33
> Tel(GER): +49 221 65028588
>
> Find us at Facebook http://facebook.com/Lilandit
> http://green-badges.com
> http://iventcloud.com
> http://Lilandit.com
>
> <http://www.LilandIT.com> <http://www.LilandIT.com>
>
> Copyright © 2014, Liland IT GmbH
>
> Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie
> diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail ist nicht gestattet.
>
> This email may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this email in error)
> please notify the sender immediately and destroy this email. Any
> unauthorised copying, disclosure or distribution of the material in this
> email is strictly forbidden.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Arman