1#### Bluetooth: Mesh Generic OnOff, Generic Level, Lighting & Vendor Models 2 3##### Overview 4******** 5 6This is a application demonstrating a Bluetooth mesh node in 7which Root element has following models 8 9- Generic OnOff Server 10- Generic OnOff Client 11- Generic Level Server 12- Generic Level Client 13- Generic Power OnOff Server 14- Generic Power OnOff Setup Server 15- Generic Power OnOff Client 16- Light Lightness Server 17- Light Lightness Setup Server 18- Light Lightness Client 19- Light CTL Server 20- Light CTL Setup Server 21- Light CTL Client 22- Vendor Model 23 24And Secondary element has following models 25 26- Generic OnOff Server 27- Generic OnOff Client 28- Generic Level Server 29- Generic Level Client 30- Light CTL Temperature Server 31 32Prior to provisioning, an unprovisioned beacon is broadcast that contains 33a unique UUID. Each button controls the state of its 34corresponding LED and does not initiate any mesh activity 35 36##### Associations of Models with hardware 37************************************ 38For the nRF52840-PDK board, these are the model associations: 39 40* LED1 is associated with generic OnOff Server's state which is part of Root element 41* LED2 is associated with Vendor Model which is part of Root element 42* LED3 is associated with generic Level (ROOT) / Light Lightness Actual value 43* LED4 is associated with generic Level (Secondary) / Light CTL Temperature value 44* Button1 and Button2 are associated with gen. OnOff Client or Vendor Model which is part of Root element 45* Button3 and Button4 are associated with gen. Level Client / Light Lightness Client / Light CTL Client which is part of Root element 46 47States of Servers are bounded as per Bluetooth SIG Mesh Model Specification v1.0 48 49After provisioning, the button clients must 50be configured to publish and the LED servers to subscribe. 51If a server is provided with a publish address, it will 52also publish its relevant status. 53 54##### Requirements 55************ 56This sample has been tested on the Nordic nRF52840-PDK board, but would 57likely also run on the nrf52_pca10040 board. 58 59 60##### Running 61************ 62 63Provisioning is done using the BlueZ meshctl utility. In this example, we'll use meshctl commands to bind: 64 65- Button1, Button2, and LED1 to application key 1. It then configures Button1 and Button2 66 to publish to group 0xC000 and LED1 to subscribe to that group. 67- Button3, Button4, and LED3 to application key 1. It then configures Button3 and Button4 68 to publish to group 0xC000 and LED3 to subscribe to that group. 69 70``` 71discover-unprovisioned on 72provision <discovered UUID> 73menu config 74target 0100 75appkey-add 1 76bind 0 1 1000 77bind 0 1 1001 78bind 0 1 1002 79bind 0 1 1003 80sub-add 0100 c000 1000 81sub-add 0100 c000 1002 82pub-set 0100 c000 1 0 5 1001 83pub-set 0100 c000 1 0 5 1003 84``` 85 86The meshctl utility maintains a persistent JSON database containing 87the mesh configuration. As additional nodes (boards) are provisioned, it 88assigns sequential unicast addresses based on the number of elements 89supported by the node. This example supports 2 elements per node. 90 91The meshctl target for configuration must be the root element's unicast 92address as it is the only one that has a configuration server model. If 93meshctl is gracefully exited, it can be restarted and reconnected to 94network 0x0. 95 96The meshctl utility also supports a onoff model client that can be used to 97change the state of any LED that is bound to application key 0x1. 98This is done by setting the target to the unicast address of the element 99that has that LED's model and issuing the onoff command. 100Group addresses are not supported. 101 102