This example demonstrates how you can use the Scene model to store and recall states of other models.
The example is composed of the Scene client minor example. It does not provide a standalone Scene server example, but instead uses one of the compatible server examples listed in Server example (model) and Client example (model).
For provisioning purposes, the example requires either the provisioner example that is provided in the Provisioner example or the nRF Mesh mobile app.
The Scene client example has a provisionee role in the network. It supports provisioning over Advertising bearer (PB-ADV) and GATT bearer (PB-GATT) and also support Bluetooth mesh Proxy Service (Server). Read more about the Proxy feature in GATT provisioning and Proxy.
Table of contents
The Scene client example has a provisionee role in the network. It implements two instances of the Scene Client model. These instances are used to store and recall the server states in a scene, and to delete the stored scenes.
There is no standalone Scene server example. Instead, other example applications showcase the Scene Server models and implement the Scene Server and Scene Setup Server models:
This is because the Scene Server models refer to the scene register table that gathers scenes (with the associated state values) from a number of elements within a node.
If you plan to evaluate using static provisioner, you need one of the following client examples that can control the state on the server example:
If you plan to evaluate using nRF Mesh mobile app, you do not need the client example, as the mobile application allows you to control server states directly from the application.
The Scene Client model is used for manipulating the scene state in the Scene Server model. For more information about the Scene models, see the Scene model documentation, Scene Server behavior documentation, and Bluetooth SIG's Bluetooth mesh model overview.
You need at least two compatible development kits for this example:
Additionally, you need one of the following for provisioning:
See Compatibility for information about the compatible development kits.
Depending on the provisioning method:
You can find the source code of this example in the following folder: <InstallFolder>/examples/scene
See the Setup section in the documentation of the server example you want to use for the source code of the server example.
RTT input | DK Button | Effect |
---|---|---|
1 | Button 1 | The Scene Store message is sent with the current scene number. |
2 | Button 2 | The Scene Recall message is sent with the current scene number. |
3 | Button 3 | The Scene Delete message is sent with the current scene number. |
4 | Button 4 | Switches the client instance used for sending. |
5 | - | Decreases the current scene number by 1. |
6 | - | Increases the current scene number by 1. |
7 | - | Send a Scene Get message to get the currently active scenes. |
8 | - | Send a Scene Register Get message to get the contents of the scene registers. |
To test the example, build both the Scene client example and the server example you want to use by following the instructions in Building the Bluetooth mesh stack.
After building is complete, use one of the following methods, depending on the preferred provisioning approach:
See provisioner example testing section for detailed steps required to provision and configure the boards using the static provisioner.
See Evaluating examples using the nRF Mesh mobile application for detailed steps required to provision and configure the boards using the nRF Mesh mobile app.
The following naming convention is used in the app:
nRF5x Mesh Scene Client
.The following model instances must be configured in the app for this example:
nRF5x Mesh Scene Client
client board: Scene Client.Once the provisioning is complete, you can start interacting with the boards.
Once the provisioning and the configuration of the client node and of at least one of the server nodes are complete, you can press buttons on the client or send command numbers using the RTT Viewer to create and recall scenes and observe how the server states change.
The following set of message types is available for this demonstration:
See LED and button assignments section for the full list of available commands.
If any of the devices is powered off and then back on, it will remember its flash configuration and rejoin the network. It will also restore values of the Scene states. For more information about the flash manager, see Flash manager.
Before storing each scene change the server examples states using client example (see corresponding client example documentation here) or nrf-mesh-mobile-app. Changing server states will allow you to visually distinguish various scenes during evaluation.
To store the states of the servers in a scene, perform the following steps:
1
or Button 1 on the client node to store these states as a scene with scene number 1.6
on the client node to change to scene number 2.1
or Button 1 on the client node to store these states as scene number 2.To recall any of the scenes stored in the previous step, use RTT input on the client node:
5
and 6
to select the scene number to recall.2
or press Button 2 to recall the scene.To get the currently active scene on the servers, use RTT input 7
on the Scene client. Observe the RTT output to see the Scene status messages.
If you use RTT input 8
on the client node, a Scene Register get message will be sent to the servers. The RTT output will list the scene register content of each server.
To delete the stored scene, use RTT input 5
and 6
to select a scene number, and then use RTT input 3
or Button 3 to delete the selected scene. Observe that the deleted scenes can no longer be recalled. They also do not show up in the scene register when you use RTT input 8
.