samples/bluetooth/mesh is not helpful

[pabigot]

samples/bluetooth/mesh lacks any description of what it actually does, or how to verify that it does anything at all.

The documentation specifies that it supports automated provisioning, and messages do show that if samples/bluetooth/mesh_provisioner is running it will be "provisioned", but on completion of provisioning there is no observable behavior between it and an unprovisioned node. Also it appears the provisioning is not preserved: on reset the node is again provisioned. Adding a second node appears to result in it using the same identify, which has no further effect except to cause unexpected xact warnings from bt_mesh_pb_adv.

I'm calling this a bug because people wanting to see how to use Zephyr for Bluetooth mesh have two options: this sample, and mesh_demo which requires tedious hard-coded provisioning. IMO samples should be useful. At a minimum more documentation should be provided to explain why this is even present. To be useful it could maybe implement something like having switches turn LEDs on or off, since the models are stubbed in.

[carlescufi]

The conclusion is that we should turn this into a basic mesh sample that provides the following functionality:

• Use the on/off service to turn on-board LEDs on and off
• Document how to provision the app and turn the LED on and off from BlueZ/mobile app

[carlescufi]

@trond-snekvik any updates on this one?

[pabigot]

@carlescufi @trond-snekvik is this expected soon (this month)?

[trond-snekvik]

Yes, I'll start it later this week.