1. BLE-Mesh Lighting Example
1.1. Presentation
This page describes how to quickly handle a first ST BLE-Mesh example.
Some of the following information can be retrieved in the linked video: STM32WB BLE MESH hands-on ST BLE-Mesh examples can be found on latest STM32Cube_FW_WB package:
BLE-MeshLightingPRFNode project generates a basic Node supporting Proxy-Relay-Friend features, this project is the easier to handle and have a first approach of ST BLE-Mesh solution.
BLE-MeshLightingLPN project generates a basic Low Power Node, which requires a Friend Node into the network to receive messages, see Friendship page for more information.
BLE-MeshLightingProvisioner project generates a basic node managing ST proprietary solution of Embedded Provisioner, this Node can configurate itself and provision other nodes into the mesh network.
1.2. Functioning
For the project description, we focus on the BLE-MeshLightingPRFNode project as it is the simplest demonstration to handle.
This project demonstrates STM32WB application capabilities using ST BLE-Mesh with basic models.
1.3. Getting Started
For a first test of the ST BLE-Mesh solution, BLE-MeshLightingPRFNode project should be the best demonstration to handle.
1.3.1. Requirements
Software and System requirements Software and System requirements are listed in the ST BLE-Mesh Application Note: AN5292 - How to build a Bluetooth® Low Energy mesh application for STM32WBx5 line microcontrollers
Hardware requirements A Nucleo board ( STM32WB55RG) is necessary to setup the demonstration.
More details about the board and other hardware required are available in the Application Note: AN5292 - How to build a Bluetooth® Low Energy mesh application for STM32WBx5 line microcontrollers Or in the online ST BLE-Mesh MOOC: STM32WB Networking – BLE MESH MOOC
2. Light Control Scenarios
The idea of the Light Lightness Controller is to add intelligence to a luminaire. Without the Light Lightness Controller, a luminaire based on the Light Lightness Server is only capable of reacting to messages sent by client models; it cannot control the lightness on its own.
The Light Lightness Controller allows a luminaire to understand messages published by sensors and adjust the lightness output accordingly.
In common applications, the inclusion of the Light Lightness Controller within a luminaire can eliminate the need for a central “control box,” which is typically present in legacy lighting control systems.
With the Light Lightness Controller, the luminaires themselves are intelligent and can form a lighting control system without the need for a centralized controller.
A luminaire with an integrated controller is a two-element Bluetooth mesh node. The controller’s Light LC Server controls the lightness of the luminaire that is implementing the Light Lightness Server model through a binding between the Light LC Linear Output state and the Light Lightness Linear state.
Each of the two elements can receive messages independently, so the luminaire either can be controlled by the controller, or it can directly receive messages from other devices.
This arrangement is illustrated below where the light level of the luminaire is controlled by connecting the Light LC Linear Output state of the controller with the Light Lightness Linear state of the luminaire:
| Luminaire Node illustration |
|---|
The controller has a total of six inputs. These include three control inputs (Light OnOff, Occupancy, Ambient LuxLevel); two mode inputs (Mode, Occupancy Mode); and the internally generated Timer. The output from the Light LC controller is the Light LC Linear Output state, which is conditionally bound to the luminaire’s Light Lightness Linear state. The Mode input is represented by the Light LC Mode state, which is a binary state that determines whether the controller is on or off. The Light LC Mode state can be controlled by Light LC Mode messages. When the controller is off, the binding between the controller’s Light LC Linear Output state and the luminaire’s Light Lightness Linear state is disabled, and the controller does not control the lightness of the luminaire. Instead, the lightness can be controlled by the Light Lightness Client model that is implemented.
2.1. Switch Control
In this scenario, switches are used to turn the luminaires on for a specified period of time. After this time expires, the luminaires turn off, although a switch can be used again in the meantime to restart the timer. To implement the switch control scenario, a relationship between the switch and the controller needs to be established. A luminaire with an integrated controller has two separates On/Off inputs (one on each element):
- The first On/Off input allows for controlling the luminaire directly, bypassing the controller.
- The second input controls the Light LC Light OnOff state (bound to the second instance of the Generic OnOff state).
This is the input that a switch needs to use to enable the switch control scenario. The switch needs to implement the Light LC Client model, which publishes to the address to which the controller’s Light LC Server model is subscribed. Alternatively, the switch implementing a Generic OnOff Client model may publish to the address to which the controller’s Generic OnOff Server model is subscribed.
| Switch control lightness phases |
|---|
2.2. Vacancy Sensing
This scenario introduces occupancy sensors to turn off the light when the area is vacant, although switches are still used to trigger the controller.
Like the switch control scenario, pressing a switch turns luminaires on for a predefined period of time.
However, in this scenario, the controller is also processing data from occupancy sensors.
Each occupancy detection restarts the Run timer, so the light stays at the configured level if occupancy has been detected within the most recent period defined by the timer.
A relationship between a switch and the controller needs to be established. In addition, the controller’s configuration must allow for processing sensor data received through the Occupancy input. The input is represented by the Light LC Occupancy state and accepts data from one or more sensors reporting the Occupancy Property via Sensor Status messages.
| Vacancy sensing lightness phases |
|---|
To be able to process the sensor data, the controller (the Light LC Server model on a luminaire) needs to be subscribed to the address to which the sensor (the Sensor Server model on the sensor device) publishes.
Finally, to enable the vacancy sensing scenario, the Light LC Occupancy Mode state, which represents the Occupancy Mode input, must be set to zero.
This way, the controller won’t transition from a standby state when occupancy is reported; only the switch can trigger this transition.
2.3. Occupancy Sensing
This scenario is very similar to vacancy sensing in its implementation. The only difference is that occupancy sensors both trigger the controller and keep it running based on occupancy detection.
The outcome is that luminaires turn on automatically whenever sensors detect occupancy. This also triggers the Run timer, which restarts whenever sensors report occupancy again. Once the timer expires and no occupancy is detected, luminaires fade to the Prolong phase and then to the Standby phase.
| Occupancy sensing lightness phases |
|---|
3. Demonstration
3.1. Technical Description
This project demonstrates STM32WB application capabilities using BLE-Mesh solution and gives example on how to setup a quick luminaire system by adding some small components (sensor, LED Bar).
It also shows how to support multi elements and different models:
- Generic OnOff
- Light Lightness
- Light LC
- Light HSL
- Sensor
and the setup of a Controller element, implementing the Light LC model, and controlling the lamp on sensor message reception.
| Project overview |
|---|
Three STM32WB55 boards, a Blinkt LED bar and one PIR Sensor (EKMB1103111) are used for this setup:
- 1 lamp which support Generic OnOff, Generic Level, Light Lightness and Light HSL server models in a first element, and Light LC server on the second element;
- 1 Sensor managing Sensor Server model;
- 1 Color Dimmer which supports Light HSL and Light LC Client.
The sensor, dimmer and lamp are Proxy and Relay nodes, and are flashed on STM32WB55 Boards. The Sensor node board is connected to a PIR Sensor. The Lamp node board is connected to the LED bar.
| Project details |
|---|
3.2. Demonstration Setup
3.2.1. Device Requirement
Required material to setup the demonstration is the following:
- 3 STM32WB55RG : as temperature information boards
- 1 Blinkt! LED: RGB LED bar
- 1 EKMB1103111 : PIR Sensor
- 1 Smartphone with Android or iOS
Click on Component Hyperlink to see resellers.
3.2.2. BLINKT LED Connection
Connect the LED bar to CN7 connector (left side of the board). The rounded edges of the LED bar must be placed towards the inside of the board. Let 7 Pins free from the beginning of CN7 connector, the LED are connected from PIN15.
| LED bar connection |
|---|
3.2.3. PIR Sensor Connection
Connect the PIR Sensor to CN7 connector or the board representing the Sensor Node:
- VDD: CN7 - Pin 16
- GND: CN7 - Pin 20
- Out: CN7 - Pin 3
| PIR Sensor connection |
|---|
3.2.4. Software patch
The PIR Sensor, ColorDimmer and Lamp&Controller projects are not included in STM32Cube_FW_WB_V1.12.0 package as it required personalized Drivers and external devices (PIR Sensor, LED bar).
A patch is available to include these projects their dependencies to the Firmware package v1.12.0: STM32Cube_FW_WB_BLEMesh_PIR_Sensor_DEMO_V1.12.0.exe
Launch this .exe file and follow the instructions.
In the Select Destination Location step, select the path to your Firmware Package.
Note: be careful to remove the \New Folder added automatically at the end of the path you selected
3.2.5. Code Modification
Before building the Lamp and Controller project, ensure to disable the ENABLE_MODEL_BINDING macro in mesh_cfg.h.
/******************************************************************************/
/*
Define the Macros for Enabling/disabling the binding of data between the Generic
and Light model.
@ define the Macro for enabling the binding
@ Undefine or comment the macro for disabling the binding.
*/
/******************************************************************************/
//#define ENABLE_MODEL_BINDING //Disable Binding to not switch Light LC FSM off
Without this modification the Light LC state machine of the Controller is switched off each time the node receives another model’s command (Generic, HSL, …).
Note: Don’t forget to enable this macro before building the other projects as Dimmer and PIR Sensor.
3.3. Demonstration Handle
3.3.1. Android Application Interfaces
| ST BLE Mesh Android application interfaces |
|---|
3.3.2. Handle
1. Flash your boards with the different node projects.
Ensure your boards are un-provisioned by pressing RESET (1) and SW1 (2) buttons simultaneously, release RESET and keep SW1 pressed until the LED1 (3) is blinking:
| Nucleo unprovisioning process |
|---|
2. Launch the Smartphone application and provision the different nodes:
Lamp and Controller Node:
| Lamp and Controller Node provisioning |
|---|
Dimmer Node:
| Dimmer Node provisioning |
|---|
Sensor:
| Sensor Node provisioning |
|---|
3. Rename the different Nodes and Elements (optional):
| Node renaming |
|---|
4. Publication address Summary:
| Publication address summary |
|---|
5. Activate Light LC Mode:
This allows the Controller to switch the Light On when receiving Sensor data.
If the Light LC Mode is Off, the controller can't drive the Lamp.
| Light LC interface |
|---|
Note: You can either activate the light LC Mode with a long press on the SW1 button of the Dimmer Node.
| Nucleo SW1 button |
|---|
6. Modify Light Color Value:
From the smartphone:
| HSL interface |
|---|
Or from the Dimmer Node:
Pressing SW1 button switch the color values of the lamp between the below list:
- red
- yellow
- green
- cyan
- blue
- purple
| Nucleo SW1 button |
|---|
7. Switch the Light On:
From the Smartphone:
| Light On/Off interface |
|---|
From the Sensor Node: The Light is automatically switched On when presence is detected by the PIR Sensor, and the Light LC Mode is activated on Controller. When no presence is detected, the Light progressively switches off following the below graph.
| Sensor Node |
|---|
3.3.3. Summary
| Light LC demonstration summary |
|---|
