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