I'm trying to get my Raspberry Pi to talk to my TI Sensortag over Bluetooth LE, using an IOGear Bluetooth 4.0 USB adapter. I chose that adapter because it is supported by Linux, and so far it works quite nicely with the Pi.
To start with, I'd like to write something to pull the sensor data - temperature, humidity, pressure, etc - from the SensorTag and publish it over MQTT. However, reading the data seems to be problematic.
Problem #1 is that the most-used bluetooth package for Python, PyBluez had their last release (0.18) in November, 2009, which, obviously, doesn't include Bluetooth LE. Not a problem, I thought, I'll just fork the project, add the bindings for LE, and off we go!
Which brings me to problem #2: the developers of the BlueZ protocol stack, which is how you access bluetooth from, well, pretty much everywhere, haven't seen fit to include GATT support either via a public library or via D-Bus, despite the fact that they've had the code in their codebase since around 2010.
Look, I understand that everybody's busy and all, but, really, you couldn't, in the last THREE YEARS break out the GATT code into a library so that people can access it? Really?
Of course, I shouldn't complain, I guess - they do provide a nice little command-line tool,
gatttool, to let you do GATT stuff, just nothing to do, you know, programming with. Somebody (who is much braver than I) is even trying to access that via Python and pexpect, which works, sort of, but, uh, really, there has to be a better way.
So, I guess my only option is to pull the GATT code out of the BlueZ project and add it to the Python project. It's ugly, but it's better than expect scripts.
And, really, BlueZ developers: Come on, throw us a bone here.
Well, it looks like I spoke too soon. Because the BlueZ developers have the GATT-layer stuff hooked heavily into glib 2.0 using callbacks, it would be much more work than I'm willing to put into it to do this within Python, which probably explains why nobody else has done it either. Thanks again, BlueZ team! sigh
So, I guess what I'm going to have to end up doing is writing all this in C/C++, and pulling parts of their GATT code into my project. Either that, or just implementing the parts I need myself.
My guess is that the BlueZ developers are really more interested in writing kernel code than user-space code. It really sucks for anybody who wants to play with LE applications, though - right now everybody seems to be just writing wrappers around the BlueZ command-line apps and calling it a day. Not a great way to help with adoption of a standard, guys!