Name Date Size #Lines LOC

..--

src/H25-Apr-2025-691414

README.mdH A D25-Apr-20253.2 KiB8061

pkg.ymlH A D25-Apr-20251.3 KiB3516

syscfg.ymlH A D25-Apr-20251.5 KiB5224

README.md

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