I’m planning to implement an integration of Bluetooth Mesh technology into openHAB.
According to Kai, it is wise to talk here BEFORE start coding on something :-).
Current ideas:
Since there is no Java support for BT, I would like to interface the BlueZ stack via DBus, similar to the existing BLE binding.
Since BlueZ v5.47, a tool called “meshctl” was introduced, supporting the network provisioning of new devices.
Maybe it would be easier to start here.
Maybe it is a good idea to talk to @vkolotov . Vlad has developed the marketplace Bluetooth Binding and an approach how to include far away bluetooth dongle ist discussed often.
Hi @benjaminaigner, you are more than welcome to help Kai (with his official bluetooth binding) or me (3rd party bluetooth binding) to extend one of the bindings (or both?) with mesh networking. In fact, it was on my list but not in the near future as, honestly speaking, there are lot of things to implement in BT world apart of mesh networking…
The binding that I develop/support is based on the Java Bluetooth Manager that is also developed and supported by OH community. As you said, there is not BT support in Java, so the BluetoothManager is supposed to fill that gap. We tried to design it in a such way that it is easily extendable. It supports various “transport” layers, e.g. TinyB (over DBus), BlueGiga and native DBus (it is being developed now).
The reason why we try to develop another “Bluez” transport (DBus) is that we wanted to get rid of superficial and unstable TinyB library. This also would allow us to implement new features that Bluez support, e.g. meshing.
As to Bluegiga transport, I don’t think bluegiga dongles (BG API) support mesh networking, but I can be wrong though. Anyway, even if it does not support it, it should not stop us from implementing it in DBus transport.
thanks for this explanation!
Hm, this is a hard decision:
Your stack seems to be better maintained/documented/structured
Implementing within an official binding is better for reaching more users.
Anyway, as far as I know, BlueZ is the only stack currently (partly) supporting mesh functionality.
In general, I would NOT implement the provisioning process in the first place.
So, it is down to a GATT connection to a proxy device, publishing/subscribing to different models (e.g. Generic OnOff -> light switch).
As I can see in your referenced implementation overview:
Comprehensive support for Bluetooth GATT specifications.
So it seems, there is not much to be implemented on lower levels. Anyway, BLE Mesh defines models (see: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634 ) which are used for a dedicated use case. This would be the big advantage for OH: if these models are implemented somewhere, it is very easy to autodiscover a device (light switch, actuator, room panel,…) and combine them together.
Do you recommend a way to implement? Maybe a new governor or a mesh process?