1

I will be asking a very subjective question, but it is important as I am looking to recover from failure to effectively use BlueZ programatically.

Basically I envision an IoT edge device that runs on a miniature computer (Ex: Raspberry pi or Intel Compute Stick). The device would then run AlpineLinux OS and interact with Cloud.

Since it is IoT environment, it is needless to mention the importance of Bluetooth BLE over ISM band. Hence the central importance of being able to customize and work with BlueZ.

I am looking to do several things with BlueZ BLE including but not limited to

  1. Advertising

  2. Pairing

  3. Characteristic
  4. Broadcast Secure transport of data etc...

Since I will be needing full control over data, for data-processing and interacting with cloud (Edge AI or Data-science on Cloud) I am looking at three ways of using BlueZ:

  1. Make DBus API calls to BlueZ Methods.
  2. Modify BlueZ codebase and make install a custom bin. (So that callback handlers can be registered and wealth of other bluez methods can be invoked)
  3. Invoke BlueZ using command line utils like hcitool/bluetoothctl inside a program using system() calls.

No 1 is where I have failed. It is exorbitant amount of effort to construct and export DBus objects and then to invoke BlueZ methods. Plus there is no guarantee that you will be able to take care of all BLE issues.

No 2 looks very promising and I want to fully explore how feasible it is to modify the BlueZ code to my needs.

No 3 is the least desirable option, but I want to have it as a fallback option nevertheless.

Given my problem statement, what is the most viable strategy forward? I am asking this aloud so that I do not make more missteps and cost myself time and efforts.

Ace
  • 1,501
  • 4
  • 30
  • 49

1 Answers1

1

Your best strategy is to start with the second way (which you already found promising) as this is a viable solution and many developers go about this method in order to create their BlueZ programs. Here is what I would do:-

  1. Write all the functionality of the system in some sort of flowchart or state machine. This helps you visualise your whole system and what needs to be done to reach your end goal.
  2. Try to perform all the above functionality manually using bluetoothctl and btmgmt. This includes advertising, pairing, etc. I recommend steering away from legacy commands such as hcitool and hciconfig as these have been deprecated and have a very different code structure.
  3. When stumbling upon something that is not the default in bluetoothctl/btmgmt or you want to tweak the functionality, update the source to do so.
  4. Finally, once you manually get the system to perform the functionality that you need (it doesn't have to be all, it can just be a subset of the functions), you can move to automating the whole process. This involves modifying the source for bluetoothctl/btmgmt commands so that instead of manual intervention, everything would be event-driven.
  5. This is a bonus, but if you can create automated tests using python or some other scripting language, then this would ensure that your system is robust and that previous functionality doesn't break when adding new ones.

By the end of this process, you'll have a much better understanding of the internals of bluetoothctl/btmgmt and D-BUS APIs that you might be able to completely detach your code from the original bluetoothctl/btmgmt or create the program from scratch.

You probably already know this, but when modifying the tools, this is the starting point for the source code:-

For more references on using bluetoothctl commands and btmgmt, please see the links below:-

I hope this helps.

Youssif Saeed
  • 11,789
  • 4
  • 44
  • 72
  • Thanks a lot for your answer. I have made lot of progress since I posted this question. I think BlueZ DBus is awfully incomplete. For example there is no DBus API for configuring the bluez chip to do low energy scanning with alll duplicates unfiltered. I had to do this by using sockets and methods inside hci.h and hci_lib.h All this was part of hcitool. Could not find alternatives in bluetoothctl or btmgmt (I could be wrong). – Ace Jun 18 '19 at 12:37
  • I would also want to add that using DBus API is hard in C even with the help of gdbus-codegen. Binding to sockets and using device descriptor is surprisingly straight forward and opens up a wealth of functionality. That is where I stand now. – Ace Jun 18 '19 at 12:39
  • I agree, DBus is incomplete and there are many features missing. Is there good documentation on using sockets instead of DBus API or was this through trial and error? – Youssif Saeed Jun 18 '19 at 20:03
  • My feel is that both Bluetooth SIG and BlueZ are protective about the innards of their product. Perhaps they want to captialize on it. So the answer is no, there are no good documentation. I had to figure out by hard trial and error and it turned out that good old sockets are way better and way way simple than DBUS (Even with gdbus-codegen!) – Ace Jul 03 '19 at 15:07
  • One awkward problem with BlueZ DBus APIs is that it actually works, but then all calls timeout and does not return properly. – Ace Jul 03 '19 at 15:08