Migrating devices from older ZigBee pro profiles to zigbee 3.0 can seem confusing. However with the right steps, it can be a lot more understandable. This KBA will help to demonstrate the steps for how to move App Builder projects from legacy ZigBee Pro profiles to full zigbee 3.0. The initial focus will be on HA device, but it will soon include ZLL devices as well.
For this guide, we are going to be looking at the various tabs in App Builder and the change that need to be made in each section.
This is where the initial changes between older HA and ZigBee 3.0 will be found. Where an HA router application will normally have a single endpoint, a ZigBee 3.0 application will have multiple endpoints. See the pictures below.
Figure 1. The ZCL configuration of an HA profile
Figure 2. The ZCL configuration of a zigbee 3.0 profile
In the HA profile, there is a single endpoint called primary. In the zigbee 3.0 profile there will be multiple endpoints. All of profile IDs will be HA, but their device ID will be different. The GreenPower profile (ID 0x0066) is required by the zigbee 3.0 specification. Touchlink (ID 0x0200) is not, but including it will give you the most flexibility and compatibility within the zigbee 3.0 network.
In terms of clusters, these should be the same for your device from HA to zigbee 3.0.
Because zigbee 3.0 uses a new security model, there is another change that will need to be made from application to application. HA had a single security model, zigbee 3.0 Security includes all of the security models needed for new zigbee 3.0 devices.
This is where you will see major changes between the two application profiles. First we will breakdown the plugins which you will find removed from your HA device profile. Then we will breakdown and explain the new zigbee 3.0 plugins, many of which are new to the EmberZnet stack.
Plugins removed in the transition from your HA device:
The plugins you removed in the previous section are replaced by new plugins that are zigbee 3.0 compatible. Along with this there are many more plugins which need to be added to support newer zigbee 3.0 features. All of them are as follows:
If required for the Network Creation and Steering plugin, you will need to make sure to include these callbacks with your project:
Generation and rebuilding
Once you have completed moving your project over to zigbee 3.0 compliant settings, you should be able to generate and compile your project. There may be other steps required for full project migration. Manually rebuilding your project callbacks file might be necessary as well as modification of any custom code. Ideally with this KBA this process is much simpler.
thanks for good article,
as a note, to work the profileID indicated for endpoint 242 (GreenPower Endpoint) need to be change from "Home automation ..." to "0xA1E0":
If the Idle/Sleep plugin is removed the halSleep function isn't call and the device will not enter power save mode. Tested on EFR32 platform
Hi As AP pointed out Green Power Profile ID isn't correct on the article.
It looks like even the Green Power Device ID is wrong. 0x066 is for Combo and I believe you only suport proxy. 0x061.
Application Device Version is wrong in the template.
See ZigBee Application Architecture ZigBee Document 13-0589-13, 04-Dec-2015 Chapter 5.1 Device Version
A device version is an unsigned integer that is associated with an approved revision and release of a device specification. The initial value for a device version SHALL be 1. The version of the instance of a device SHALL be represented by the Application Device Identifier field (Device Identifier), and Application Device Version field (device version) in the Simple Descriptor.
Products developed before these requirements have a device version of 0. The initial version (1) of a device specification SHALL require the latest certifiable revisions of the clusters it mandates. Device implementations MAY support later revisions of the mandatory clusters as they become certifiable. Any mandatory changes to the device specification SHALL only enhance, not change the function of the device. Any changes SHALL increment the version of the device. Newer versions of the device SHALL interoperate with older versions at the older version’s level of functionality.
Examples of changes to a device specification that requires incrementing the version: