4

I am new to BLUEZ as well as linux. I found that Bluez promotes usage of DBUS APIs. I want to know whats a DBUS API in terms of BLUEZ also, whats the benefit of using them instead of direct C APIS? How different is it as compared to C APIs?

user3316985
  • 25
  • 5
Shruthi
  • 93
  • 2
  • 6

3 Answers3

2

From my own experience:

  • DBUS apis are the officially published ones so are more likely to be stable, maintained and documented.
  • The C apis are a bit more low level and it's not always obvious how they can be used (beyond simple discover).
  • The C apis are more light weight whereas the DBUS APIs require more both at build time and at run time (glib, dbus, bluetoothd to name a few things).

So it depends on what you are trying to achieve. If you just want basic discovery and rfcomm/l2cap connections then the C apis are probably ok. If you want anything beyond that and if your platform is able to accommodate the extra overhead of DBUS/bluetoothd/etc then you probably want to go with the DBUS apis.

kaylum
  • 13,833
  • 2
  • 22
  • 31
  • I am trying to create a BLE central which receives notifications from many BLE peripheral devices. BLE central has to be built on Linux machine using BLUEZ. Can I do this using DBUS APIs? – Shruthi Feb 26 '15 at 06:12
  • Also, Can I write a C application program to use DBUS apis? or should it be only in Python? – Shruthi Feb 26 '15 at 10:29
  • @user3301710 Who mentioned Python? There are libraries in both C and Python for DBUS. – Tim Tisdall Feb 26 '15 at 14:42
  • 1
    See Tim's answer. I concur with it. For what you want to do it sounds like the DBUS interface may not do what you want. Unfortunately I don't think there is a nice public raw C interface to Bluez's gatt capabilities (I don't know why). But it's not too difficult to extract that from the Bluez source. I've done it before. To get started take a look at the gatttool source in the attrib directory. Basically you can call g_attrib_register to register for notifications. And gatt_write_char to write to characteristics, including enabling notifications. – kaylum Feb 26 '15 at 22:05
  • I am working on linux kernel version 3.13 and bluez version 5.28. Is the limitation with using DBUS still exist? – Shruthi Feb 27 '15 at 04:34
  • @Tim I taught Python because the sample test scripts(for thermometer, heartrate..) which are using DBUS apis, available at bluez/test are all in python. – Shruthi Feb 27 '15 at 06:25
  • I'm using 5.24 which is about 4 months old. Haven't looked at the latest version so can't say for sure. – kaylum Feb 27 '15 at 09:54
2

Update: bluez now supports a gatt API via the dbus. Just completed in 5.28 (though I think there were bits of it in earlier versions).

kaylum
  • 13,833
  • 2
  • 22
  • 31
1

Bluez pushes the use of the DBUS interface over the rest. Unfortunately, not everything is possible through the DBUS interface.

I haven't looked at it recently, but it used to be that BLE was poorly supported though DBUS. You could only interact with officially published BLE profiles such as heart rate monitors. If you wanted to do anything with attributes not part of any Bluetooth BLE profile then you were stuck. So, for example, accelerometers were impossible to access via the DBUS interface.

This may have changed in the 5.X branch (I haven't been looking at it because it doesn't work on the 3.4 kernel I have to use). The 4.X branch of Bluez hasn't changed and it's definitely the case you'll have issues with BLE over DBUS on non-profile attributes.

Just a note of warning, though, if you're using the 3.4 kernel or older you'll have issues opening more than one L2CAP socket. There's a bug in the kernel that no one seems interested in fixing. (what happens is all the data comes down one socket regardless of which device it came from)

Tim Tisdall
  • 9,914
  • 3
  • 52
  • 82