Revival of Official Bluetooth Binding

Hi all,
I am currently in the process of doing a number of fixes and improvements for the official bluetooth binding and I just wanted to start this topic as a way to document my progress and as a sounding board for new ideas.

As a bit of background, I’m rather new to openhab development (started this year actually) but in the process of creating my first binding I got caught up in trying to fix all the bugs in the underlying bluetooth binding to get things to work. Needless to say, I got things working and have decided to share the results.

But for whatever the reason (obsession or genuine interest) I’ve decided to continue my improvements of the bluetooth binding beyond bug fixes and start adding new features.
Below is a list of my git issues showing my progress and roadmap of things I have planned:

  • #6836 Bluez discovery eventually crashes/inbox discoveries are never culled
  • #6912 Adapter discovery settings not respected after restart
  • #6913 Fixed minor Bluez logging bug
  • #6914 Changed characteristic logging to hex
  • #6915 Bluez loses track of devices causing handlers to become unresponsive
  • #7010 tinyb Characteristics disappear
  • #7072 Bluez error causes discovery sweep to crash

These fixes have made my bluez setup (almost) rock solid, so I have decided to take things a bit further to pave the road for development of other bluetooth bindings:

  • #6935 make characteristic write/notify thread safe
  • #7007 Support connection based discovery (basically allows bindings to query the device during discovery)
  • #7008 Allow bluetooth devices to jump between adapters* (is more or less a replicate of the 3rd party binding feature)
  • mqtt-to-bluetooth adapter (basically simulates a native adapter for remote bluetooth-to-mqtt services)
  • add support for device gatt definition files (not quite sure how this would work)

I’m not the only one doing bluetooth bug fixes either; @pauli_anttila and @pfink are working on their own fixes for the bluegiga binding. I’ve been cooperating with them on their code changes.

  • Completed and merged into the official codebase
  • Completed but waiting on PR to merge
  • In development
  • Proposed

For those that want to get their hands on the fixes without having to build the latest code, here are jars with the latest fixes:
Bluetooth Binding snapshot:
Bluez Binding snapshot:
Bluegiga Binding snapshot:

The latest fixes and enhancements are currently in the official repo.

If there are any bugs that still aren’t fixed or features you are dying to have let me know and I’ll see what I can do.


Discovered new issue that I need to address: #7010

Thank you very much for your efforts and great to hear that the bluetooth binding seems to come back to life! :wink:
Is there also a jar to download for the bluegiga binding? As I am only using bluegiga sticks this would be highly appreciated.

@vossivossi Ask, and you will receive.
I’ve added a link in the original post for the latest bleeding edge version of bluegiga that has the fixes and improvments from @pauli_anttila and @pfink.

1 Like

Wow, thanks a lot! I will give it a try!

I installed the new bindings based on OH2.5.2 stable release. The basic functions seem to work.
However I own some blukii sensors and I tried the 2.5.2 binding for these one, and the result is still the same as more than a year ago, discussed in this thread

The device is discovered, sends one time its RSSI value but then freezes (no more updates in RSSI). The other channels (like battery, tmeperature etc. do not work at all, but never did). Is there also work on the blukii part of this binding going on?

The generic bluetooth devices in beacon mode seem to work more reliable (updating RSSI value from time to time without freezing). However, the update interval is changing between 10 to 120 seconds without obvious reasons, although the devices are just a meter away from the stick. This is not very suitable for tasks like presence detection. And as RSSI is the only supported channel(?), presence detection would be the only use case.
Here the 3rd party bluetooth binding is much more suitable: I have it running in parallel on a raspi with OH2.5.0M3 (the last build where it was functional). It updates the RSSI value oh the same devices reliably in a 10 seconds interval continously. And furthermore you can use several sticks/bridges with it and the item definition of a beacon is not bound to one of them. So it offers a location channel which updates the information which of my sticks (placed in different locations in my house) hast reveiced the signal a what point in time. How can I realize such a scenario with the official binding?

Well I’m glad to hear that at least basic functions are operational for you, it took a bit of work to even get it that far!

The current official bluegiga binding doesn’t support automatic discovery of the adapters, so you still need to create the Thing manually. But what issues are you still experiencing exactly? Are you saying that you are still experiencing issues with the Bluegiga adapter being stuck in UNKNOWN?

This sounds like something might be going on with the bluegiga binding, I’ll have to investigate.

There is no work that I am aware of. I don’t own one, but I might be able to track down the issue. What specifically doesn’t work about the blukii binding? Does it not update? Are the values wrong?

Right now RSSI is the only supported channel for generic beacons. And generic connected devices are basically useless ATM. I plan to improve those in the future by adding support for basic GATT characteristics.

I’m actually working on this right now, it is included as part of enhancement 7008 I’ve listed above. I actually have most the code written for it (and 7007 for that matter) and am just in the middle of testing. Although maybe you can give some input before I go down the wrong path. How would you prefer the nearest adapter to be identified? By address (as it is in the 3rd party binding) or by its ThingUID? I was thinking that ThingUID might be more useful for rules, but I might be wrong.

I know that I need to specifiy the COM Port manually and this worked fine. What is important to keep in mind is that you also need to install the Serial Binding manually, otherwise you cannot use Bluegiga (but which is “normal” if you install a binding via AddOns Folder that needs other dependencies).

After some more analysis the problems seem to narrow down to the Blukii part of the binding. The binding is still running stable for more than 14 hours now and all beacon devices still update their RSSI (although sometime with a changing frequency). The blukii devices just stopp reporting RSSI (but they are still displayed as online (which does not make sense to me).

Besides the missing RSSI updates (or device freezing?) after some minutes it is just that no other channel than RSSI is updated for blukii devices either. So the main benefit from the binding would be to read battery level, temperature, humidity, acceleration etc. but none of those blukii specific channels ever change from null. They just don’t work.

ThingUID is a good idea and you are right that it might be a better solution for a more direct use in rules. The 3rd party binding reported also the LOCATION from the thing properties (own channel) which was a nice feature (but it required to maintain the location property for each stick thing before).

Thank you very much for your work!

1 Like

I have a bluegiga dongle and was able to use it without manually installing the serial binding. I don’t know if the libraries are the same ones as what the 3rd party app uses but they come included in the OH core as far as I can tell. I could be wrong though and I might have inadvertently included the library as part of another binding I’m using.

That is either a bug in the blukii binding or the bluegiga binding is not sending data to the binding. Try enabling debug logging on the org.openhab.binding.bluetooth package and see if anything interesting shows up.

I’ll make sure to use that instead then!

I appreciate it.

@cpmeister What use cases do you envision for Bluetooth beyond presence detection? I’m just curious as to where you optimistically think it’ll go in the future.

Honestly, I don’t know where bluetooth is going in the future. The bluetooth spec a combinations of many wildly different protocols, all serving vastly different purposes. It’s a mess. But in that mess, Bluetooth is currently capable of interacting with a huge range of devices: phones, speakers, TVs, locks, lights, fitness trackers, etc…
Bluetooth has a huge amount of potential in home automation that has largely been untapped, and given how easy it is to snoop bluetooth logs (snooper is built-in almost every android phone for debugging purposes), reverse engineering can be fairly easy.

That said, do I plan to implement support for bluetooth speakers, TVs, etc…? Hell no. But at the very least I can pave the road for others that might want to go down that path. My focus is to make OH’s bluetooth framework as robust and flexible as possible while at the same time making features that would be appealing to the largest number of people. But without any input from others I will likely focus on features that are useful to myself.

1 Like

I thought as much. :wink:

Is it possible that individual OH users would be able to connect BT devices and determine what inputs/outputs are available for them to use? I’m assuming the answer is also a strong “no”, but I’m out of my depth.

Mostly, I just want to have my Sphero R2-D2 act as an extension of OH. That would be a lot of fun.

Sounds like a solid plan to me. Thanks for your efforts!

For BLE devices that follow the standard GATT spec, yes, automatic discovery of all available inputs and outputs is not just possible, but mandatory as part of the spec. The hard part of reverse engineering isn’t figuring out ‘what’ to interact with, but ‘how’ to interact with it.
Luckily, if the device adheres closely enough to the GATT spec you don’t need to do much reverse engineering to figure out what does what, it will pretty much tell you.

1 Like

Cool. Thanks for the lesson. I can see a lot more possibilities now, so hopefully manufacturers get on board with the GATT specifications.

PR for #7007 has been created, now awaiting to be merged.

Does this mean, that you’re planning to add GATT parsing for some BLE sensors like Vlad did in the (abandoned?) Bluetooth marketplace binding?

Yea, it is on my list. It isn’t at the very top of my list though:
1st I want to redesign the OH bluetooth api first since it seems like there are quite a few people making bluetooth bindings right now so I want to solidify the api changes before their PRs go through. An improved api will make work easier for other developers in the long run.

2nd on my list is finalizing and testing the roaming feature which is almost done already.

3nd on my list is the implementing the gatt stuff.

1 Like

Sound reasonable :+1:

And, need to add: I’m very happy that you picked this binding to work on. Looking forward to see the results. Thanks a lot for your work!

I assume you had the serial binding already installed. I even could not add any Bluegiga thing (option was not offered in PaperUI) before I manually installed the serial binding. However I am running OH on Windows, so maybe things are different on other platforms.

I will do so when I am back home next week.

Just to post a bit of news.
The official bluetooth binding now supports two new additional things: Airthings and the AM43 Blind Drive motors.
Also, the bluegiga binding fixes by @pauli_anttila and @pfink have been merged into the 2.5.x branch.
Of course there have been numerous smaller bug fixes for both the bluez and bluegiga bindings included as well. I’m more or less patching them as I find them in my own system.

My current focus is to refactor and improve the bluetooth binding code to make it easier for developers to make custom bluetooth bindings down the road including laying the foundation for the dbus adapter binding that will eventually replace the current bluez binding.

I would like to have the refactoring work out of the way to make it easier to tackle 7008 and generic gatt channel support.