Silicon Labs took the decision to deprecate its proprietary implementation of Thread and instead be a major contributor to the more popular OpenThread implementation.

The announcement was made as part of the release notes for Silicon Labs Thread (SL-Thread) SDK  v2.10.1.0 which can be found here:
https://www.silabs.com/documents/public/release-notes/thread-release-notes-2.10.1.pdf

The notice indicates that the inclusion of the SL-Thread implementation will be removed from the Simplicity Studio release scheduled in December 2019.

The notice re-iterates that Silicon Labs has a continued focus on its Thread strategy and is committed to continuing as a leading-edge Thread supplier. Support for Thread will continue within the Silicon Labs software and hardware tools but the stack availability itself will be distributed through the commonly accessible OpenThread GitHub repository.

More information on the OpenThread implementation can be found at: https://openthread.io/platforms/efr32

In EmberZNet version 6.6, Silicon Labs has made changes to the underlying framework so that it uses the same user interface and metadata used by all of Silicon Labs’ other stacks including the xNCP, Silicon Labs Thread, and Flex. This change results in a slightly different user interface for the EmberZNet 6.6 stack in Simplicity Studio. The most noticeable change is that projects are no longer generated into the <stack>/app/builder directory. Instead projects are generated by default into the user’s workspace directory. What follows is a comprehensive guide to both the UI changes for the EmberZNet 6.6 stack in Simplicity Studio as well as a migration guide for moving a pre-6.6 project using Application Framework V2 to one using the Zigbee Application Framework in EmberZNet 6.6.

Creating an Application from Scratch

The first thing you will notice when creating an application in SDK version 6.6 is that the application framework is no longer called “ZCL Application Framework V2”, but rather “Silicon Labs Zigbee”.

Other than this minor change to the location of projects and naming of the application framework, the creation of an application is unchanged.

User Interface Changes

The AppBuilder interface is still broken up into Tabs, however the contents and names of some of the tabs have changed slightly. The ZCl global tab has been removed and its contents moved to the ZCL Clusters tabs or removed. All changes are detailed below.

Pre EmberZNet 6.6 Stack Tabs

Post EmberZNet 6.6 Stack Tabs

The General Tab

1. The generation directory has moved out of the stack and away from the “app/builder” directory and into the user’s workspace by default:

2. There is no longer an option to “Automatically generate when file is saved”.

3. Multi-network configuration widget has moved to the Zigbee stack tab.

ZCL Global Tab

1. The ZCL Global tab has been removed.

2. The Manufacturer Code and Default Response Policy options have moved into the ZCL Clusters tab.

3. Specification versions pulldowns that were related to previous ZCL “Profiles” have been removed. Applications are always built against the latest Zigbee 3 ZCL cluster definition located in the stack’s app/zcl directory.

ZCL Clusters Tab

1. Includes the Manufacturer Code and Default Response Policy from the ZCL Global Tab.

ZNet Stack Tab

1. The ZNet Stack tab has been renamed to the Zigbee Stack Tab.

2. Multi-network configuration has moved into the Zigbee Stack Tab from the General Tab.

3. “Interpan settings” has been removed.

4. The “Custom ZCL Additions” widget has been added. Custom ZCL .xml files used to be loaded into Simplicity Studio preferences and were applied to all projects. We have moved the interface into the project itself so that custom ZCL .xml files and additions are added on a project by project basis.

Prior to EmberZNet 6.6, ZCL .xml additions were added into the Simplicity Studio Preferences and thus affected all projects created for a given stack version as shown below. This is no longer an option for EmberZNet 6.6 and higher.

Printing and CLI Tab

1. The Debug printing checkbox has moved into the “Debug Configuration” widget.

2. “Cluster debugging” has been renamed to the more generic “Application Specific debug printing”. All of the clusters are still listed in this section.

3. Individual plugin debug printing has been added.

4. The “CLI Options” widget has been renamed to “CLI”.

Hal Configuration Tab

1. This tab has been renamed to “HAL”.

2. The “IO Configuration” widget has been renamed to “Serial Configuration”. The Command Line Interface pulldown has been moved to an App Framework Core plugin option.

3. The “Board Header” widget has been renamed to “Board Header Configuration”.

4. The “Manage integration…” widget has been renamed to ”Hardware Configurator Interface”.

5. The “Multi Protocol Stack Interface” widget has been renamed to “MPSI Configuration” with the acronym spelled out below.

Plugins Tab

The ability to expand the table, collapse the table, and show only selected plugins does not exist yet in the EmberZNet 6.6 interface.

Callbacks Tab

This tab is unchanged.

Includes Tab

The “Custom Events” widget is now renamed to “Event Configuration”.

Other Options Tab

This tab is unchanged.

Bluetooth GATT Tab

This tab is unchanged.

ISC File Changes

1. Many of the key value pairs located in the pre-EmberZNet 6.6 stacks have been moved into “setup” configurations in the new .isc file format.

2. Pre-EmberZNet 6.6 .isc files are automatically upgraded to the new Zigbee Application Framework format when they are opened against an EmberZNet 6.6 stack.

Migrating a Pre-EmberZNet 6.6 Application Over to EmberZNet 6.6.

Applications created with earlier versions of EmberZNet can be moved into the user’s workspace directory and migrated over to EmberZNet 6.6. The following is a step by step instruction on the migration process, starting with the creation of a pre-EmberZNet 6.6 application and resulting in an upgraded application. This process works for both SoC and Host applications.

1. In the SDK preferences navigate to and open your Pre-EmberZNet 6.6 stack. In this example I will use the EmberZNet 6.5 stack, part of Gecko SDK Suite 2.5.3.

2. Right click and close all open projects in the workspace. Now, create a new project using the earlier stack. In this case I’ll create an EmberZNet 6.5 Z3LightSoc.

3. Generate and compile the project. This will generate code into your <GSDK>/app/builder directory.

4. Right click and close all open projects in the workspace. Not doing so will re-enable the older stack versions upon restarting studio. In the Simplicity Studio V4 preferences disable earlier stack and enable EmberZNet 6.6.

5. Since you have generated and compiled against an earlier stack you should close Simplicity Studio in order to clear out any Hardware Configurator cached data. Hardware configurator data is cached in Simplicity Studio by default in order to speed up generation. Alternatively caching can be turned off in Simplicity Studio preferences.

6. In your user workspace directory create a directory called “<project name>_temp”. This is a temporary directory that you can copy your important project files into before they are imported into Simplicity Studio. For example, my user workspace is located at “/Users/<username>/SimplicityStudio/v4_workspace/.” My project is called Z3LightSoc so I created a directory at “/Users/<username>/SimplicityStudio/v4_workspace/Z3LightSoc_temp”

7. Copy your project’s .isc, .hwconf and callbacks.c files from the <GSDK>/app/builder/<projectname> directory into this temporary directory inside your workspace.

8. Start Simplicity Studio V4.

9. In Simplicity Studio V4 go to File > Import… and browse to the temporary directory that you have created containing your copied files.

• You should have the option of importing the project as an “External Project Type”.

10. Import the project. Be sure to set the stack to your EmberZNet 6.6 stack. The project name should default to the original name of the project, in my case Z3LightSoc.

11. You should see the project inside the Simplicity Studio IDE.

12. Double click on the .isc file in the Simplicity Studio to open the project in AppBuilder.

13. Change the generation directory from the old <GSDK>/app/builder directory to your project directory inside your workspace. In my case this is /Users/<username>/SimplicityStudio/v4_workspace/Z3LightSoc

14. Be sure to change the path to any “Included” files in your project by modifying the “Other Options Tab” as necessary.

15. Generate your application.

16. As a final step you should copy the files out of your <projectname>_temp directory into your actual project directory by right-clicking on the files in Simplicity Studio and choosing “Copy Linked Files into Project”.

17. Compile your application.

This is a guide is for creating, building, and running a Dotdot OTA Server and Client using available sample applications. The OTA Server will be on a Host application on the Raspberry Pi that has an NCP connected. This KBA assumes that the user has reviewed UG116 and is familiar with running a Raspberry Pi Host with NCP. (Please note, it is not a requirement for the OTA Server to also be a Border Router).

This KBA was written with the following software tools:

• Simplicity Studio
• Gecko SDK version 2.5
• IAR Workbench 7.80.4
• GCC 6.3.0

With the following recommended hardware:

• Raspberry Pi 2 Model B
• Two BRD4164s or equivalent EFR32MG12 reference boards with WSTKs

Sample Applications

Create projects for the following sample applications found in Gecko SDK version 2.5 through the Application Wizard. These can be found through the File menu going to File -> New -> Project -> Silicon Labs AppBuilder Project.

• OTA Server (Host)
• Light (Soc)
• NCP UART HW (Hardware Flow Control)
• SPI Flash Storage Bootloader (single image)

The Light and OTA Server are pre-commissioned and will be in the same network at startup,  unless the devices were already in a previous network. Resetting the network parameters will coax the devices to enter the networking state-machine. The reset command is as follows:

ota-server> network-management reset

OTA Server Configuration

The OTA Server (Host) Sample application has all the plugins required to be an OTA Server. Most notable are the following:

• OTA Bootload Core
• OTA Bootload Server
• OTA Bootload Server Policy
• OTA Bootload Storage CLI
• OTA Bootload Storage Core
• OTA Bootload Storage UNIX

In OTA Server Sample app we recommend making the following changes for testing: 

• Under the Printing tab enable the following debug output
  • ICMP CLI
  • OTA Bootload Core
  • OTA Bootload Server
  • OTA Bootload Storage UNIX
  • OTA Bootload Storage Core
  • OTA Bootload Server Policy
• In OTA Bootload Server Plugin
  • Change the Image Notify Period to 1 minute

Generate, transfer to Raspberry Pi, Compile the OTA server application. Also, compile ip-driver-app found under v2.x/protocol/thread/ with the following command:

$> make -f app/ip-ncp/ip-driver-app.mak

Light OTA Client Configuration

The OTA Client is based on the Light sample app. The following plugins are used to enable the OTA functionality. Here we assume the device you are using has external EEPROM:

•  OTA Bootload Client
•  OTA Bootload Client Policy
•  OTA Bootload Core
•  OTA Bootload Storage CLI
•  OTA Bootload Storage Core
•  OTA Bootload Storage EEPROM

In the OTA Bootload Client options set the following to maximize the recurrence of OTA Client/Server communication:

• Discover Server Period to 1 minute
• Query Next Image Period to 1 minute 

In the OTA Bootload Client Policy options note the following and/or set them to something unique. These will be used for creating the OTA image:

• Current Image Manufacturer Code
• Current Image Type
• Current Image Version 

In the OTA Bootload Storage EEPROM plugin make sure the value of EEPROM OTA Storage End Address is one less than the value found in SPI Flash Storage Bootloader Slot 0 size (under the Storage tab). If the size does not match the download will fail.  

We also recommend enabling the following plugins for testing:

• ICMP CLI
• COAP CLI
• UDP CLI

As well as the following for debug output under the Printing tab:

• EEPROM
• OTA Bootload Storage EEPROM
• OTA Bootload Client Policy
• OTA Bootload Core
• NVM3 Library
• ZCL Core
• OTA Bootload Client

Generate, Build, and Flash the Light application and bootloader to the EFR32. 

Building OTA Image

Recall the values in OTA Bootload Client Policy plugin for the Light. In order for the Light application to flash an image it must verify if the image has met the criteria of the OTA policy. The Manufacturer ID, Image Type ID need to be the same, and the Firmware Version must be a higher value. We will need to create a second image with a higher version number. For example, the first image will be version 0x00000001 and the new image will have version 0x00000002. Go back to AppBuilder and update the project to have a higher version number by changing the setting, generating, and compiling. (Note: this will overwrite your old image. If it needs to be available store it in a different place or rename the GBL file.)

The Image Builder tool will wrap the GBL file in an OTA file. The tool can be found under the SDK directory tree ../gecko_sdk_suite/v2.5/protocol/thread/tool/image-builder/. The following command can be called in a terminal:

$> ./image-builder-linux -c 1234-5678-00000002-light.ota -m 0x1234 -i 0x5678 -v 0x00000002 -s 4 -t 0  --security-credentials=3 -f "light292BRD4163A_02.gbl"

• -c : The OTA file to create
• -m : Manufacturer ID found in OTA Bootload Client Policy
• -i : Image type ID found in OTA Bootload Client Policy
• -v : Firmware version found in OTA Bootload Client Policy
• -s : ZCL Stack version
• -t : Tag Identifier
• --security-credentials : The security credentials required for this upgrade.
• -f : The file to be included in the OTA

More information can be found in  AN716: Instructions for Using Image-Builder

Kicking off OTA upgrade

Copy the OTA image to the same directory where the Server Host application is called. Start the ip-driver-app followed by the ota-server.

$> sudo ./ip-driver-app -u /dev/ACM1 -t tun0 -m 4901 &
$> sudo ./ota-server -m 4901

In ota-server call the following command to see if it has found the OTA image.

ota-server> ota-bootload-storage info

The output should be similar to the lines below:

ota-server: 
1234-5678-00000002-light.ota: m=0x4X t=0x4X v=0x8X
ota-server.nvm: 
Load files found 1 files
OTA Bootload Storage Info: maximumFileSize = 1000000, fileCount = 1
File 0: m=0x1234 t=0x5678 v=0x00000002 size = 311919

On the Light side open the console and check the network parameters using the info command and make sure it is on the same network as the OTA Server. The results should be similar to the lines below:

light_01> info
network status: 0x03
eui64: >000B57FFFE25FAFC
macExtendedId: >776A3C93A3776E86
network id: precommissioned
node type: 0x02
extended pan id: >4F8EC75FB4E1EFC6
pan id: 0x1075
channel: 19
radio tx power: 3 dBm
ula prefix: fd01::/64
mesh-local: fd01::1f0e:750c:b36:7ce5
link-local: fe80::756a:3c93:a377:6e86

To kickoff the search for an OTA Server use the following command:

light_01> ota-bootload-client update

The following lines should output to console:

Sent discovery command: .well-known/core?rt=urn:zcl:c.2000.s&
get 0x00
Using upgrade server discovery
Discovered server: fd01::63e6:a84:377c:3305->5683

If the server is discovered then the OTA transfer will start in ~1 minute (as we configured in OTA Bootload Client plugin).

The ISA3 Utilities are a set of software tools for the Silicon Labs Ember ISA3 Debug Adapter. With these tools you can manipulate adapter firmware as well as program chips in the EM35x and EM35xx family of parts. The latest downloads of these parts can be found here:

ISA3 Utilities

For assistance using these utilities, please refer to this user guide:

UG107: ISA3 Utilites

If you are having the issue mentioned in the title after an update to EmberZnet 6.5.0.0 please consider updating to the Gecko Bootloader. If it is not an option for you the following is an explanation on why this problem occurs followed by a proposed solution. 

Although support of Ember Standalone Bootloader for EFR32 based products has ended in 2017. There could still be some devices in the field that were initially manufactured with the Ember Standalone Bootloader and are now unable to upgrade to the Gecko Bootloader. 

Since the 2.5 GSDK release modules are regarded as first class citizens and while the Gecko bootloader has been upgraded to facilitate this update the Ember Bootloader was not because it is no longer being developed. 

This update causes the AAT header in .ebl files built during the post-build process in Simplicity Studio to be interpreted as corrupt by the Ember Standalone Bootloader.

The problem is that the value of byte 0x78 used to be 0x10 for EFR32MG1P or 0x11 EFR32MG1B and after the update it is set to 0x01 for MGM111. 

If this is the issue the advised solution is to convert the created .s37 file to .ebl using the 'em3xx_convert' tool.
This should be located at "(StudioFolder)\developer\adapter_packs\em3xx\utils"

Open any command line tool at this location and you can convert a .s37 to .ebl with the correct AAT header using the following command. 

 "em3xx_convert.exe --chip EFR32 (path)/(filename).s37 (path)/(filename).ebl"

If your existing Host-NCP solution is lacking Green Power proxy support and you want to add it to the design these steps will walk you through the process of adding it.

Adding host support

First, go to the ZCL Clusters tab and find the Multiple endpoint configuration section at the top. Click the New button to add an endpoint to your device, this will create a second endpoint on the device with identifier 2. Now we need to convert this to a green power endpoint.

In the Configuration column, click the Primary name, which will bring up a button with 3 dots

Click the box to bring up the Endpoint type window

Select the option Create new endpoint type and name your new endpoint Green Power. Click OK.

Keeping the endpoint selected, go to the pull-down menu for ZCL Device Type and change the device to GP Proxy Basic (under GP devices). When this is selected, this will make the endpoint change to number 242. This should also enable Cluster 0x0021, the Green Power cluster, on the device.

Now go to the Plugins tab and on the search bar, enter Green – this will find 4 plugins in the Green Power section:

Check the box next to the Green Power Client and Green Power Common plugins, this will enable them. There isn't any need to change any of the default settings within the plugins, so you can leave those alone. 

At this point you should be able to generate and build your host application with no issue and Green Power will be supported. However support for green power needs to be enabled within the NCP.

Adding NCP support

As you are configuring your  NCP application, go to the plugins tab and enable the Green Power Stack Library plugin. Make sure the Green Power Stack Stub Library is disabled:

Since this is just a proxy, you can leave the settings as defaulted, proxy table size of 5 and sink table size of 0. However you will need to consider your potential network when configuring your table sizes. A larger proxy table might be needed for supporting all devices on the network.

This is all you need for NCP support. You can generate and build your NCP and combined with your new host code, green power proxy support should be ready to go.

What is the maximum allowed power for ZigBee applications under ETSI EN 300 328?

Although ETSI EN 300 328 allows 20dBm RF output power, there is a limitation for PSD (Power Spectral Density) for wide band modulations other than FHSS. This PSD limit restricts the maximum allowed power for ZigBee applications.

Section 5.4.3.2 in EN 300 328 V2.1.1 details the test method for PSD. The ZigBee modulated signal measured according to Option 2, Step 3 (with sweep time set to 10s):

CW signal with the same power level and spectrum analyzer settings:

The peak power difference between the ZigBee and CW signal measured with RMS detector is ~2.3dB. In order to meet the PSD limit of 10dBm per MHz, the maximum allowed power is 12.3dBm (EIRP).

Note: The 12.3dBm power limit is radiated (EIRP), which means that in case of an antenna with 0dBi, the maximum conducted power allowed is 12.3dBm. For antennas with lower gain than 0dBi, conducted power can be increased, while for antennas with higher gain than 0dBi, conducted power should be reduced.

Measurements were performed on an EFR32MG13 based reference board (BRD4158A Rev A01).

1. Make sure your device has a XMODEM bootloader. 
2. Connect your device to the machine that will perform the upgrade through a UART interface. 
3. Connect to the device with a serial terminal application that is capable of XMODEM file transfer. (I used tera term)
4. Reboot your device into the bootloader. You can confirm this if you see the bootloader menu on the serial interface.
5. The bootloader menu looks like this
    
6. Select the 'upload gbl' option by pressing 1. 
7. The device will enter a loop and start waiting for XMODEM packets
    
8. Transfer the desired firmware upgrade file in gbl format using XMODEM file transfer
   
9. After the device confirms that the upload was successful select the 'run' option
    
10. The new firmware should be running on the device now try and connect to it with a HOST. 

Physical interface - Light

Project Overview | Previous Step | Next Step

So now it’s time to make the physical interface for our light and switch. While being able to send and see messages go across the network is fun, since we are making a light and a switch, we should expect them to act like a light, turning a light source on and off and a switch, taking an input from a button press or similar signal.

First let’s turn our attention to the light, since a light turning on and off is an easier goal to observe. As we have noticed on our last step, we have been toggling one of our cluster attributes, specifically an on-off attribute. What we want is to have our device change based on this attribute’s value. One mechanism that we can use to handle this is through a callback.

A callback is a way that EmberZNet handles events throughout the stack code and application layer as well. If you click on the callbacks tab, you will see a number of calls that can be used throughout your code. These are generally broken down into application callbacks, plugin callbacks, stack callbacks, API callback and cluster callbacks. An in depth look at the callbacks is beyond the scope of this lesson.

For our light code, we are going to need to handle two events. First, at startup we need to enable our lights and configure them. Once that’s done we need to handle the toggling of the light based on the On/Off attribute. 

To setup our light, we need to look at the section called “Non-cluster related.” All of these callbacks are in order. As you look down the list you will come across two callbacks Main Init and Main Start, both of these callbacks run at the start of our main() function. Main Init runs right after main executes, but before the network is setup, while Main Start runs right before our main loop executes, after the HAL is done configuring the hardware. In most cases it won’t matter where we set up our LED interface, so for this we will use Main Start, check the box for it.

Next, we need to figure out how to toggle our light on and off. Because this is tied to the on/off cluster, you want to go to the On/Off cluster under the General. Looking through the list, we can find the Server Attribute Changed callback. Since we are operating on the attribute value setting, this is perfect for our needs, check its box as well.

Before we leave this page, make sure at the bottom of your callbacks page you have the “Generate project-specific callbacks file” box checked. This will ensure your new callbacks file is generated for your application.

Before we click generate, we also need to configure all of our GPIOs to work as LEDs. The Thunderboard has 1 green LED, 1 red LED and 4 full color LEDs, for this project we are going to use the full color LEDs. If you read UG309 section 3.4.8, you will see all of the pin definitions, as well as an explanation of how the LEDs are setup.

Next, we need to launch Hardware Configurator (HWConf for short). If you look in your light project, you should see a file named brd4166a_efr32mg12p332f1024gl125.hwconf, this is your header file for your project. Double click on it and it should open in HWConf in the DefaultMode Port I/O. If it isn’t in that format, click that tab at the bottom of the DefaultMode Peripherals window. This view brings us to a graphical representation of the pins, it is where we will set our GPIOs to be available to us within our software.

Setting the GPIOs from within HWConf is fairly straight forward. First you need to go to the Outline view on the top right corner of Studio and open the Port I/O tree. Then click on the Port (A-K) you want to set, this will make those GPIOs become active on the graphical pin grid. Locate the pin you want to setup on the grid (be careful, the pin letters are easy to get confused with their grid identifiers) and click on them. You will then see the Properties of this pin on the middle right of Studio. If you click on the value area within Custom pin name, you will be able to give the pins a name, this will be how you identify the pin in your program.

For example: PJ14 is RGB_LED_ENABLE (note this is configured by default)

• Outline view: click on PortJ
• DefaultMode Port I/O: Click on PJ14 (located in row B, column 6)
• Properties view: name it RGB_LED_ENABLE

Do the same for the following pins – locations provided for easy locating:

• PD11 (M10) – LEDS_RED
• PD12 (N11) – LEDS_GREEN
• PD13 (M11) – LEDS_BLUE
• PI0 (G13) – LED0
• PI1 (G12) – LED1
• PI2 (G11) – LED2
• PI3 (F13) – LED3

Remember all of the names you give these pins.

Once this is done, save your HWConf file, this might take some time as it will generate some new hardware configurations. Then return to Simplicity IDE view and click on your MyLight.isc file. Click the Generate button. After some time you will get a validation window to appear. Make sure that all files on this window are checked, Studio will many times leave the *_callbacks.c file unchecked to not overwrite this. Once all the boxes are checked, click OK to continue.

Finally, it is time to put in some code to make our lights turn on and off. First, locate the callbacks file in your project list. It will be called PROJECTNAME_callbacks.c, in our case, this will be MyLight_callbacks.c, double click on it and the code in this file will appear. You will note that you should have 2 functions in the project: emberAfMainStartCallback and emberAfOnOffClusterServerAttributeChangedCallback.

First let's enable our lights. Since we need to enable our LEDs as our code starts, we will focus our attention to the emberAfMainStartCallback() function. As noted, this function is called right before our program initiates it's loop while it is running. 

Now we will need a fuction to initialize our GPIOs, configuring them as output pins. You can look through docs.silabs.com and find the EMLIB section to discover a function to run this setup. To save you some time, the function you are looking for is:

void GPIO_PinModeSet (GPIO_Port_TypeDef port, unsigned int pin, GPIO_Mode_TypeDef mode, unsigned int out)

The function call for this is defined fully here. But we will step you through the function calls for easy reference.

The first two arguments are the port and pin that we want to configure. Because we have defined our pins in HWConf, you can use those names you assigned these pins in the GUI. They will be something like PIN_NAME_PORT and PIN_NAME_PIN, which correspond do the port letter and port number respectively. If you look in your project tree there is a folder called hal-config and in that folder you will find a file hal-config.h, this file contains the names of the ports and pins for easy reference, locate the section

// $[Custom pin names]

The next argument is how the pin is configured. Fortunately all of our GPIOs are set as outputs and our GPIO mode is going to be gpioModePushPull. A full list of pin options can be found here.

Finally because we are using these as output pins, the last argument is the desired initial state of the pin, either 0: off or 1: on.

So to set up RGB_LED_ENABLE, use the following:

GPIO_PinModeSet(RGB_LED_ENABLE_PORT, RGB_LED_ENABLE_PIN, gpioModePushPull, 1);

Do the same for all of your ports and pins. You should certainly make sure that RGB_LED_ENABLE is on at startup. If you want a particular color, the colored LEDs should be enabled as you want for the color you want to output, red, green or blue, or some combination of them all. LEDs 0-3 can be disabled or enabled, they are what we are going to use to turn on the LEDs. 

One final warning the LEDs are quite bright, especially if you turn on all three for white, so be careful when looking at them. After doing so, you might decide you want to start with them off. 

At this point you can re-compile your code and test to see if your lights come on. Once you have verified that your LEDs are working, you can then implement the on/off feature.

So now we will move down to the function emberAfOnOffClusterServerAttributeChangedCallback. This function is called anytime a server sided attribute on the light changes. It has two variables in its definition which are the endpoint that is being operated on by the change and the attribute itself which is being changed. In our case we want to change anytime we are seeing a call on our defined endpoint on the on/off attribute and change to the state which is set in that attribute. Despite only having a single endpoint in our project, you should wrap this call to make sure you are calling it on a particular endpoint, because you can then expand it to work for additional endpoint. Since our light functionality is our primary endpoint, you should compare the endpoint passed to this function against this. EmberZnet provides a means of getting this with the function emberAfPrimaryEndpoint(), this means we know that we are getting this called against the main light endpoint.

if (endpoint == emberAfPrimaryEndpoint())

Once we have done that, we need to make sure we are operating on the on/off attribute. First you should look at the file attribute-id.h. This file lists all of the attributes in your project and sets a number of defines for these attributes, using these your code will be much more readable. If you go to the section with the On/off cluster, you will see the ZCL_ON_OFF_ATTRIBUTE_ID, which matches that attribute ID. You can then do some comparison or switch statement and use that as the entry into your function.

if(attributeId == ZCL_ON_OFF_ATTRIBUTE_ID)

Now, we need a means of reading our attribute and turning the light on or off based on this attribute. Because this callback is made after the attribute has changed, we can read this attribute to get its state. To do this we will need to look through the documentation of EmberZNet. If you go to Docs.silabs.com, you can find the Ember Application framework API

On the left, if you click Ember Application Framework API Reference it will shows you the sections of the top-level API. At this point we just want the General Application Framework Interface. When you get this page, you will find the Attribute storage section listed at the very top. We are looking for some function to read an attribute, a little searching will find the function emberAfReadServerAttribute, a function that is doing exactly what we want, reading a server attribute, so copy that whole definition and paste it into your code. 

EmberAfStatus emberAfReadServerAttribute (uint8_t endpoint, EmberAfClusterId cluster, EmberAfAttributeId attributeID, uint8_t *dataPtr, uint8_t readLength)

Because the function returns an EmberAfStatus, create one to catch the return value. We should only change our LED if the read was successful. You can return to the API guide and look up EmberAfStatus, you will find this is EMBER_ZCL_STATUS_SUCCESS.

if(readStatus == EMBER_ZCL_STATUS_SUCCESS)

Finally we need to make sure we properly read our attribute and change our LED, so go back to emberAfReadServerAttribute function call and let’s set it up properly. We know that our endpoint is the endpoint passed to our callback, so make sure this matches. The cluster ID is that for the on/off cluster. If you look at cluster-id.h, you will see that it is enumerated as ZCL_ON_OFF_CLUSTER_ID, so put that as the 2nd variable in the call. The attribute ID is again ZCL_ON_OFF_ATTRIBUTE_ID, so use that. Finally, we need something to catch the value of the data. I created a boolean type named onOff to catch this, the last two variables of the signature are a pointer to this variable and the size of that variable. In the end our full call looks something like this:

boolean onOff;
EmberAfStatus readStatus;
readStatus = emberAfReadServerAttribute(endpoint, 
                                        ZCL_ON_OFF_CLUSTER_ID,
                                        ZCL_ON_OFF_ATTRIBUTE_ID,
                                        &onOff,
                                        sizeof(onOff));

Now we can just use an if-else called against onOff to turn on or turn off our LED. The checking EMLIB again, we see that the function calls for this are:

GPIO_PinOutSet(port, pin); 

GPIO_PinOutClear(port, pin);

Make the appropriate calls to the LEDs you want on and off within your code block, save and recompile your code. You can then reflash it to your “light” Thunderboard and use the switch to toggle it from the CLI. If you are able to turn the lights on and off, it’s time to move on to our switch to get it to toggle from the buttons.

Project Overview

Previous Step
Next Step

In this tutorial we are going to be demonstrating how to build two simple Zigbee 3.0 applications for a light and a switch using Simplicity Studio on the Thunderboard Sense 2. 

This project will start by building up a basic set of applications using AppBuilder which will start out as the framework for our light and switch. Then we will add some custom hardware definitions as well as some custom code and expand the base projects provided to tie the software in with the hardware.

When you are finished you will have a light application that controls the states of LEDs based on software attributes and you will have a switch which reacts to a button to send ZCL messages over the air to update the attributes of the light. Below you will find some basic instructions which walk you along the next few lessons as well as code examples and hardware configuration files to get you started.

Some prerequisites you will need for this tutorial:

Simplicity Studio 4 with the latest updates
EmberZNet 6.4.0 or later
Two Thunderboard Sense 2 boards (BRD4166A)
Two WSTKs (BRD4001A)
Two Mini-Simplicity connectors (BRD8010A) and the included 10 pin ribbon cable

You will also need easy access to Simplicity Commander's CLI interface. While it isn't the only way to program your chips, there are a few steps, like token programming, that require Commander.

Tutorial Steps

ZigBee 3.0 Tutorial - Step 0: Preparation and bootloaders

ZigBee 3.0 Tutorial - Step 1: Creating the projects

ZigBee 3.0 Tutorial - Step 2: Configuring the projects

ZigBee 3.0 Tutorial - Step 3: Flashing and testing our application

ZigBee 3.0 Tutorial - Step 4: Forming and joining the network

ZigBee 3.0 Tutorial - Step 5: Communications

ZigBee 3.0 Tutorial - Step 6: Physical interface - light

ZigBee 3.0 Tutorial - Step 7: Physical interface - switch

Older Tutorial

The videos that went with the older lesson can be found here:

ZigBee Home Automation Developer Tutorial: Light and Switch Overview
ZigBee Home Automation - Light and Switch - part 1
ZigBee Home Automation - Light and Switch - part 2
ZigBee Home Automation - Light and Switch - part 3
ZigBee Home Automation - Light and Switch - part 4
ZigBee Home Automation - Light and Switch - part 5
ZigBee Home Automation - Light and Switch - part 6
ZigBee Home Automation - Light and Switch - part 7
ZigBee Home Automation - Light and Switch - part 8
ZigBee Home Automation - Light and Switch - part 9
ZigBee Home Automation - Light and Switch - part 10
ZigBee Home Automation - Light and Switch - part 11
ZigBee Home Automation - Light and Switch - part 12