1.. zephyr:code-sample:: nrf_bluetooth_mesh_onoff 2 :name: Mesh OnOff Model 3 :relevant-api: bt_mesh 4 5 Control LEDs on a mesh network using the Bluetooth Mesh OnOff model. 6 7Overview 8******** 9 10This is a simple application demonstrating a Bluetooth Mesh multi-element node. 11Each element has a mesh onoff client and server 12model which controls one of the 4 sets of buttons and LEDs . 13 14Prior to provisioning, an unprovisioned beacon is broadcast that contains 15a unique UUID. It is obtained from the device address set by Nordic in the 16FICR. Each button controls the state of its 17corresponding LED and does not initiate any mesh activity. 18 19The models for button 1 and LED 1 are in the node's root element. 20The 3 remaining button/LED pairs are in elements 1 through 3. 21Assuming the provisioner assigns 0x100 to the root element, 22the secondary elements will appear at 0x101, 0x102 and 0x103. 23 24After provisioning, the button clients must 25be configured to publish and the LED servers to subscribe. 26 27If a LED server is provided with a publish address, it will 28also publish its status on an onoff state change. 29 30If a button is pressed only once within a 1 second interval, it sends an 31"on" message. If it is pressed more than once, it 32sends an "off" message. The buttons are quite noisy and are debounced in 33the button_pressed() interrupt handler. An interrupt within 250ms of the 34previous is discarded. This might seem a little clumsy, but the alternative of 35using one button for "on" and another for "off" would reduce the number 36of onoff clients from 4 to 2. 37 38Requirements 39************ 40 41This sample has been tested on the Nordic nRF52840-PDK board, but would 42likely also run on the nrf52dk/nrf52832 board. 43 44Building and Running 45******************** 46 47This sample can be found under :zephyr_file:`samples/boards/nordic/mesh/onoff-app` in the 48Zephyr tree. 49 50The following commands build the application. 51 52.. zephyr-app-commands:: 53 :zephyr-app: samples/boards/nordic/mesh/onoff-app 54 :board: nrf52840dk/nrf52840 55 :goals: build flash 56 :compact: 57 58Prior to provisioning, each button controls its corresponding LED as one 59would expect with an actual switch. 60 61Provisioning is done using the BlueZ meshctl utility. Below is an example that 62binds button 2 and LED 1 to application key 1. It then configures button 2 63to publish to group 0xc000 and LED 1 to subscribe to that group. 64 65.. code-block:: console 66 67 discover-unprovisioned on 68 provision <discovered UUID> 69 menu config 70 target 0100 71 appkey-add 1 72 bind 0 1 1000 # bind appkey 1 to LED server on element 0 (unicast 0100) 73 sub-add 0100 c000 1000 # add subscription to group address c000 to the LED server 74 bind 1 1 1001 # bind appkey 1 to button 2 on element 1 (unicast 0101) 75 pub-set 0101 c000 1 0 0 1001 # publish button 2 to group address c000 76 77The meshctl utility maintains a persistent JSON database containing 78the mesh configuration. As additional nodes (boards) are provisioned, it 79assigns sequential unicast addresses based on the number of elements 80supported by the node. This example supports 4 elements per node. 81 82The first or root element of the node contains models for configuration, 83health, and onoff. The secondary elements only 84have models for onoff. The meshctl target for configuration must be the 85root element's unicast address as it is the only one that has a 86configuration server model. 87 88If meshctl is gracefully exited, it can be restarted and reconnected to 89network 0x0. 90 91The meshctl utility also supports a onoff model client that can be used to 92change the state of any LED that is bound to application key 0x1. 93This is done by setting the target to the unicast address of the element 94that has that LED's model and issuing the onoff command. 95Group addresses are not supported. 96 97This application was derived from the sample mesh skeleton at 98:zephyr_file:`samples/bluetooth/mesh`. 99 100See :zephyr:code-sample-category:`bluetooth` samples for details. 101