openhab-addons
openhab-addons copied to clipboard
openhab
[bluetooth] Add support for service data
Bluetooth low energy allows broadcasters to advertise not only their presence but also Service Data. In Service Data, data of a Bluetooth Service's Characteristic can be advertised. Doing so allows a central like openHAB to receive data from a Bluetooth device without the need to connect to it. This helps to reduce power consumption on the peripheral.
Supplement to the Bluetooth Core Specification, 1.11 SERVICE DATA, page 19
The aim of this pull request is to add basic support of Service Data to openHAB so that a temperature/humidity sensor broadcasting its value as Service Data is supported.
I'm curious what you think about this idea in general @cpmeister and also on how I suggest to implement it. Input and feedback is very welcome.
@Hilbrand, @kaikreuzer, @weymann it seams that @cpmeister has no time to do a review. Is there someone else who could do that?
Hi @PRosenb! Yes, it is a pity that @cpmeister does not find the time as he is our BLE expert... But I am also very interested in getting support for service/characteristic data for beacon devices as this is a very common use case for BLE. I had a look at your code and while it looks good in general, my concern is that it won't scale - you have implemented support for a single characteristic, but there exist more than 200 of them. I guess we'd hence have to rather use some map/library and do dynamic lookups. Also, we will likely require support for BLE units, so that the values can always be correctly parsed and converted to openHAB channel types. Did you spend any thoughts on this already?
Hi @kaikreuzer, thanks for having a look at my implementation. I'm currently moving overseas and have no access to my equipment at the moment.
You are certainly right that there are many characteristics we could support. I thought to start with one I specifically need and then extend it later to support more.
Did you think on using a map in BeaconBluetoothHandler to map service UUIDs to channel types? I thought on that too but as it maps to specific channel types defined in channels.xml, I didn't how we can make it dynamic.
What's your idea there?
What do you mean with BLE units?
With BLE units, I referred to "BLE GATT Units" that also have UUIDs assigned in the specification (see e.g. here. We would need to know the unit of a value to correctly map it to an openHAB item type (preferably a Number with dimension).
I thought to start with one I specifically need and then extend it later to support more.
As mentioned above, by concern is that this won't scale at all. The hope expressed in this post was that a lot of work/features that were done in the previous 3rd-party bluetooth binding can be ported over to this official one here.
This binding used a dedicated GATT parser library and says in its README:
If a bluetooth device supports the Bluetooth specification 4.0, then the standard GATT services and characteristics can be automatically recognized and corresponding thing channels be created for each GATT characteristic and its GATT fields.
This was done in a very generic way, which would imho also be the best way to go here.
I implemented a generic solution but cannot test it without a debugger due to ForbiddenClassException. @kaikreuzer have you seen that issue as well or know how to solve it?
@kaikreuzer - are you interested in looking into this generic solution implemented by @PRosenb? Also there is a request for help, I don't know if you or anyone else would have the knowledge to be able to help.
Thanks @jlaur for your comment.
The ForbiddenClassException happens because the library bluetooth-gatt-parser does not support newer versions of xstream. openHAB uses newer versions of xstream and the newer version is on the classpath.
The existing Generic Bluetooth Device Binding of openHAB is currently broken because it depends on bluetooth-gatt-parser. I created a pull request to fix bluetooth-gatt-parser but unfortunately does it seam abandoned.
@kaikreuzer - are you interested in looking into this generic solution implemented by @PRosenb?
Yes, I definitely am, sorry for not commenting any earlier!
I created a https://github.com/sputnikdev/bluetooth-gatt-parser/pull/15 to fix bluetooth-gatt-parser but unfortunately does it seam abandoned.
How about creating a fork of it in the openHAB organisation? Then we can fix it ourselves and release our own versions of it.
How about creating a fork of it in the openHAB organisation?
I just did so. I included your pull request and released a version 2.0.0 under the new org.openhab namespace: https://github.com/openhab/bluetooth-gatt-parser/releases/tag/bluetooth-gatt-parser-2.0.0
I will prepare a PR to update the Generic Bluetooth Device Binding to make use of this version.
@PRosenb - #13128 is merged now, so you should be able to resolve conflict/rebase.
Thanks for letting me know @jlaur, I rebased it but cannot test it at the moment because I'm overseas. I think review can still go ahead.
Thanks @PRosenb, The code looks good to me in general. I currently cannot test it as I only have a BlueGiga stick at hand, but not a Linux/BlueZ setup. That also brings me to my only concern: The PR only adds support for BlueZ, but not for BlueGiga. I assume you do not have such a stick, so it will be too much to ask you for adding support.
@cdjackson As you are the original author of the BlueGiga bundle: Do you happen to know if it is also possible to extract service data from scan notifications on it? From the code itself, I unfortunately do not see any clear path to do so. 😞
Sorry @kaikreuzer it's been a few years since I've looked at the BlueGiga stuff so I'm not sure to be honest.
Thank you @kaikreuzer to review the code. BlueZ uses the built in Bluetooth chip of the Raspberry Pi. If you have such a device I guess it should work with openHABian. I'm back home by the way and tested it with the new changes from main branch.