1. Light LC System Specification
1.1. Definition
Regarding Bluetooth SIG white paper named Building a Sensor-Driven Lighting Control System Based on Bluetooth Mesh:
Lighting control systems consist of one or several line-powered light sources that can be controlled via different mechanisms.
Light sources (e.g., LED modules) typically are combined with electrical components (e.g., transformers and drivers), optical components (e.g., reflectors, diffusors, and lenses), and mechanical components (e.g., housing) that are required to provide a ready-to-use product. Such a product is commonly called a luminaire and forms the basic component of a lighting control network. Each scenario described in this white paper assumes that at least one luminaire is present.
Luminaires can be controlled by switches, sensors, smartphones and tablet personal computers (PCs), or components of building automation systems:
Switches allow manual adjustment of the light level. Users can switch the light on or off, increase (dim up) or decrease (dim down) the light level, or recall specific light levels that were defined (“lighting scenes”) based on their preferences.
Sensors allow automatic adjustment of the light level based on detected parameters such as room occupancy and available light (e.g., daylight coming through windows) based on defined rules.
Smartphones and tablet PCs can be used both to control the light level (instead of using switches) and to configure the lighting control system.
Lighting control systems might also be integrated into larger-scale building automation systems, which control and monitor various functions of a building (e.g., lighting, air conditioning, hazard monitoring, and access control). Building automation systems might both monitor the status of the lighting control system (e.g., room occupancy) and request specific settings (e.g., turning on all lights in case of a fire alarm).
1.2. System Architecture
A complete Light Control System can be schematized as follow:
| Light LC System illustration |
|---|
1.3. Component Description
1.3.1. Switches
The on/off switch could control the luminaire by publishing its state (on or off) to the luminaire which subscribes to these publications. The luminaire would then react to the switch state publications by changing its own state, e.g. turning the light on or off.
The most basic lighting control scenario involves a luminaire and an on/off switch:
- The luminaire implements the Generic OnOff Server model.
- The switch implements the Generic OnOff Client model.
| Switch-Luminaire interaction |
|---|
To control a group of luminaires by using a single switch, a group address needs to be created and set as the model’s publish address.
| Switch-Luminaire group example |
|---|
Note:
Client models implemented by switches only send messages: they do not themselves have states. This is why, adding additional switches to the network doesn't create any conflicts.
Another scenario would be to have multiple switches controlling multiple luminaires that are assigned to multiple overlapping groups.
| Switch-Luminaire with multiple groups example |
|---|
1.3.2. Dimmer
A dimmer can be used to control the light level if it implements the Light Lightness Client model (often in conjunction with the Generic Power OnOff Client model used to control the initial light level at power up). To enable power-up behavior to be specified, a luminaire requires the Generic Power OnOff Server model and the Generic Power OnOff Setup Server model. The Generic Power OnOff Server model extends the Generic OnOff Server model, so the Generic OnOff Server model also needs to be implemented. The power-up behavior is determined by the Generic OnPowerUp state, which can be set to one of the following modes:
- Off: When a luminaire is powered up, its light level is set to 0 percent.
- Default: When a luminaire is powered up, its light level is set to a desired default value.
- Restore: When a luminaire is powered up, it restores the same light level it had when the power outage occurred.
A dimmer can also be used to control the light level if it implements the Generic Level Client model.
On his side, the luminaire needs to implement the Generic Level Server model.
The Light Lightness Server model (which extends the Generic Power OnOff Server model and the Generic Level Server model) and the Light Lightness Client model introduce the Light Lightness Linear state: the lightness on a linear scale. And the Light Lightness Actual state: the lightness on a perceptually uniform lightness scale. The Light Lightness Linear state is bound to the Light Lightness Actual state, which in turn is bound to the Generic Level state. This arrangement helps to provide a smooth, dimming experience that is friendly to the human eye.
Note: if a device implements the Light Lightness Client model, the device can only control the light level.
1.3.3. Sensor
A connected lighting network that is sensor-driven is capable of tracking changes in the environment and responding to those changes.
Sensors are defined in the Mesh Model Specification.
For occupancy sensing, there are different types of sensing devices available on the market: motion sensors, presence sensors, or also people-counting sensors that can estimate the number of persons occupying a given space.
These three different types of sensors report different values; Bluetooth mesh is designed to support all of them.
From the perspective of the publish-subscribe paradigm, sensors are not much different from on/off switches or dimmers.
Sensors introduce a certain degree of automation to the system. They automatically publish information, and the luminaires respond to that information accordingly.
To be able to respond to sensor information, a luminaire needs to implement a lightness controller, which is manifested by the inclusion of the Light LC Server model.
| Sensor Client Server interaction |
|---|
1.3.4. Controller
The Light Lightness Controller controls the luminaire’s light level based on information obtained from occupancy and ambient light sensors, it implements a Light LC Server Model.
The Light Lightness Controller can be in either the On or Off state.
When the Light Lightness Controller is off, it does not control the lighting installation.
When turned on, the Light Lightness Controller enters the Standby mode, where it is ready to respond to events from sensors or switches.
The events trigger the progression of the Light Lightness Controller through several phases, as illustrated below:
| Light LC phases |
|---|
1.3.5. Component Summary
The following tables summarize the models required by each component and by the luminaire to manage the different scenarios:
Luminaire - On/Off Switch:
Luminaire – Dimmer:
Luminaire – Sensor:
Luminaire -Sensor, with Configuration Device (smartphone):
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 |
|---|
