You can test this example on the following devices: nRF52840, nRF52833, and nRF52832.

This example is not compatible with the nRF52810 device.

This example demonstrates how to use the Sensor model. It implements an emulated Motion Sensed sensor and shows how such a sensor can be used and controlled.

The example is composed of the following minor examples:

Sensor server: A minimalistic server that implements a Sensor server model, with the sensor value emulated and controllable by buttons on the board.
Sensor client: A minimalistic client that implements two instances of a Sensor client model. Buttons on the board can be used to send messages to the Sensor servers in order to control their cadence and request status messages.

Note: The Sensor server example can also be used together with the Light LC example.

Table of contents

Hardware requirements

You need at least two compatible development kits for this example:

One compatible development kit for the sensor client.
One or more compatible development kits for the sensor servers.

Additionally, you need one of the following for provisioning:

One compatible development kit for the provisioner if you decide to use the static provisioner example.
An iOS or Android smartphone if you decide to provision using the nRF Mesh mobile app mobile application.

See Compatibility for information about the compatible development kits.

Software requirements

Depending on the provisioning method:

If you decide to provision using a mobile application, you need nRF Mesh mobile app (iOS or Android) installed on the smartphone.
If you decide to use the static provisioner example, you need the provisioner example.

Note: Setting the Publish Period on the Sensor server when interacting with the boards is only possible if you use the mobile app for provisioning the examples.

Setup

You can find the source code of this example in the following folder: <InstallFolder>/examples/sensor

Button assignments

Sensor server:

When interacting with the boards:

You cannot use buttons on the server boards.

Instead, use the following RTT input:

RTT input	DK Button	Effect
`1`	Button 1	The mocked sensor value is decreased by 1%.
`2`	Button 2	The mocked sensor value is decreased by 10%.
`3`	Button 3	The mocked sensor value is increased by 1%.
`4`	Button 4	The mocked sensor value is increased by 10%.
`5`	-	All mesh data is erased and the device is reset.

Sensor client:

When interacting with the boards, you can use one of the following options:

RTT input (recommended): Due to a limited number of buttons on the DK board, use the following RTT input when evaluating this example:

RTT input	DK Button	Effect
`1`	Button 1	Send a descriptor get message for all properties.
`2`	Button 2	Send a descriptor get message for the Motion Sensed property.
`3`	Button 3	Send a cadence get message for the Motion Sensed property.
`4`	Button 4	Send an acknowledged cadence set message for the Motion Sensed property.
`5`	-	Send an unacknowledged cadence set message for the Motion Sensed property.
`6`	-	Send a settings get message for the Motion Sensed property.
`7`	-	Send a status get message for all properties.
`8`	-	Send a status get message for the Motion Sensed property.
`9`	-	Switches the client instance to be used for sending messages.

- Buttons: If you decide to use the buttons on the DK instead of the RTT input, you can only send descriptor get, cadence get, and acknowledged cadence set messages.

Testing the example

To test the sensor example, build the examples by following the instructions in Building the mesh stack.

After building is complete, use one of the following methods, depending on the preferred provisioning approach:

Evaluating using the static provisioner

See provisioner example testing section for detailed steps required to provision and configure the boards using the static provisioner.

Note: Using this provisioning method limits the amount of actions you can take when interacting with the boards.

Evaluating using the nRF Mesh mobile app

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:

Each server board is nRF5x Mesh Sensor Setup Server.
The client board is nRF5x Mesh Sensor Client.

The following model instances must be configured in the app for this example:

For the nRF5x Mesh Sensor Setup Server server boards: Sensor Setup Server, Sensor Server.
For the nRF5x Mesh Sensor Client client board: Sensor Client.

Once the provisioning with the mobile app is complete, you can start interacting with the boards.

Note: You can also configure the publish address of the second Sensor client model instance. To do this, repeat step 3 from binding nodes and all steps from setting publication.

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 start interacting with the examples using buttons or RTT, or both.

The publication behavior of the Sensor server depends on the following parameters:

Model Publish Period
Sensor Cadence
Current sensor value (in this case, the Motion Sensed value)

Standard behavior when no Publish Period is set

Depending on your provisioning method:

If you use the phone app, ensure that the server has no Publish Period set.
If you use the static provisioner, it is automatically ensured that there is no Publish Period set.

Regardless of the provisioning method, when no Publish Period is set, all button presses on the server will result in sensor publications. The client will print the incoming sensor status messages to RTT, where you can monitor them using the RTT Viewer on the RTT output of the server. They will also be visible as received Sensor status messages on the client.

Custom publication behavior

You can change the publication parameters to see how this will affect the publication behavior.

Note: The steps in this section require you to set the Publish Period on the Sensor server. As of now, this is only possible if you choose to provision and configure the example using the nRF Mesh mobile app.

Step 1: Set periodic publication to 10 seconds (default cadence): Set a Publish Period of 10 seconds on the server. Because a Publish Period is set, changing the sensor value does not result in sensor publications. Instead, the server publishes all sensor statuses on its periodic publication callback. The client receives publications every 10 seconds according to the Publish Period set.

Note: In this step, the cadence for the Motion Sensed property is using the default initial values. Next steps use custom cadence values.

Step 2: Set periodic publication to 60 seconds (custom cadence)

Set a Publish Period of 60 seconds on the server. Then, press Button 4 on the client. This sets the following custom cadence for the sensor:

Field	Value
`fast_period_exponent`	`7` (representing `2^7`)
`trigger_type`	`0`
`trigger_delta_down`	`1`
`trigger_delta_up`	`1`
`min_interval_exponent`	`1`
`fast_cadence_low`	`0`
`fast_cadence_high`	`49`

The fast_cadence_high value exceeds the fast_cadence_low value, so Motion Sensed values in the closed interval [fast_cadence_low (0), fast_cadence_high (49)] will cause the server's sensor publication period to be the server's Publish Period divided by 2^n, where n is the fast_period_exponent (that is, 7). This fast period is constrained to a minimum interval by min_interval.

Step 3: Set a sensor value within fast cadence region (custom cadence): Set the sensor value to 20. At the next periodic publication time, the server will find a Motion Sensed value of 20. As 20 is between 0 and 49, the server will begin to publish on a period of 60sec / 2^7 = 0.4687 sec. The client receives information about two messages per second while the motion sensor value remains between 0 and 49.

Step 4: Set a sensor value outside fast cadence region (custom cadence): Set the sensor value to 50 or higher. When this value is first published by the periodic publication on the server, the periodic publication period will be set to 60 seconds (the configured Publish Period for the server). As long as the server's publications find Motion Sensed values of at least 50, the client receives one message per minute.

Note: The client's cadence message targets the sensor identified by property_id = 0x0042 (the Motion Sensed device property). When interacting with a multi-sensor server, the client can program each sensor to a unique cadence.