SILICON LABS AN1299 Bluetooth Mesh Lighting Demo User Guide

SILICON LABS AN1299 Bluetooth Mesh Lighting Demo

The Bluetooth mesh SDK comes with an example project that creates a wireless network of lights and switches using Bluetooth mesh technology. The example assumes usage of Silicon Labs WSTKs for switches and lights and an Android or iOS mobile phone for provisioning and controlling the network. In this document, we discuss the basics of Bluetooth mesh required to understand the example, and walk through key aspects of the application source code. This document assumes you have read QSG176: Bluetooth Mesh SDK v2.x Quick-Start Guide, installed the Bluetooth mesh SDK, and successfully run the examples.

Bluetooth LE and Mesh Stacks and Supported Topologies

KEY FEATURES

•  Short introduction to Bluetooth mesh
•  Lighting example application description and code walkthrough
• Silicon Labs Bluetooth mesh mobile application

Introduction

This document explains the Bluetooth mesh lighting demo, installed as part of the Bluetooth mesh SDK. Most of the documentation focuses on the example application and its usage flow, explaining key parts of the source code and the Silicon Labs Bluetooth Mesh mobile application. This document also introduces some concepts of the specification that are important for understanding the example. The following subsections briefly go through the relevant aspects of the Bluetooth mesh technology. Section 2 Bluetooth Mesh Lighting Demonstration describes the features and functions of the Lighting Demonstration, section 3 Network Analyzer describes using Network Analyzer for packet capture, and section 4 Bluetooth Mesh Stack and Application for Smartphones focuses on the mobile application.

Bluetooth Mesh
Bluetooth mesh is a new topology available for Bluetooth LE devices and applications. Previously Bluetooth devices have been using point-to-point connectivity or broadcasting topologies to communicate with other devices. Bluetooth mesh extends that and allows both many-to-many device communications and using Bluetooth devices in a mesh topology. This enables multi-hop communications between Bluetooth devices and much larger-scale Bluetooth device networks than have been possible previously.
Bluetooth mesh uses Bluetooth LE advertising channels to send and receive messages between the Bluetooth mesh nodes, but it can also use Bluetooth connections and GATT services to communicate with devices that do not natively support Bluetooth mesh. Bluetooth mesh also uses its own security architecture, which is separate from the normal Bluetooth LE security architecture, although the same AES-CCM 128-bit and Elliptic Curve Diffie Hellman (ECDH) security algorithms are used. Bluetooth mesh also defines its own application layer called mesh model which is different than the GATT-based profiles and services that non-mesh Bluetooth LE devices use. The new application layer was defined to address the requirements and needs of mesh- based topologies and also to make Bluetooth mesh a full stack solution and enable interoperable mesh devices to be built.

 Bluetooth Mesh Network Roles and Node Features

The Bluetooth mesh network typically consists of multiple nodes. All nodes can transmit and receive mesh messages, but they can optionally also support one or more additional features. If a node does not implement any of the additional features, it is considered just a node. Various node types are illustrated in the following figure. Node Types
The four types of specified node features are as follows:

Proxy feature: Enables message proxy between Bluetooth mesh and GATT, and enables devices such as smartphones to connect to Bluetooth mesh.

Relay feature: Relays messages to extend the range and scale of a Bluetooth mesh network.

Friend feature: Implements an additional message cache to support nodes with the low power feature.

Low power feature: Allows sleeping and polling of messages from friend nodes at known time intervals.
For further information on these features and Bluetooth mesh technology, please go to the Silicon Labs Bluetooth mesh learning center.

Provisioning
Provisioning refers to the operation where devices that are not part of any Bluetooth mesh network are transformed into nodes that are part of one or more Bluetooth mesh networks. For example, provisioning happens when a new light bulb is installed and taken into use, so it can be controlled by switches or dimmers. Provisioning is mainly a security process where the first level security keys are generated by the provisioner and transferred to the device that is being provisioned to make it part of a Bluetooth mesh network. The provisioning process begins when a device starts to send unprovisioned Bluetooth beacon packets and the provisioner receives them. The provisioner then initiates the provisioning process, the devices exchange public keys, and both generate session keys. The session keys are used to secure the session, in the transfer of the actual network key, and the rest of the provisioning process. After provisioning, each device, now a node in the network, has the network key, a security parameter called the IV index, and its unicast address.

Publish and Subscribe
In Bluetooth mesh, communication to a group of devices is typically implemented through a publish and subscribe mechanism. This is an easy-to- understand concept which also simplifies the setup of Bluetooth mesh networks and adding and reconfiguring nodes. Usually the Bluetooth mesh nodes are configured into groups, which may represent their physical location (kitchen or living room) or specific function (lights or window coverings). Usually the devices are also controlled as groups, so the same message is sent to all devices in a group. To accomplish this functionality, Bluetooth mesh uses a concept called publish – subscribe, where nodes, such as lights, subscribe to messages groups and nodes, like switches, publish messages to those groups. At the network layer, each group is assigned a group address, and multicast messaging is used to send the messages to all devices in a specific group. Publish and Subscribe
The benefit of publish and subscribe is that, when a new node is added or an existing node is removed or replaced, only that node needs to be provisioned and configured.

Bluetooth Mesh Lighting Demonstration

Requirements

• Simplicity Studio
• Bluetooth Mesh SDK 2.1.0 or later, distributed through Simplicity Studio 5.
• The pre-built demo binaries and source code are included in the SDK.
•  Simplicity Studio has a network analyzer capable of capturing and decoding Bluetooth mesh packets.
•  The actual code development can be done with Simplicity Studio, IAR EWARM, or command line tools.
• Silicon Labs Bluetooth mesh mobile application
•  Available for both iOS and Android.
• Used for discovering and provisioning devices over GATT.
•  Includes network, group, and publish-subscribe setup.
• Allows device configuration and control.
• Requires iOS 10 or later.
•  Requires Android 6 (API23) or later.
• For the full experience, at least three Silicon Labs Blue Gecko SoC Wireless Starter Kits are needed.
•  2 kits are used as lights with proxy feature.
•  1 kit is used as a switch.
•  EFR32BG12, EFR32MG12, EFR32BG13, EFR32MG13, EFR32xG21, and EFR32xG22 SoCs as well as the BGM13P, BGM13S, BGM220P, and BGM220S modules support Bluetooth mesh software. Note that EFR32xG22, BGM220P, and BGM220S only support limited Bluetooth mesh features.

See QSG176: Bluetooth Mesh SDK v2.x Quick-Start Guide for more information on obtaining required hardware and software, and running the demonstration. The demonstration setup can, in principle, consist of any number of switch nodes and light nodes. A single switch node can control an arbitrary number of light nodes by sending commands to a group address. Similarly, a light node can receive on/off commands from multiple switches.

 Mesh Network Implementation

The demonstration implementation process can be divided into four main phases as follows:

1. Unprovisioned mode – After the demo firmware is installed, the device starts in unprovisioned mode.
2. Provisioning – The devices are provisioned to a Bluetooth mesh network and network security is set up.
3.  Configuration – The group, publish and subscribe, and application security are configured.
4.  Normal operation – The light node(s) can be controlled by the switch node(s) and the smartphone application.

In the first phase, all the devices are unprovisioned and transmitting unprovisioned beacons. They do not have any network keys or application keys configured, and publish and subscribe settings are not set. In this state, the devices are simply waiting for the provisioner to assign them into a Bluetooth mesh network and to configure publish and subscribe and mesh models. In this state, the devices can be detected by the smartphone application. In the provisioning phase, the provisioner adds lights and switches to the Bluetooth mesh network. A network key is generated and distributed to the nodes, and each node is assigned a unicast address. In the configuration phase, the provisioner configures groups, publish and subscribe settings, application- level security, and mesh models. After provisioning and configuration, the Bluetooth mesh network is operational, and switches can be used to control the lights. The WSTK switch’s buttons can be used to control all the lights in a group. The same functionality can be done with the smartphone application, and it can also control individual lights using unicast addressing.

Code Walkthrough

The Bluetooth mesh SDK includes light and switch example projects, named Bluetooth Mesh – SoC Light and Bluetooth Mesh – SoC Switch. Both examples are implemented using the same event-driven architecture that is used in plain Bluetooth (non-mesh) applications. For information about Bluetooth C application development, see UG434: Silicon Labs Bluetooth® C Application Developer’s Guide for SDK v3.x.

Unprovisioned Mode, Provisioning, and Configuration
In unprovisioned mode, both light and switch examples behave the same way. The unprovisioned device simply starts sending unprovisioned beacons and waits for a provisioner to provision and configure it. After receiving the system_boot event (sl_bt_evt_system_boot_id), the application checks if a button is pressed. If yes, it calls the function sl_btmesh_initiate_full_reset(), which halts the system and performs a factory reset by erasing PS storage. The factory reset is also done after receiving a node_reset event (sl_btmesh_evt_node_reset_id). If no button is pressed, then the name of the device is set based on the Bluetooth address, and the function sl_btmesh_node_init() is called to initialize the Bluetooth mesh node stack. The event sl_btmesh_evt_node_initialized_id indicates that the Bluetooth mesh node stack initialization is complete. When this event is raised, the callback function sl_btmesh_on_provision_init_status() is called to provide information about the node status. The application first checks the provisioning status. If the node is not provisioned (the default state when the device is first powered up after programming), then the application starts unprovisioned beaconing by calling sl_btmesh_node_start_unprov_beacon-ing(). The API sl_btmesh_node_start_unprov_beaconing takes one parameter (bearer) that selects which bearers are used (PB-ADV, PB-GATT, or both). In this example, both bearers are used. Because the PB-GATT bearer is enabled, the device will begin advertising its provisioning GATT service. This allows the smartphone application to detect unprovisioned nodes. When unprovisioned beaconing has been started, the application waits for the provisioner (in this case, the smartphone app) to start provisioning. The start of provisioning is indicated with the event sl_btmesh_evt_node_provisioning_started_id. When this event is raised, the callback function sl_btmesh_on_node_provisioning_started() is called. During provisioning, no actions are required from the user application. The Bluetooth mesh stack automatically handles network key configuration and other operations. Both the light and the switch application simply start blinking the two LEDs on the WSTK to indicate that provisioning is in progress. Then they wait for the event sl_btmesh_evt_node_provisioned_id that indicates provisioning is complete. When this event is raised, the callback function sl_btmesh_on_node_provisioned() is called. Life Cycle of the Application
The next step after provisioning is configuration of the node. As explained in QSG176: Bluetooth Mesh SDK v2.x Quick-Start Guide, the smartphone app is used to configure a node either as a switch or a light and assign it to a group. The configuration procedure consists of following steps:

• Provisioner distributes an application key to the node.
•  The application key is bound to the selected Bluetooth mesh model.
• Publish address and settings are configured.
•  Subscribe address and settings are configured.

The configuration phase is mostly handled between the Bluetooth mesh stack and the provisioner and it does not require any involvement from the user application in the node. The following events are generated by the stack to give status information about the ongoing configuration:

• sl_btmesh_evt_node_key_added_id: generated when the provisioner has sent a new key (network or application)
•  sl_btmesh_evt_node_model_config_changed_id: indicates that the provisioner has modified configuration of the local model (either publish or subscribe settings changed)

Up to this point, the code in the examples Bluetooth Mesh – SoC Light and Bluetooth Mesh – SoC Switch is almost identical.

Switch Node Example
This section describes basic operation of the Bluetooth Mesh – SoC Switch example. It is assumed that the node is already provisioned and publish – subscribe settings have been configured by the smartphone app. The switch node has one simple task: listen for push-button presses and, based on the button press length, control the brightness, color temperature, or on/off state of the lights in the group or recall previously stored scenes. Short button presses (less than 250 ms) are used to adjust light brightness up (PB1) and down (PB0). Medium button presses (more than 250 ms and less than 1 s) are used to adjust light color temperature up (PB1) and down (PB0). A long press (more than 1 s and less than 5 s) turns the light on (PB1) or off (PB0). A very long press (more than 5 s) recalls scene number 1 (PB0) or scene number 2 (PB1). The on/off control uses the Generic On Off Client model, the brightness control uses the Light Lightness Client model, the color temperature control uses the Light CTL Client model, and the scene recalls use the Scene Client model (see the Bluetooth Mesh Model specification for more details on the Scene model). The switch example also demonstrates the Low Power Node (LPN) feature. When the switch is provisioned into the network, it will start looking for a friend so that it can enter low-power mode. When a friendship is established, the switch can go to deep sleep, and it will wake up periodically to poll the friend node for any incoming messages.
Upon receiving the sl_btmesh_evt_node_initialized_id event, the Light CTL Client, the Lighting Client, the Scene Client, and the mesh library are initialized. The Low Power Node (LPN) feature is then initialized and configured. After the LPN feature is initialized, the callback function sl_btmesh_lpn_on_init() is called and the application displays “LPN on” on the WSTK LCD. The LPN configuration has five parameters: lpn_queue_length, lpn_poll_timeout, lpn_receive_delay, lpn_request_retries, and lpn_retry_interval. The settings of these parameters are defined in sl_btmesh_lpn_config.h as LPN_MIN_QUEUE_LENGTH, LPN_POOL_TIMEOUT, LPN_RECEIVE_DELAY, LPN_REQUEST_RETRIES, and LPN_RETRY_INTERVAL, respectively. After that, the node starts finding a friend node. The LPN feature status is displayed on the WSTK LCD display.
The LPN feature is mostly implemented in the mesh stack, so only a few informative events can be raised to the application through corresponding callback functions:

•  sl_btmesh_lpn_on_friendship_established: A friendship was successfully established. The application displays “LPN with friend” on the WSTK LCD.
• sl_btmesh_lpn_on_friendship_failed: The Friendship establishment failed. The application displays “No friend” on the WSTK LCD, and the node tries to establish a friendship again in 2 seconds.
• sl_btmesh_lpn_on_friendship_terminated: The friendship was terminated for some reason. The application displays “Friend lost” on the WSTK LCD, and the node tries to establish a friendship again in 2 seconds.

If a GATT connection is opened, the friendship is terminated and the LPN is de-initialized. In this case, the callback function sl_btmesh_lpn_on_deinit() is called, and the application displays “LPN off” on the WSTK LCD. After all GATT connections are closed, the LPN feature is re-initialized. The sl_btmesh_change_lightness() function changes the lightness level and sends its value to the server for short button presses. Short presses are used to adjust light brightness up and down. The application sends a request using the Light Lightness model. The last level that has been set is stored in a variable (type uint16), and the level is adjusted up or down each time a short button press is detected.

Sending a single light lightness request is implemented in function send_lightness_request(), which is very similar to the send_on-off_request() that is used for on/off requests. Both of these use the same API mesh_lib_generic_client_publish() to publish the request. The differences are in the model ID that is passed as argument and the parameter data type. The sl_btmesh_change_temperature() function changes the color temperature and sends its value to the server for medium button presses. Medium presses are used to adjust light color temperature up and down. The application sends a request using the Light CTL model. The last temperature that has been set is stored in a variable (type uint16), and the temperature is adjusted up or down each time a medium button press is detected. Sending a single light CTL request is implemented in function send_ctl_request(), which is very similar to send_lightness_re-quest() that is used for light brightness requests. Both of these use the same API mesh_lib_generic_client_publish() to publish the request. The differences are in the model ID that is passed as argument and the parameter data type.
The sl_btmesh_change_switch_position() function changes the switch position and sends its value to the server for long button presses. For each long button press, the application publishes three consecutive on/off requests to the group address that has been set by the smartphone app. The request is sent multiple times for increased reliability. Note that it is the application’s responsibility to choose a suitable strategy for reliable communications. In this example, multiple application message transmissions were chosen. Retransmissions can also be configured to be added automatically at the network level. Sending a single on/off request is implemented in the function send_onoff_request(). A soft timer is used to trigger three calls to send_onoff_request() with a 50 ms delay between each call. The mesh stack API used to send one on/off transaction is mesh_lib_generic_client_publish(). This is a common API used to publish data for several client models. It is not limited to the generic on/off client only. For example, publishing data as a generic transition time client would be done using the same API. The first parameter model_id selects which model is being used. In addition to the desired on/off status, the publish API has some additional parameters such as transaction identifier, transition time, and delay. The transaction identifier is a running number that is incremented for each transaction. In this example, each on/off state change triggers three consecutive on/off requests. The transaction identifier is the same for each of these requests so that, at the receiving end, duplicate requests can be filtered out. In other words, all three published messages are part of the same transaction, and they will trigger only one event at the receiving light node. The delay parameter can be used to indicate that the on/off transition should not be executed immediately but after a given delay. In this example, the delay parameter is set to values of 100 ms / 50 ms / 0 in the first, second, and third request, respectively. The purpose is to ensure that all lights in the target group change their state simultaneously, regardless of which of the three on/off requests was captured on the receiving side. The sl_btmesh_select_scene() function selects the scene and sends its value to the server for very long button presses. Very long presses are used to recall scenes. The application sends a request using the Scene Client model.
Sending a single scene recall request is implemented in function send_scene_recall_request(), which is similar to other requests. The difference is that it uses a dedicated API sl_btmesh_scene_client_recall() for publishing. This function is generally used for sending scene recall requests. If the destination address is set to the prohibited address 0, the function publishes the recall message. The application code that implements the light switch functionality is relatively simple because many aspects are automatically handled by the mesh stack. For example, the switch node does not need to know anything about the light nodes that it is controlling. Any number of light nodes can be subscribed to the on/off requests that are published by the switch node. The switch node does not need to know the group address that has been configured by the provisioning application. It simply publishes the on/off requests using the API mesh_lib_generic_client_publish(), and the stack automatically sends the requests using the group address that has been configured by the provisioner.

Light Node Example
This section describes basic operation of the Bluetooth Mesh – SoC Light example. It is assumed that the node is already provisioned and that the publish and subscribe settings have been configured by the smartphone app. The main feature of the light node is that the development kit LEDs are turned on or off based on the requests that are received from switch nodes or from the smartphone application. The brightness of the LEDs can also be controlled. The On/off control is based on the Bluetooth mesh Generic On Off model, and the brightness control is based on the Light Lightness model. The Light CTL model supports color temperature requests. Color temperature changes are shown on the WSTK LCD display. The light node also supports the friend feature. It can establish a friendship with a low-power switch node in the network so that the switch node can enter low-power mode.
The light node supports the following states:

• Generic On Off
• Generic Level
•  Generic On Power Up
•  Generic Default Transition Time
• Light Lightness
• Light CTL
• Scenes
• All Light LC states
• All Light LC Property states

Upon receiving the sl_btmesh_evt_node_initialized_id event, the Lighting Server, the Light CTL Server, the Light LC Server, the Scene Server, the Scheduler Server, the Time Server, and the mesh library are initialized. The mesh library is an adaptation layer between the mesh stack and the application code that enables using multiple models with a small set of generic API calls. To support all the states listed above, the light node must store its internal state permanently so that it is preserved over reboots and power cycles. The Lighting Server holds Generic and Light Lightness states in the lightbulb_state struct. The Light CTL Server holds Light CTL states in the lightbulb_state struct. The Light LC Server holds Light LC states in the lc_state struct and Light LC Property states in the lc_property_state struct. The state information is also held in the stack. The light state initialization is implemented in sl_btmesh_lighting_server_init() and sl_btmesh_ctl_server_init(). The On Power Up state enables configuration of the default state after power is applied to the light node. The possible settings are listed below.

The transition time model makes it possible to configure how long it takes for the light to transition from one state to another. The lightbulb_state struct in the Lighting Server contains the following fields.

from -32768 to 32767)
pri_level_target| Target generic level on primary element

The lightbulb_state struct in the Light CTL Server contains the following fields.

20000. temperature_target| Target color temperature
       temperature_default| Default color temperature
       ---|---
       temperature_min| Minimum color temperature
       temperature_max| Maximum color temperature
       deltauv_current| Current value of delta UV (possible values from -32768 to

20001. deltauv_target| Target value of delta UV
       deltauv_default| Default value of delta UV
       sec_level_current| Current generic level on secondary element (possible values from -32768 to 32767)
       sec_level_target| Target generic level on secondary element

After that, LC (Light Controller) models are initialized in sl_btmesh_lc_init(). See the Bluetooth Mesh Model specification for more details on the LC model.
The lc_state struct contains following fields.

The lc_property_state struct contains the following fields.

changing the Light LC Occupancy state
time_fade_on| Transition time from a standby state to a run state
time_run_on| Duration of the run state after last occupancy was detected
time_fade| Transition time from a run state to a prolong state
time_prolong| Duration of the prolong state
time_fade_standby_auto| Transition time from a prolong state to a standby state when the transition is automatic
time_fade_standby_manual| Transition time from a prolong state to a standby state when the transition is triggered by a manual operation
lightness_on| Lightness level in a run state
lightness_prolong| Lightness level in a prolong state
lightness_standby| Lightness level in a standby state
ambient_luxlevel_on| Required Ambient Lux Level level in the Run state
ambient_luxlevel_prolong| Required Ambient Lux Level level in the Prolong state
ambient_luxlevel_standby| Required Ambient Lux Level level in the Standby state
regulator_kiu| Integral coefficient of PI light regulator when increasing output
regulator_kid| Integral coefficient of PI light regulator when decreasing output
regulator_kpu| Proportional coefficient of PI light regulator when increasing output
regulator_kpd| Proportional coefficient of PI light regulator when decreasing output
regulator_accuracy| Accuracy of PI light regulator

Both structs are used for saving and restoring the LC states between the resets. Most of the LC functionality is implemented in the stack, so events are mostly used for saving state and informative purposes. The application uses the sl_btmesh_evt_lc_server_lin-ear_output_updated_id event to update the LED state according to the LC output value generated by the light controller based on the LC properties, state, and received sensor readings. The friend functionality is then initialized to enable the friend feature implemented in the stack. After successful initialization, friend re-quests from Low Power Nodes can be accepted. The friend feature is mostly implemented in the stack, so after initialization only a few informative events can be raised to the application through corresponding callback functions:

•  sl_btmesh_friend_on_friendship_established: a friendship was established. The application displays “FRIEND” on the WSTK LCD and/or in UART logs.
•  sl_btmesh_friend_on_friendship_terminated: the friendship was terminated. The application displays “NO LPN” on the WSTK LCD and/or in UART logs.

Next, the Scene Server and Scene Setup Server models are initialized. The Scene Server behaviors are implemented in the stack, so the application receives only informative events. The Scene Server automatically recalls Light LC states and generates the sl_btmesh_evt_generic_server_state_recall_id event to inform other models what states are stored with the scene. The light node registers callback functions for each of the supported models. This is done by calling the mesh_lib_ge-neric_server_register_handler() function. The function has five parameters: the model ID, the element index, the client request handler function, the server state change handler function, and the server state recall handler function.
The light node registers handlers for the following models in the Lighting Server:

•  Generic On Off Server
• Generic Power On Off Server
•  Generic Default Transition Time Server
•  Light Lightness Server
•  Light Lightness Setup Server
•  Generic Level Server (on primary element)

The light node registers handlers for the following models in the Light CTL Server:

•  Light CTL Server
•  Light CTL Setup Server
•  Light CTL Temperature Server (on secondary element)
•  Generic Level Server (on secondary element)

The light node registers handlers for the following model in the Light LC Server:

• Generic On Off Server (on secondary element)

On the server side, the mesh library works as follows. When any generic request from a client is received, the event sl_btmesh_evt_generic_server_client_request_id is raised. The application then calls the function mesh_lib_ge-neric_server_event_handler from the mesh library and passes the event as the parameter. The mesh library decodes the model ID from the event and invokes the callback function that has been registered for that model. For example, in the light node, a Generic On Off request will invoke the callback function onoff_request() The onoff_request() function is called whenever an on/off request is received either from one of the switch nodes or from the smartphone app. This is the piece of code in the light node that turns lights on and off. If the request does not specify any transition time or delay, then the light state is changed immediately. Alternatively, the client may have requested a delay and/or a transition time, meaning that the transition does not happen instantly. In that case, the light node application starts a soft timer with the given delay. The light state is not changed until the soft timer expires. Light Lightness requests are handled in function lightness_request(). The lightness request includes a parameter of type uint16 that indicates the light brightness on a scale of 0 – 65535. The example code uses pulse-width modulation (PWM) to drive the LEDs. The PWM is implemented using a 16-bit timer and the requested brightness value is directly mapped to the value of the Compare/Capture register of the timer. For example, the value 32768 will result in 32768/65536 ~ 50% brightness / PWM duty cycle. The duty cycle of the PWM signal is displayed on the LCD so that it is easy to compare the brightness that has been requested and the brightness that is currently set in the light node. The Generic On Off state is bound with the Light Lightness state. This means that, if the light is turned off with an on/off request, the last brightness value is saved by the application and is recovered after the application receives an on/off request that turns the light on. If brightness is set to 0 using lightness request, the generic on/off state is set to OFF. If brightness is set to a positive value, the generic on/off state is set to ON. Brightness can be also changed using Generic Level requests handled in function pri_level_request(). The generic level request includes a parameter of type int16 that indicates brightness level. The conversion from level to lightness is made by adding 32768 to the level value. Light CTL requests are handled in function ctl_request(). The CTL request includes three parameters that indicate the light bright-ness, color temperature, and delta UV. The first two parameters are of type uint16, and the third is of type int16. Actual color temperature and delta UV are displayed on the WSTK LCD below the lightness. Color temperature is limited by spec to scale 800 – 20000 K. Limits can be changed by ctl_setup_request() with type of request set to ctl_temperature_range. Also the default values for CTL state could be changed using ctl_setup_request() with type of request set to ctl_default .

Network Analyzer

Network Analyzer is a packet capture, decoder software, and visualization application and is part of Silicon Labs Simplicity Studio. Net-work Analyzer has support for Bluetooth LE and Bluetooth mesh packet capture, and the latest version of Simplicity Studio also has decoders to decode the Bluetooth LE and mesh traffic. Refer to AN1317: Network Analyzer for Bluetooth Low Energy and Mesh for more information. The EFR32 SoCs have a dedicated Packet Trace Interface (PTI), which outputs all the radio traffic sent and received by a specific EFR32 device, and Network Analyzer can capture this traffic. On the EFR32, the PTI functionality can be enabled or disabled at the source-code level so it can be enabled during development and can then be disabled for production software. Silicon Labs Wireless Starter Kits (WSTKs) support PTI packet capture either over USB, which is useful for capturing packets from a few WSTKs at a time, or over an Ethernet connection. The Ethernet connection also provides access to PTI, and this functionality enables building and debugging a network of WSTKs and large-scale testing environments for Bluetooth mesh. The easiest way to start a Network Analyzer session for a specific application is to right-click on a project, select Profile As and then select Network Analyzer Target. Starting Silicon Labs Network Analyzer

 Bluetooth Mesh Stack and Application for Smartphones

Silicon Labs also provides a Bluetooth mesh stack and a reference application for smartphones. The application can be used to provision mesh-capable Bluetooth devices as nodes that are part of a Bluetooth mesh network, as well as configure the nodes, set up groups, and the publish subscribe settings for nodes. At the time of writing this document, the application supports one physical network, multiple groups, and Lighting mesh models, but the application will be constantly updated for new features and functionality. As the smartphones at the time of writing this document do not natively support Bluetooth mesh, Silicon Labs also provides the Bluetooth mesh stack for the phones. The mesh stack is needed for the phone to be able to provision, configure, and control the Bluetooth mesh nodes over the GATT bearer. The figure below illustrates the architecture and the relationship between the Bluetooth stack on the phone operating system and the Silicon Labs Bluetooth mesh stack, as well as how the application relates to this. The Bluetooth mesh stack will be available as a binary library for phone application developers. A reference application implementing the Bluetooth mesh stack, provisioning, configuration, and device control is available on the Google Play and Apple App Stores. Contact your local Silicon Labs sales office for more information. Bluetooth Stacks and Application Architecture on Smartphones

Simplicity Studio

One-click access to MCU and wireless tools, documentation, software, source code libraries & more. Available for Windows, Mac and Linux! IoT Portfolio
www.silabs.com/IoT SW/HW
www.silabs.com/simplicity Quality
www.silabs.com/quality Support & Community
www.silabs.com/community

Disclaimer
Silicon Labs intends to provide customers with the latest, accurate, and in- depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and “Typical” parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the
information supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required or Life Support Systems without the specific written consent of Silicon Labs. A “Life Support System” is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications. Note: This content may contain offensive terminology that is now obsolete. Silicon Labs is replacing these terms with inclusive language wherever possible. For more information, visit www.silabs.com/about-us/inclusive- lexicon-project

Trademark Information
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, “the world’s most energy friendly microcontrollers”, Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® , Zentri, the Zentri logo and Zentri DMS, Z-Wave®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.
Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701
USA
www.silabs.com

References

• Silicon Labs
• Silicon Labs
• About Us - Silicon Labs
• Silicon Labs Community
• Internet of Things (IoT) - Silicon Labs
• Simplicity Studio - Silicon Labs

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>