This sample has been tested on the Nordic nRF52840-PDK board, but would likely also run on the nrf52_pca10040 board.
Prior to provisioning, each button controls its corresponding LED as one would expect with an actual switch.
Provisioning is done using the BlueZ meshctl utility. Below is an example that binds button 2 and LED 1 to application key 1. It then configures button 2 to publish to group 0xc000 and LED 1 to subscribe to that group.
discover-unprovisioned on provision <discovered UUID> menu config target 0100 appkey-add 1 bind 0 1 1000 # bind appkey 1 to LED server on element 0 (unicast 0100) sub-add 0100 c000 1000 # add subscription to group address c000 to the LED server bind 1 1 1001 # bind appkey 1 to button 2 on element 1 (unicast 0101) pub-set 0101 c000 1 0 0 1001 # publish button 2 to group address c000
The meshctl utility maintains a persistent JSON database containing the mesh configuration. As additional nodes (boards) are provisioned, it assigns sequential unicast addresses based on the number of elements supported by the node. This example supports 4 elements per node.
The first or root element of the node contains models for configuration, health, and onoff. The secondary elements only have models for onoff. The meshctl target for configuration must be the root element's unicast address as it is the only one that has a configuration server model.
If meshctl is gracefully exited, it can be restarted and reconnected to network 0x0.
The meshctl utility also supports a onoff model client that can be used to change the state of any LED that is bound to application key 0x1. This is done by setting the target to the unicast address of the element that has that LED's model and issuing the onoff command. Group addresses are not supported.