@vkolotov Hi Vlad,
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?