Z-Wave Plus Application Framework v6.8x · 2019-12-05 · ALL Based on INS13427– Z-Wave Plus...

Instruction

Z-Wave Plus Application Framework v6.8x.0x

Document No.: INS13953

Version: 4

Description: -

Written By: JFR;COLSEN;SSE;BBR

Date:

Reviewed By: NOBRIOT;LTHOMSEN;CST

Restrictions: Public

Approved by:

This document is the property of Silicon Labs. The data contained herein, in whole or in part, may not be duplicated, used or disclosed outside the recipient for any purpose. This restriction does not limit the recipient's right to use information contained in the data if it is obtained from another source without restriction.

INS13953-4 Z-Wave Plus Application Framework v6.8x.0x 2018-04-05

silabs.com | Building a more connected world. Page ii of v

REVISION RECORD

Doc. Rev

Date By Pages affected

Brief description of changes

1 20170615 TRO COLSEN JFR TRASMUSSEN

ALL Based on INS13427– Z-Wave Plus Application Framework v6.71.0x Initial revision.

1 20170621 TRO 5.2.5 Update protocol function calls for security flags.

1 20170719 JFR Appendix D Slave based application migration using 128KB external NVM

1 20170720 TRO 5.2.7 Smart Start

1 20170925 COLSEN 8.1 Porting guide

2 20171206 COLSEN ALL Updated references.

2 20171206 COLSEN 8.1 Updated porting guide.

3 20180115 COLSEN 6 Restructured and edited some of the document into the CC section.

4 20180405 BBR All Added Silicon Labs template

https://www.silabs.com/


silabs.com | Building a more connected world. Page iii of v

Table of Contents

1 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ......................................................................... 6

2 INTRODUCTION ................................................................................................................................... 6

3 PURPOSE ............................................................................................................................................. 6

4 ARCHITECTURE .................................................................................................................................. 7

4.1 Smart Start ......................................................................................................................................... 8 4.2 Power Management .........................................................................................................................10

5 HOW TO DEVELOP A Z-WAVE PLUS APPLICATION ....................................................................11

5.1 Create application folder and setup make environment ...................................................................11 5.2 Setting up config_app.h ....................................................................................................................11

5.2.1 Generic type, specific type and device options ......................................................................11 5.2.2 Role Type, node type, icon type and user icon type (Z-Wave Plus Info CC) ........................11 5.2.3 Manufacturer Specific CC / Firmware update ........................................................................12 5.2.4 Association Group Information (AGI) .....................................................................................12 5.2.5 Security ..................................................................................................................................13 5.2.6 Firmware upgrade ..................................................................................................................14 5.2.7 Smart Start Included Node Information Frame (INIF) configuration ......................................14

5.3 Setting up EEPROM files .................................................................................................................14 5.4 Source file .........................................................................................................................................15

5.4.1 Command class lists configuration ........................................................................................15 5.4.2 Endpoint configuration ...........................................................................................................15

6 COMMAND CLASSES .......................................................................................................................17

6.1 General interfacing to CCs ...............................................................................................................17 6.1.1 Unsolicited transmission ........................................................................................................17 6.1.2 Respond to received Command ............................................................................................17

6.2 Implementing a CC ...........................................................................................................................19 6.3 Association Group Information CC ...................................................................................................19

6.3.1 API ..........................................................................................................................................19 6.4 Battery CC ........................................................................................................................................20 6.5 Notification CC version 8 ..................................................................................................................20 6.6 Supervision CC.................................................................................................................................21

6.6.1 Configuration scenarios .........................................................................................................21 6.6.1.1 Default configuration ......................................................................................................21 6.6.1.2 Handle more Supervision Reports .................................................................................22 6.6.1.3 Control Supervision Reports ..........................................................................................23

7 UTILITIES ............................................................................................................................................25

7.1 AGI module .......................................................................................................................................25 7.1.1 Configuration of AGI ...............................................................................................................25

7.1.1.1 Example 1: how to setup AGI for a Wall Controller. .......................................................26 7.1.1.2 Example 2: how to extend the Wall controller with 2 buttons .........................................27

7.1.2 Using AGI ...............................................................................................................................28 7.2 Association module ..........................................................................................................................28

7.2.1 Setting up the NVM ................................................................................................................29 7.2.2 Initialization.............................................................................................................................30

7.2.2.1 Example 3: How to use group mapping. ........................................................................30 7.3 Interfacing Firmware Update module “ota_util” ................................................................................32 7.4 GPIO Driver ......................................................................................................................................32 7.5 Key Driver .........................................................................................................................................32 7.6 Event Scheduler ...............................................................................................................................33

7.6.1 Simple event job handling ......................................................................................................33



silabs.com | Building a more connected world. Page iv of v

7.6.2 Multiple event jobs handling ...................................................................................................34 7.6.3 Coding example .....................................................................................................................35

7.7 Task pool ..........................................................................................................................................38 7.8 Test Interface....................................................................................................................................38

7.8.1 UART settings ........................................................................................................................39 7.8.2 Test Interface in the sample applications ...............................................................................39 7.8.3 Defined commands for the default ZAF channel ...................................................................39

8 PORTING GUIDE ................................................................................................................................41

8.1 Changes in 6.81.01 ..........................................................................................................................41 8.2 Porting from 6.71.0x to 6.8x.0x ........................................................................................................41

8.2.1 ZAF_pm replaces Battery_plus ..............................................................................................41 8.2.1.1 ApplicationIdle replaces AppPowerDownReady ............................................................41 8.2.1.2 No arguments for loadStatusPowerLevel and one less argument for Transport_OnApplicationInitSW ..........................................................................................................41 8.2.1.3 ApplicationPoll takes an argument and return a value ...................................................41

8.2.2 ApplicationInitSW must return node type ...............................................................................41 8.2.3 App must trigger Smart Start after initialization......................................................................42 8.2.4 The module slave_learn_plus is moved to the protocol .........................................................42

8.3 Porting from 6.61.0x to 6.71.0x ........................................................................................................42 8.3.1 Security configuration in Config_app.h ..................................................................................42 8.3.2 General changes in command classes ..................................................................................42 8.3.3 Utilities modules .....................................................................................................................43

APPENDIX A IMPLEMENTING A NEW COMMAND CLASS ...............................................................45

APPENDIX B SCENARIO RECEIVING A GET COMMAND .................................................................49

APPENDIX C DATA MIGRATION ..........................................................................................................50

APPENDIX D SLAVE MIGRATION USING 128KB EXTERNAL NVM ..................................................53

REFERENCES ...........................................................................................................................................54

Table of Figures

Figure 1: The Z-Wave Plus Application Framework architecture ................................................................ 7 Figure 2, Smart Start state event machine for all applications. ................................................................... 9 Figure 3, SwitchOnOff.c interface to BinarySwitch CC for incoming commands. ..................................... 18 Figure 4, Command Class Version Get implementation in SwitchOnOff.c. .............................................. 19 Figure 5, AGI behavior diagram ................................................................................................................ 25 Figure 6, Wall controller that sends Command Class Scene and Device Reset Locally over association

group 1 (lifeline) and Command Class Basic over association group 2. ........................................... 26 Figure 7, extended with two endpoints and remove root group 2. ............................................................ 27 Figure 8, Association behavior diagram .................................................................................................... 29 Figure 9, Wall Controller with Root Device group mapping....................................................................... 31 Figure 10, State event machine handling an unsolicited job ..................................................................... 34 Figure 11, Using the FIFO queue in an application ................................................................................... 35 Figure 12, Module source code for a response job. .................................................................................. 46 Figure 13, Unsolicited event function declaration in the module header file. ............................................ 47 Figure 14, Unsolicited event function implementation in the module c-file. .............................................. 48 Figure 15, Sequence diagram of how Z-Wave Plus Framework handle an incoming Get command....... 49 Figure 16, NVM data migration from SDK 6.5x/6.6x with security to SDK 6.7x based application ........... 50 Figure 17,NVM data migration from SDK 6.5x/6.6x without security to SDK 6.7x based application ....... 51 Figure 18, App migration process. ............................................................................................................. 53



silabs.com | Building a more connected world. Page v of v



silabs.com | Building a more connected world. of 49

1 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Abbreviation Explanation

AGI Association Group Information

CC Command Class

NIF Node Information Frame

OTA Over The Air

S0 Security 0 Command Class

S2 Security 2 Command Class

SDK Software Development Kit

ZAF The Z-Wave Plus Application Framework

2 INTRODUCTION

This document describes the Z-Wave Plus Application Framework (ZAF) distributed on SDK 6.8x.xx.

3 PURPOSE

The purpose of the ZAF is to facilitate the implementation of robust Z-Wave Plus compliant products.




4 ARCHITECTURE

Figure 1 shows the architecture of the ZAF and its relation to the hardware and the Z-Wave protocol.

Figure 1: The Z-Wave Plus Application Framework architecture

The ZAF consists of three blocks:

Transport Layer:This layer handles all communication with the protocol, which includes single cast, multicast,Multi-Channel encapsulation, delivery of bundled commands, etc.

Command Class Handlers:These handlers parse and compose Command Class frames.

Utilities:Utilities are composed of different modules. Among them, there are modules for handling I/Ocommunication specific for the ZDP03A board bundled with the SDK. Other modules are batterymonitoring and firmware updating, etc.

The framework implements an event-driven application design.

The framework provides built-in features for developing simpler applications. Transmit buffers are mutex-protected to ensure that the application has only one transmit request job (unsolicited event) at a time. The transmit buffer is released only when the transmit request job is completed or has timed out. The Framework can handle one request job and one response job at the same time.

The ZAF is split into the following two folders:

Hardware & Z-Wave protocol

Application

Z-Wave Framework

Transport Layer

Command Class Handlers Utilities




/ApplicationCommandHandlers/ contains CC modules. All CC modules share a protected

transmit buffer provided by the ZW_tx_mutex module. The ZW_tx_mutex module implementstwo transmit buffers, one for request calls and one for response calls. Protected transmit buffersare described in chapter Appendix A.

/ApplicationUtilities/ contains utility modules and interfaces to the transport layer.

Some of the modules are used for simple MMI-setup such as button and LED handling. Othermodules as association_plus, battery_monitor, battery_plus and ota_util are more complex utilitymodules which interface to CC and the client application.

4.1 Smart Start

The Smart Start feature is part of the protocol and automatically handles the inclusion process without having a user physically interact with a device. When powered on for the first time, the device tells the world that it is ready for inclusion and most likely a controller nearby will hear this and include the device. If inclusion process times out, it retries again after a given time. This connection process differs dependent on whether a device is main powered or battery powered. A main powered device is active all the time where a battery device sleeps between connection retries.

The Smart Start inclusion process starts when the application calls “ZW_NetworkLearnModeStart()” with the parameter “E_NETWORK_LEARN_MODE_INCLUSION_SMARTSTART”.

The Protocol inform Classic and Smart Start learn process through function call “ApplicationNetworkLearnModeCompleted()”. Function Node Id’s value description:

Node ID

Event

0x00 Exclusion was successful.

0xFD APPLICATION_NETWORK_LEARN_MODE_COMPLETED_TIMEOUT

0xFE APPLICATION_NETWORK_LEARN_MODE_COMPLETED_SMART_START_IN_PROGRESS

0xFF APPLICATION_NETWORK_LEARN_MODE_COMPLETED_FAILED

X Any other value will be an assigned node ID.

The following state machine (Figure 1) applies to all Z-Wave+ applications in the SDK.




Figure 2, Smart Start state event machine for all applications.

Smart Start description:

Powering On: Smart Start is per default started.o If not included, smart Start inclusion can be started by Controller.o If included, powering on reason is “power on reset”. Protocol sends out INIF.

STATE_APP_IDLE:o ApplicationNetworkLearnModeCompleted called with:

APPLICATION_NETWORK_LEARN_MODE_COMPLETED_SMART_START_IN_PROGRESS. The protocol informs the application that an inclusion process has started.

o ApplicationPoll called with E_PROTOCOL_STATE_READY_FOR_SHUTDOWN: The protocol informs the application that it’s ready to powerdown. Since the

application is in STATE_APP_IDLE, the device will power down. This applies tobattery nodes only.

STATE_APP_LEARN_MODE:o ApplicationNetworkLearnModeCompleted called with valid node ID:

Inclusion succeeded and application changes to STATE_APP_IDLE.o ApplicationNetworkLearnModeCompleted called with:

APPLICATION_NETWORK_LEARN_MODE_COMPLETED_FAILED.

Inclusion process failed and application change to reboot state.o ApplicationNetworkLearnModeCompleted called with:

Node ID zero.

Exclusion process succeeded and application change to reboot state.

STATE_APP_WATCHDOG_RESETo Reset device and reboot to start Smart Start Inclusion.

STATE_APP_REBOOT:o Protocol handles Smart Start time out to power off.o Protocol handles next powering on time (WUT timer) if not included.o Protocol handles powering off if no active jobs.




4.2 Power Management

Compared to earlier versions of the SDK, the Z-Wave protocol now handles power management. We have introduced a new module in the ZAF called ZAF_pm where pm is the abbreviation of power management. This module tells the protocol if the application or the ZAF wants to stay awake for a given time.

Besides this module ApplicationInitSW and ApplicationPoll now includes power management related code.

Function Description

BYTE ApplicationInitSW(ZW_NVM_STATUS nvmStatus)

ApplicationInitSW must return whether the device is a listening or non-listening device.

- APPLICATION_FREQ_LISTENING_MODE_250ms - APPLICATION_FREQ_LISTENING_MODE_1000ms - APPLICATION_NODEINFO_NOT_LISTENING

E_APPLICATION_STATE ApplicationPoll(E_PROTOCOL_STATE bProtocolState)

ApplicationPoll must whether the application is ready to sleep.

Main powered applications do not need to power off and can in “ApplicationPoll()” return E_APPLICATION_STATE_ACTIVE.

Battery powered applications must wait for a list of things to finish before informing the protocol that it can go to sleep. ApplicationIdle() implements this.




5 HOW TO DEVELOP A Z-WAVE PLUS APPLICATION

The Z-Wave Plus applications basic functionality is defined by a Device Type and Role Type , which are explained further in [1] and [2]. It is important to determine the right combination of Device Type and Role Type for your Z-Wave Plus application.

When Device and Role Type are determined, the application development can start.

5.1 Create application folder and setup make environment

Follow these steps in order to setup a working directory for your application.

1. To get a general understanding of the build environment, please refer to [5].2. Create a copy of the MyProductPlus folder in the ProductPlus folder. MyProductPlus is a simple

application which can be included and excluded from a Z-Wave network. It implements all thebasic functionalities that are mandatory for a Z-Wave Plus application.

3. Rename the copied folder to a suitable name for your application.4. Enter the folder and rename MyProduct.c to a suitable name for your application.5. Open Makefile and locate MyProduct.obj. Change MyProduct to match the name of your c file –

without file extension. For example, the result could be MyApplication.obj.6. In Makefile, also change APP_NAME to a suitable name. E.g. MyApplication.7. Build the application in order to verify that the changes did not break anything. It is also possible

to download the application to the chip to check that the application runs without error.

5.2 Setting up config_app.h

5.2.1 Generic type, specific type and device options

A Z-Wave Plus device must specify a Generic Device Class and a Specific Device Class by using the following two definitions:

GENERIC_TYPE

SPECIFIC_TYPE

Refer to [10] and [1] to select appropriate Generic and Specific Device Classes for your product. The identifiers values are defined in ZW_classcmd.h.

DEVICE_OPTIONS_MASK is a bitmask used to specify a set of device options. See the ZW_basic_api.h file for details.

5.2.2 Role Type, node type, icon type and user icon type (Z-Wave Plus Info CC)

The Role Type, node type, icon type and user icon type are all values used by the Z-Wave Plus Command Class. They are set using the following definitions:

APP_ROLE_TYPE

APP_NODE_TYPE

APP_ICON_TYPE

APP_USER_ICON_TYPE




For further information about the Icon Types used in the Z-Wave Plus Info CC, refer to [6]. Please contact the Z-Wave Alliance to acquire new Icon Types.

5.2.3 Manufacturer Specific CC / Firmware update

The Manufacturer specific CC requires some product specific values to be defined. Refer to the Manufacturer Specific Command Class in [14] for more information. The ZAF uses the following macros for these values:

APP_MANUFACTURER_ID

APP_PRODUCT_TYPE_ID

APP_PRODUCT_ID

APP_DEVICE_ID_TYPE

APP_DEVICE_ID_FORMAT

The Firmware Update Command Class uses this definition:

APP_FIRMWARE_ID: The firmware ID consists of the product type ID and the product ID.

The manufacturer and product ID’s are used to identify a Z-Wave product from a manufacturer point of view. Other applications can also use this information to show a company logo, type of product, user guide, etc. on the user interface. This information is exchanged via the Manufacturer Specific CC and currently allocated manufacturer IDs are listed in the ZW_classcmd.h file. See [14] for more information about these two Command Classes.

5.2.4 Association Group Information (AGI)

Refer to [14] and [8] for a general understanding of AGI and Associations.

In an application, the AGI must be configured in config_app.h.

For Z-Wave Plus products, the Lifeline group is mandatory. It can be defined using the following declaration:

#define AGITABLE_LIFELINE_GROUP \ {<command class X>, <command A>}, \ {<command class Y>, <command B>}, \ {<command class Z>, <command C>}

Refer to [1] to find out what events and Command Classes have to be used in the Lifeline group. Definitions for Command Classes and Commands are found in ZW_classcmd.h.

Other groups (apart from Lifeline) must be defined using the following format if the application is not implementing Multi Channel endpoints:

#define AGITABLE_ROOTDEVICE_GROUPS \ {<profile 1 MSB>, <profile 1 LSB>, {<command class X, command A}, "<group 2 name>"}\ {<profile 2 MSB>, <profile 2 LSB>, {<command class X, command A}, "<group 3 name>"}\

If the application is implementing Multi Channel endpoints, the AGI definition must be filled out using the endpoint groups.

#define AGITABLE_ROOTDEVICE_GROUPS \




AGITABLE_ENDPOINT_1_GROUPS, \ AGITABLE_ENDPOINT_2_GROUPS, \ AGITABLE_ENDPOINT_3_GROUPS, \ AGITABLE_ENDPOINT_4_GROUPS

AGITABLE_ENDPOINT_X_GROUPS represents the non-lifeline groups for endpoint X. Each of the endpoint groups are defined as the Root Device groups defined by AGITABLE_ROOTDEVICE_GROUPS, but with a matching definition name, other profiles, Command Classes, etc.

#define AGITABLE_ENDPOINT_1_GROUPS \ {<profile X MSB>, <profile X LSB>, {<command class>, <command>}, "group name"}, \ {ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY01, {COMMAND_CLASS_SWITCH_MULTILEVEL_V4, SWITCH_MULTILEVEL_SET_V4}, "Button 1"}

When the product implements Multi Channel endpoints, there must be a mapping to the root association groups. Root groups mapping provides backwards compatibility because devices which do not support Multi Channel must be able to ask the Root Device which groups are supported. Root group mapping defines groups in the Root Device mapping to endpoints’ groups. An example is given in Table 1.

Table 1, Root Device and Endpoint Group mapping

Root Device group Endpoint ID Endpoint group ID

Root Device group 2 Endpoint 1 Endpoint 1 group 2

Root Device group 3 Endpoint 2 Endpoint 2 group 2

The following shows how root group mapping is configured in config_app.h. The details of the root group mapping setup depend on the application.

#define ASSOCIATION_ROOT_GROUP_MAPPING_CONFIG \ {<ROOT DEVICE GROUP 2>, <ENDPOINT ID 1>, <ENDPOINT GROUP 2>}, \ {<ROOT DEVICE GROUP 3>, <ENDPOINT ID 2>, <ENDPOINT GROUP 2>}

Refer to the config_app.h file in the Wall Controller sample application for a group mapping example. The SensorPIR and DoorLockKeyPad applications also show how AGI can be set up.

Group definitions are used to initialize the AGI in the main source file of the application.

5.2.5 Security

Security authentication and levels are configured in the config_app.h file with the definition of REQUESTED_SECURITY_AUTHENTICATION and REQUESTED_SECURITY_KEYS flags. Definitions can be found in the ZW_security_api.h file and see [7] for more information about security.

Application can be configured for security S2 authentication type controller-side (SSA) or client-side (CSA). For client-side authentication need the user to input a 10 digits code via an input interface on the device, like a keyboard.

#define REQUESTED_SECURITY_AUTHENTICATION SECURITY_AUTHENTICATION_SSA




Application security level bits must be added to this flag when developing a product. Secure level “No-secure” is the default value.

#define REQUESTED_SECURITY_KEYS \

(SECURITY_KEY_S2_UNAUTHENTICATED_BIT|SECURITY_KEY_S0_BIT)

Added functionality:

ApplicationSecureAuthenticationRequested () includes security authentication flagREQUESTED_SECURITY_AUTHENTICATION.

ApplicationSecureKeysRequested() includes security keys flagREQUESTED_SECURITY_KEYS..

5.2.6 Firmware upgrade

The definition FIRMWARE_UPGRADABLE is used by the Firmware Upgrade CC. It determines whether your application is upgradable or not. See description of the Firmware Meta Data Report Command in [14].

5.2.7 Smart Start Included Node Information Frame (INIF) configuration

Setting up INIF for advertising included nodes [11] [12]:

#define USER_INPUT_IDENTIFICATION

#define USER_INPUT_LOCAL_RESET

Please see the source for more info regarding this.

5.3 Setting up EEPROM files

The EEPROM is set up in two files: eeprom.c and eeprom.h. Each file must contain a list of the application’s variables. Some of these variables belong to the ZAF.

For a new application, the variables can be initialized in the following manner:

BYTE far variable_name = 0xAA;

With performing a firmware update, only variables that were not in the previous firmware are initialized. Existing variables added in earlier versions of the firmware do not get initialized again.

When developing a newer version of the firmware where new variables are needed, it is very important that these variables are appended to the list. This is done in order to keep the device included in the Z-Wave network and to preserve all associations’ data. In other words, if the order of the variables is changed in a newer version, the firmware update will corrupt the EEPROM data and the device will no longer be included in the network.




5.4 Source file

The application must implement two functions for initialization: ApplicationInitHW(..) and ApplicationInitSW(..). The protocol calls the functions in the mentioned order. For details about their arguments and return values, see the ZW_basis_api.h file. All initializations for the application should be done from these two functions. Transport_OnApplicationInitSW(..) must be called at the end of ApplicationInitSW(..). NvmInit(..) must be called at the beginning of ApplicationInitSW(..).

5.4.1 Command class lists configuration

The application uses 3 Command Class lists to send out the node information frame (NIF) depending on the inclusion status. These three lists define the NIF for:

- Not included - Non-securely included - Securely included

The following Command Class list is used when the node is not included or non-securely included. When the device is included, Security and Security_2 Command Classes are removed by the ZAF. This Command Class list is present in node information frame (NIF):

static code BYTE cmdClassListNonSecureNotIncluded[]

The following Command Class list is used when node is securely included. It represents the Command Classes that are supported non-securely even though the device has been securely included.

static code BYTE cmdClassListNonSecureIncludedSecure[]

The following Command Class list is used when node is securely included. It contains the Command Classes that are supported securely only. This Command Class list is advertised through the Security Command Class, Security Commands Supported Report Command.

static BYTE cmdClassListSecure[]

5.4.2 Endpoint configuration

If your device must implement endpoints, the AGI and association group mapping must be set up in the config_app.h file. After configuring each endpoint in AGI (see section 5.2.4 ) AssociationInitEndpointSupport() must be called instead of AssociationInit() for association group mapping (see chapter 7.2.2 for the different initializations).

Finally, the transport layer needs to be initialized for endpoints by calling the Transport_AddEndpointSupport() function. This function sets up endpoints’ functionalities and Command Class lists. Please read [15] for information about individual and aggregated endpoints.




void Transport_AddEndpointSupport( EP_FUNCTIONALITY_DATA* pFunctionality, EP_NIF* pList, BYTE sizeList);




6 COMMAND CLASSES

An essential feature of the ZAF is the communication through Command Classes. For this purpose, each of the Command Classes has a C module where incoming commands are handled and outgoing commands are transmitted.

6.1 General interfacing to CCs

The application will typically use CCs in the two following ways:

Send an unsolicited command, or

Respond to a received command

6.1.1 Unsolicited transmission

See the following example of a CC API definition. Although none of the CCs complies with that naming scheme yet, it is the plan that more and more CCs will comply for every future version of the ZAF.

job_status_t ZAF_CC_Basic_Set_tx( agi_profile_t * pProfile, uint8_t sourceEndpoint, uint8_t value, VOID_CALLBACKFUNC(pCallback)(transmission_result_t * pTransmissionResult));

A controlling device, e.g. a wall switch, may want to send a Basic Set Command. It is the purpose of the function given in the above example. Three of the four arguments are generic arguments found in all Command Class APIs: pProfile, sourceEndpoint and pCbFunc. Those arguments are detailed below. The argument bValue is specific for the Basic Set Command. To find out information about Basic Set or other application CCs and their commands, see [13].

pProfileThe pProfile points to a AGI profile. This must be one of the profiles that is set up in the AGIsection in your application’s config_app.h file.

sourceEndpointIf the application is implementing endpoints, the source endpoint must be set to ENDPOINT_Xwhere X is the number of the endpoint, e.g. ENDPOINT_1. If the application does not haveendpoints, the source endpoint must be set to ENDPOINT_ROOT. The enumeration forENDPOINT_ROOT and ENDPOINT_X can be found in the ZW_TransportEndpoint.h file.

pCbFuncThis argument is a pointer to a callback function with one argument of the typeTRANSMISSION_RESULT. The definition of this type can be found in the CommandClass.h file.The given callback function will be called once for each node found in the Associations. Whentransmission for the last node is done, the isFinished value will be set toTRANSMISSION_RESULT_FINISHED.

6.1.2 Respond to received Command

Each CC implementation has a handleCommandClass…() function that extracts the received frame for a given Command Class. This function needs to be added into the application’s




Transport_ApplicationCommandHandler() function switch-case block. Normally, the frame is carrying a “Set” or “Get” Command that results in a function call for reading or writing data. It is up to the application to implement these functions provided as extern functions in the CC header file.

An example is shown in Figure 3 where the SwitchOnOff application interfaces to Binary Switch CC.

Figure 3, SwitchOnOff.c interface to BinarySwitch CC for incoming commands.

Version CC has a function called handleCommandClassVersionAppl() into the application to read a

specific CC version. It is the application's responsibility to implement this function and make the function able to return the version number for any CC used in the application.




Figure 4, Command Class Version Get implementation in SwitchOnOff.c.

6.2 Implementing a CC

Not all CCs have been implemented in the ZAF yet. Hence, in some cases the required Command Class must be developed for the application. For details, see Appendix A.

6.3 Association Group Information CC

For a general introduction to AGI CC, please refer to [14].

AGI CC is implemented in two C modules:

CommandClassAssociationGroupInfo

Agi

Together, these modules serve two purposes:

Advertise capabilities of each association group, and

Find associated nodes to which the application wants to send an unsolicited command.

6.3.1 API

CC_AGI_Init()

CC_AGI_LifeLineGroupSetup()

CC_AGI_ResourceGroupSetup()




6.4 Battery CC

Battery CC is implemented in two C modules:

CommandClassBattery

battery_monitor

Together, these modules can measure and report the battery level of a device. The API consists of the following functions. For information about what they do, arguments and return values, please refer to the source header files for each of the modules.

InitBatteryMonitor()

BatterySensorRead()

BatteryMonitorState()

TimeToSendBattReport()

SendBattReport()

ActivateBattNotificationTrigger()

InitBatteryMonitor() must be called as the first function of the above six to initialize the Battery CC.

6.5 Notification CC version 8

Notification CC is typically used in sensor applications because it supports many different notification/sensor types. For general information related to Notification CC, please see [13].

Historically, this CC supported both push and pull mode and the ZAF implementation has tried to cover both modes. However, push and pull mode have been separated in version 8 of the CC and the ZAF now supports and tests only push mode because supporting both modes at the same time will conflict in certification.

Notification CC is implemented by two C modules:

CommandClassNotification

notification

The Notification CC API consists of the following functions. For information about what they do, arguments and return values, please refer to the source header files of notification.h.

InitNofication()

AddNotification()

DefaultNotificationStatus()

NotificationEventTrigger()

UnsolicitedNotificationAction()

The typical call order is showed below:

1. Initialize the Notification CC by calling InitNofication().2. Set the notification status for all available notifications (limited by the definition

MAX_NOTIFICATIONS in config_app.h) by calling DefaultNotificationStatus().3. Call AddNotification() a number of times depending on how many different notification types the

application implements.




4. Trigger an event by calling NotificationEventTrigger() and transmit it by callingUnsolicitedNotificationAction().

5. If a state was triggered contrary to an event, the state can be cancelled by callingNotificationEventTrigger() with cancelling arguments and then transmitting the cancellation bycalling UnsolicitedNotificationAction().

6.6 Supervision CC

Please refer to [9] for the definition of the Supervision Command Class.

CC Supervision is built into the Application Framework and handles Supervision communication on S2 encapsulated frames. Supervision is only supported for Set and Report commands.

The default is that CC Supervision supports only one Supervision Report per Supervision Get command. In Supervision Get command is 'more status updates' field set to CC_SUPERVISION_STATUS_UPDATES_NOT_SUPPORTED. The application does not need to initialize CC Supervision if the default configuration fulfills application demands (see 0).

Initialization for CC Supervision:

void CommandClassSupervisionInit( cc_supervision_status_updates_t status_updates, VOID_CALLBACKFUNC(pGetReceivedHandler)(SUPERVISION_GET_RECEIVED_HANDLER_ARGS * pArgs),

VOID_CALLBACKFUNC(pReportReceivedHandler)(cc_supervision_status_t status, BYTE duration));

6.6.1 Configuration scenarios

6.6.1.1 Default configuration

The application does not handle more than one Supervision report. The device receives a Supervision Get and replies with a Supervision Report containing CC_SUPERVISION_STATUS_SUCCESS. There’s no need to call CommandClassSupervisionInit() for initialization.




6.6.1.2 Handle more Supervision Reports

The application has the possibility to display that a destination node is processing the transmitted command. An example is that a Wall Controller with a display shows a device is working (CC_SUPERVISION_STATUS_WORKING) until a given command has been performed (CC_SUPERVISION_STATUS_SUCCESS).

void ApplicationInitSW(..) { CommandClassSupervisionInit(

CC_SUPERVISION_STATUS_UPDATES_NOT_SUPPORTED, NULL, ZCB_CommandClassSupervisionReportReceivedHandler);

}

void ZCB_CommandClassSupervisionReportReceivedHandler(cc_supervision_status_t status, BYTE duration) { : }




6.6.1.3 Control Supervision Reports

The application has the possibility to send several Supervision Reports to report on an ongoing activity. An example is that a Door Lock Key Pad reports that a Door Lock Operation is started and a report when it is finished.

void ApplicationInitSW(..) { CommandClassSupervisionInit(

CC_SUPERVISION_STATUS_UPDATES_SUPPORTED, ZCB_CommandClassSupervisionGetReceived, NULL);

}

void ZCB_CommandClassSupervisionGetReceived(SUPERVISION_GET_RECEIVED_HANDLER_ARGS * pArgs) {




: }




7 UTILITIES

Some of the common used functionalities are handled by utilities, which can be adapted by the developer for a particular application.

7.1 AGI module

The AGI module works with the Association Plus module in order to provide a general API for handling the setup and use of associations between multiple Z-Wave nodes. The AGI module interfaces to

“CommandClassAssociationGroupInfo.h” for external access to AGI tables.

Figure 5, AGI behavior diagram

The AGI module contains a configuration part and an API to extract destination nodes for a specific association group.

7.1.1 Configuration of AGI

The AGI module has a constructer called AGI_Init(), which needs to be called before the AGI groups are configured. The constructer call resets the module parameters.

void AGI_Init(void);

The configuration of the group 1 (Lifeline) is done when calling the AGI_LifeLineGroupSetup

function to setup the profile, Command Class groups and group name. This function is also used to configure each endpoint group 1 (endpoint Lifeline). For the Root Device configuration, the endpoint parameter must be set to ENDPOINT_ROOT (0):

void AGI_LifeLineGroupSetup( CMD_CLASS_GRP* pCmdGrpList, BYTE listSize, const BYTE* pGrpName,




BYTE endpoint);

The configuration of group 2..N for endpoint X is done by calling the AGI_ResourceGroupSetup function. The function sets up a list of type AGI_GROUP including profile, Command Class group and group name.. For the Root Device configuration, the endpoint parameter must be set to ENDPOINT_ROOT (0)

Void AGI_ResourceGroupSetup( AGI_GROUP pTable[], BYTE tableSize, BYTE endpoint);

7.1.1.1 Example 1: how to setup AGI for a Wall Controller.

Figure 6, Wall controller that sends Command Class Scene and Device Reset Locally over association group 1 (lifeline) and Command Class Basic over association group 2.

The sample applications use definitions from config_app.h to configure agiTableLifeLine[] and agiTableRootDeviceGroups[].

Table 2, configuration of the Wall Controller

BYTE GroupName[] = "Lifeline";

CMD_CLASS_GRP agiTableLifeLine[] = { {COMMAND_CLASS_CENTRAL_SCENE, CENTRAL_SCENE_NOTIFICATION}, {COMMAND_CLASS_DEVICE_RESET_LOCALLY, DEVICE_RESET_LOCALLY_NOTIFICATION} };

AGI_GROUP agiTableRootDeviceGroups[] = { { ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY01, {COMMAND_CLASS_BASIC, BASIC_SET}, "Button 1" } };

ApplicationInitSW() { : AGI_Init();




AGI_LifeLineGroupSetup( agiTableLifeLine, (sizeof(agiTableLifeLine)/sizeof(CMD_CLASS_GRP)), GroupName, ENDPOINT_ROOT);

AGI_ResourceGroupSetup( agiTableRootDeviceGroups, (sizeof(agiTableRootDeviceGroups)/sizeof(AGI_GROUP)), ENDPOINT_ROOT); :

7.1.1.2 Example 2: how to extend the Wall controller with 2 buttons

In this example each button represents an endpoint. The Root Device association group 2 is moved endpoint 1. Root mapping to endpoints is not shown in current example, please see chapter 7.2.2.

Figure 7, extended with two endpoints and remove root group 2.

Table 3, Add endpoints to a Wall Controller.

CMD_CLASS_GRP agiTableLifeLine[] = { {COMMAND_CLASS_CENTRAL_SCENE, CENTRAL_SCENE_NOTIFICATION}, {COMMAND_CLASS_DEVICE_RESET_LOCALLY, DEVICE_RESET_LOCALLY_NOTIFICATION} };

AGI_GROUP agiTableEndpoint1Groups[] = { ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY01, {COMMAND_CLASS_BASIC, BASIC_SET}, "Button 1" };

AGI_GROUP agiTableEndpoint2Groups[] = { ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY02,




{COMMAND_CLASS_BASIC, BASIC_SET}, "Button 2" };

ApplicationInitSW() { : AGI_Init();

/*Root device configuration*/ AGI_LifeLineGroupSetup( agiTableLifeLine, (sizeof(agiTableLifeLine)/sizeof(CMD_CLASS_GRP)), GroupName, ENDPOINT_ROOT);

/*Endpoint configuration*/ AGI_LifeLineGroupSetup( agiTableLifeLine, (sizeof(agiTableLifeLine)/sizeof(CMD_CLASS_GRP)), GroupName, ENDPOINT_1); AGI_ResourceGroupSetup( agiTableEndpoint1Groups, (sizeof(agiTableEndpoint1Groups)/sizeof(AGI_GROUP)), ENDPOINT_1); AGI_LifeLineGroupSetup( agiTableLifeLine, (sizeof(agiTableLifeLine)/sizeof(CMD_CLASS_GRP)), GroupName, ENDPOINT_2); AGI_ResourceGroupSetup( agiTableEndpoint2Groups, (sizeof(agiTableEndpoint2Groups)/sizeof(AGI_GROUP)), ENDPOINT_2);

:

7.1.2 Using AGI

The AGI module handles the reading of the destination node list from the Association module. After the configuration of the AGI module, the application does not access the AGI module again. The Command Class handlers access the AGI module when calling the ReqNodeList() function for an unsolicited event job.

TRANSMIT_OPTIONS_TYPE_EX* ReqNodeList(AGI_PROFILE* pProfile, CMD_CLASS_GRP* pCurrentCmdGrp, BYTE sourceEndpoint);

7.2 Association module

The Association module is a small database handling all associations. The Association and Multi Channel Associations Command Class modules are interfacing with the Association module for adding




or removing associations. The database is stored in NVM and need to be configured in the eeprom.c /.h files. The AGI module handles the reading of the node list from the database.

Figure 8, Association behavior diagram

The configuration is split in two parts: a first one for setting up the NVM layout and a second one for initializing the Association module in the ApplicationInitSW function.

7.2.1 Setting up the NVM

The data structure in the NVM for one association is composed of 3 bytes:

1. BYTE EEOFFSET_ASSOCIATION_START_far2. BYTE EEOFFSET_ASSOCIATION_ENDPOINT_START_far3. BYTE EEOFFSET_TRANSPORT_CAPABILITIES_STRUCT

The number of associations is calculated from the following definitions:

Number of associations in a group: MAX_ASSOCIATION_IN_GROUP

Number of association groups: MAX_ASSOCIATION_GROUPS

Number of individual endpoints: NUMBER_OF_INDIVIDUAL_ENDPOINTS

Number of aggregated endpoints: NUMBER_OF_AGGREGATED_ENDPOINTS

The total number of endpoints is sum of individual and aggregated endpoints in the device:NUMBER_OF_ENDPOINTS

Definitions are configured in the config_app.h file and used in eeprom.c + .h and association.c + .h.

The NVM layout from the eeprom.c + .h files is shown below:

BYTE far EEOFFSET_ASSOCIATION_START_far[(NUMBER_OF_ENDPOINTS_NVM_MAX + 1) * ASSOCIATION_SIZE_NVM_MAX]; BYTE far EEOFFSET_ASSOCIATION_MAGIC_far; BYTE far EEOFFSET_ASSOCIATION_ENDPOINT_START_far[(NUMBER_OF_ENDPOINTS_NVM_MAX + 1) *




ASSOCIATION_SIZE_NVM_MAX]; EEOFFSET_TRANSPORT_CAPABILITIES_STRUCT far EEOFFSET_TRANSPORT_CAPABILITIES_START_far[(NUMBER_OF_ENDPOINTS_NVM_MAX + 1) * ASSOCIATION_SIZE_NVM_MAX]; BYTE far EEOFFSET_ASSOCIATION_ENDPOINT_MAGIC_far;

7.2.2 Initialization

The initialization of the Association module is done in the ApplicationInitSW function and depends on

support for endpoints.

When no endpoint is implemented, the application must call the AssociationInit() function. The parameter

“forceClearMem” is used for clearing the NVM data:

void AssociationInit(BOOL forceClearMem);

When the application implement endpoints, the application must call the AssociationInitEndpointSupport() function. The function takes the following parameters:

- “forceClearMem” is used for clearing the NVM data.

- “pMapping” is used for backwards compatibility with non-Multi Channel devices. The root group

mapping is used to configure the Root Device to advertise association groups on behalf of endpoints.

- “nbrGrp” is the number of groups in pMapping list.

BOOL AssociationInitEndpointSupport( BOOL forceClearMem, ASSOCIATION_ROOT_GROUP_MAPPING* pMapping, BYTE nbrGrp);

7.2.2.1 Example 3: How to use group mapping.

In this example, the Wall Controller Root Device has 2 association groups and maps them to its endpoints. See previous example in 7.1.1.2. The goal is to map associations from the [Root Device, group 2] to the [endpoint 1, group 2] and from the [Root Device, group 3] to the [endpoint 2, group 2]. More information can be found in [8].




Figure 9, Wall Controller with Root Device group mapping.

Table 4, AGI root groups 2 and 3 (mapped to endpoint 1 and 2) setup.

AGI_GROUP agiTableRootDeviceGroups[] = {{ ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY01, {COMMAND_CLASS_BASIC, BASIC_SET}, "Button 1" }, { ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL, ASSOCIATION_GROUP_INFO_REPORT_PROFILE_CONTROL_KEY02, {COMMAND_CLASS_BASIC, BASIC_SET}, "Button 2" }};

/*root grp, endpoint, endpoint group*/ ASSOCIATION_ROOT_GROUP_MAPPING rootGroupMapping[] = { {ASS_GRP_ID_2, ENDPOINT_1, ASS_GRP_ID_2}, {ASS_GRP_ID_3, ENDPOINT_2, ASS_GRP_ID_2} };

ApplicationInitSW() { BOOL init_NVM = TRUE; : AGI_Init();

/*Root device configuration*/ :

AGI_ResourceGroupSetup( agiTableRootDeviceGroups, (sizeof(agiTableRootDeviceGroups)/sizeof(AGI_GROUP)), ENDPOINT_ROOT);

/*Endpoint configuration*/




: /*Init association*/ if (MemoryGetByte((WORD)&EEOFFSET_MAGIC_far) == APPL_MAGIC_VALUE) { init_NVM = FALSE; }

/* Initialize association module */ AssociationInitEndpointSupport(init_NVM, rootGroupMapping, sizeof(rootGroupMapping)/sizeof(ASSOCIATION_ROOT_GROUP_MAPPING));

:

7.3 Interfacing Firmware Update module “ota_util”

The Ota_util module handles OTA firmware update. It is interfacing to Firmware Update Meta Data CC and delivers an interface to the application to manage the process.

Ota_util API:

BYTE

OtaInit(

BOOL (CODE *pOtaStart)(WORD fwId, WORD CRC),

VOID_CALLBACKFUNC(pOtaExtWrite)( BYTE *pData, BYTE dataLen),

VOID_CALLBACKFUNC(pOtaFinish)(BYTE val));

Input parameters pOtaStart and pOtaFinish is used to inform Application of the status of firmware update and give application possibility to control start of firmware update. It is possible to not call OtaInit and the process run without the application with standard parameters for txOption. Input parameter pOtaExtWrite is used to update host firmware.

[5] Gives a detailed description how to interface to the “ota_util” module.

7.4 GPIO Driver

This driver can be used to setup GPIO pins in the Z-Wave chip. It takes into account that the pins can be swapped depending on the developer target chip or board. It is advised to look at the gpio_driver.h and io_zdp03a.c files in order to see how GPIO pins are implemented. This module can be bypassed using the pin control macros (PIN_IN, PIN_OUT, etc.) defined in ZW_pindefs.h.

7.5 Key Driver

The Key Driver is implemented in the key_driver.c and key_driver.h files. This module is used in all sample applications. It has a flexible interface although this is not fully utilized in the sample applications since a general initialization has been implemented for all sample applications. Refer to the file headers and the function headers in the .h file to get information on how to use the module.




7.6 Event Scheduler

API Files in module

Ev_man.h Ev_man.h + ev_man.c + ZW_util_queue_api.h + ZW_util_queue_api.c

The objective of the Event Scheduler is to provide a general FIFO event queue, which handles events for the application state event machine. Another FIFO queue is added for the application to enqueue and dequeue manually. Event queue buffer size, defined by EVENT_QUEUE_BUFFER_SIZE, is set to 5 by default, but can be changed to suit the application’s size and complexity.

The initialization of the Event Scheduler is done by providing the address of application state event machine function as a parameter to the initialization function:

void EventSchedulerInit(VOID_CALLBACKFUNC(pApplicationStateMachine)(BYTE));

Processing the Event Scheduler is done by calling the function:

void ZCB_EventScheduler(void);

Add this function to the Task pool, TaskAdd( ZCB_EventScheduler ) for processing or add it to ApplicationPoll().

Adding events to application state event machine is done by calling ZCB_EventSchedulerEventAdd(BYTE event).

The manual FIFO is used in the sample applications to temporary queue up events that first should be processed when the active job is finished. Sample applications use this to handle multiple jobs.

Manual queue operations API:

BOOL ZCB_EventEnqueue(BYTE event);

BOOL ZCB_EventDequeue(BYTE* pEvent);

7.6.1 Simple event job handling

Figure 10 shows an example of handling an unsolicited event job.

1. A key press forces state-change to “STATE_APP_TRANSMIT_DATA” and triggers the“EV_BASIC_JOB” event.

2. The “EV_BASIC_JOB” event triggers the CcBasicJob(…) function.

3. Based on receiving acknowledgement from the job, the ZCB_Job(..) function is called and ittriggers the “EV_APP_FINISH_EVENT_JOB” event.

4. The state changes to “STATE_APP_IDLE”.




Figure 10, State event machine handling an unsolicited job

In order to simplify Figure 10, the following function’s name was simplified:

Table 5, Figure 10 function pseudonym

Pseudo function Correct function name

EventAdd(..) ZCB_EventSchedulerEventAdd(..)

7.6.2 Multiple event jobs handling

Figure 11 shows an example of using the FIFO queue in a sample application, handling multiple unsolicited event jobs. In the current design, it is possible to enqueue more jobs during the execution. All the sample applications are built on the current design.

1. Key press forces a state-change to the “STATE_APP_TRANSMIT_DATA” state and fires the“EV_NEXT_EVENT_JOB” event and enqueue multiple event jobs.

2. The “EV_NEXT_EVENT_JOB” event removes an event job from queue and triggers the job to beexecuted. If the queue was empty, then the “EV_APP_FINISH_JOB” event is triggered.

3. Event job “EV_BASIC_JOB” is received and the CcBasicJob(..) function is executed.




4. Based on receiving an acknowledgement from the event job, the ZCB_Job(..) function is calledand triggers the “EV_NEXT_EVENT_JOB” event (step 2).

5. The “EV_APP_FINISH_JOB” event triggers a state change to “STATE_APP_IDLE”.

Figure 11, Using the FIFO queue in an application

In order to simplify Figure 11, the following functions’ names are simplified:

Table 6, Figure 11 functions pseudonyms

Pseudo function Correct function name

EventAdd(..) ZCB_EventSchedulerEventAdd(..)

Dequeue(..) ZCB_EventDequeue(..)

Enqueuer(..) ZCB_EventEnqueue(..)

7.6.3 Coding example

Step 1




The user presses key-2, 2 events are queued, change state and trigger event: “EVENT_APP_NEXT_EVENT_JOB” (see step 2.a).

case STATE_APP_IDLE : if(EVENT_KEY_B2_PRESS == event)

{ ChangeState(STATE_APP_TRANSMIT_DATA); ZCB_EventSchedulerEventAdd(EVENT_APP_NEXT_EVENT_JOB)

/*Add event's on job-queue*/ ZCB_EventEnqueue(EVENT_APP_BASIC_START_JOB); ZCB_EventEnqueue(EVENT_APP_NOTIFICATION_START_JOB);

}

Step 2

The “EVENT_APP_NEXT_EVENT_JOB” event is triggered and Removes event from the queue and triggers its execution.

case STATE_APP_TRANSMIT_DATA :

if(EVENT_APP_NEXT_EVENT_JOB == event) { BYTE event; if(TRUE == ZCB_EventDequeue(&event)){ ZCB_EventSchedulerEventAdd(event); } else{ ZCB_EventSchedulerEventAdd(EVENT_APP_FINISH_EVENT_JOB); } }

Step 2.a: queue:

Queue position Event

1 EVENT_APP_BASIC_START_JOB

2 EVENT_APP_NOTIFICATION_START_JOB

3

(see step 3.a)




Step 2.b, queue:


1 EVENT_APP_NOTIFICATION_START_JOB

2

3

(see step 3.b)

Step 2.c, queue:


1

2

3

Queue became empty, which triggers “EVENT_APP_FINISH_EVENT_JOB”. (see step 5).

Step 3.a, incoming event “EVENT_APP_BASIC_START_JOB” executes CmdclassBasicSetSend(..).

Callback status executes ZCB_JobStatus(..) (see step 4).

if(EVENT_APP_BASIC_START_JOB == event) { if(JOB_STATUS_SUCCESS != CmdClassBasicSetSend…, ZCB_JobStatus)) { ZCB_EventSchedulerEventAdd(EVENT_APP_NEXT_EVENT_JOB); } }

Step 3.b, incoming event “EVENT_APP_NOTIFICATION_START_JOB” executes

UnsolicitedNotificationAction (..). Callback status executes ZCB_JobStatus(..) (see step 4).

if(EVENT_APP_NOTIFICATION_STOP_JOB == event) { NotificationEventTrigger(…); if(JOB_STATUS_SUCCESS != UnsolicitedNotificationAction(…, ZCB_JobStatus)) { ZCB_EventSchedulerEventAdd(EVENT_APP_NEXT_EVENT_JOB); }

}

Step 4, ZCB_JobStatus triggers “EVENT_APP_NEXT_EVENT_JOB (see step 2.b and 2.c).

PCB(ZCB_JobStatus)(TRANSMISSION_RESULT * pTransmissionResult)




{ UNUSED(pTransmissionResult); if(TRANSMISSION_RESULT_FINISHED == pTransmissionResult->isFinished) {

ZCB_EventSchedulerEventAdd(EVENT_APP_NEXT_EVENT_JOB); } }

Step 5, finish by changing state to “STATE_APP_IDLE”:

if(EVENT_APP_FINISH_EVENT_JOB == event) { ChangeState(STATE_APP_IDLE);

}

7.7 Task pool

API Files in module

ZW_task.h ZW_task.h + ZW_task.c

The objective of the Task pool is to provide a pluggable architecture to make multi-tasking applications easier to write and more flexible. The module is a standalone module and the framework does not depend on this module.

The implementation uses a task queue of elements of type TASK_POOL_JOB. The size of the queue (defined by TASK_POOL_SIZE) is by default set to 5 but can be changed for an application. Each element includes information to control task handling. The Task pool itself needs to be executed by a timer or by the ApplicationPoll() function in order to check the pool. Only one task-job is executed for each TaskApplicationPoll() call. A task-job (Boolean) status is returned to indicate if the task has executed the job or not. If task-job returns FALSE or nothing, the Task pool goes to next task-job in the pool.

A task can be added by calling the following function:

BYTE TaskAdd(BOOL (CODE *CBPolltask)(void), BYTE* pTaskName)

The Task pool jobs can be executed by calling the following function:

BOOL TaskApplicationPoll(void)

The rest of the API and functions’ description can be found in the ZW_task.h .

7.8 Test Interface

The Test Interface (TI) is a UART intended for interfacing between a node and a terminal using ASCII characters. A simple handler is built on top of the UART in order to handle different commands.




The TI is using an 8 bits channel associated to a handler function. Each channel can be used to define a set of commands.

An application can allocate a channel by calling the following function:

BOOL ZW_test_interface_allocate( BYTE channel, VOID_CALLBACKFUNC(pCallback)(BYTE channel, BYTE * pString));

The ZW_test_interface_allocate function will initialize the TI and allocate the given channel to the callback handler function.

As the channel is defined by an 8 bit value, it can be represented with ASCII characters in a terminal. By default, the ZAF uses the channel 0x61, which is represented by the letter ‘a’ in the ASCII table.

The format used for sending a command through a channel is the following: “channel command”. Hence, a command for channel 0x61 written in the terminal would be “a command” for the ZAF. If the channel ‘a’ is allocated correctly, the allocated callback handler function will be called with channel ‘a’ and a pointer to a string containing “command”.

7.8.1 UART settings

The following settings are used for the UART communication:

- Baud: 115200

- Parity: None

- Data bits: 8

- Stop bits: 1

- Hardware Flow Control: None

7.8.2 Test Interface in the sample applications

All sample applications except SensorPIR implement the TI. Wall Controller, Power Strip and Switch On/Off use the default ZAF channel (0x61:‘a’).

Thus, if another channel is to be set up, another value must be used, e.g.0x62 (‘b’),0x63 (‘c’). It is recommended to use lowercase letters ASCII characters to simplify terminal commands.

The Door Lock sample application uses the TI for two purposes: Input user codes and use Client Side Authentication (CSA). When using CSA during S2 bootstrapping, the user must enter a 10 digit code on the door lock to authenticate the SIS. If a connection to the TI is open during the process, the door lock will transmit a message telling the developer to enter the following command: “a csa <code>” where <code> will be e.g. 1234567890. In the door lock application, this will call the callback handler function associated with channel ‘a’ and a give the string “csa 1234567890” as an argument.

7.8.3 Defined commands for the default ZAF channel

The commands defined for channel 0x61 in the ZAF are defined in Table 7




Table 7, Channel 0x61:'a' commands

Command (usage) Description

a kxy[z] This command is used to simulate key inputs on the node.

Arguments: x : key number. It can take values in 1..6 y : key action. It can take the following values:

- d = key down

- u = key up

- p = key press

- h = key hold (where z=seconds, but only value is 10)

- t = key triple press

Examples :

“a k1d” Key 1 is down

“a k3u” Key 3 is up

“a k1t” Key 1 is triple pressed

a gp This command is used to get the state of a hardware pin.

a reset This command will trigger the device to Reset to factory default. The device will

issue a Device Reset Locally Notification via the Lifeline.

a csa code This command is used to input a DSK code into the device when performing S2 bootstrapping with Client Side Authentication (CSA).

Arguments: code : 10 number digit used for authenticating the SIS.

Example:

“a csa 1234567890” will give the 1234567890 DSK digits to the node.

a lms This command is used to start Learn Mode.

a lme This command is used to end Learn Mode.

a wdr This command is used to resets the chip using the watchdog.

a ast This command prints out the Application State

It requires IO_ZDP03A_EXTRAS to be defined.

a ZW This command prints out the application version.

a help This command prints the help information message

It requires IO_ZDP03A_HELP to be defined.




8 PORTING GUIDE

8.1 Changes in 6.81.01

In 6.81.01, all CCs are updated so that Set commands will fail if input values are not correct according to specification. This is done to make sure that Supervision Report includes the correct status.

In order to fulfill this requirement, the following API calls are changed:

handleCommandClassUserCodeSet() declared as an extern function inCommandClassUserCode.h: It now returns a boolean.

handleCommandClassDoorLockOperationSet() declared as an extern function inCommandClassDoorLock.h: It now returns a boolean.

8.2 Porting from 6.71.0x to 6.8x.0x

The following headlines are based on a review of the Door Lock Key Pad application. Please inspect the code for details regarding each of the items.

8.2.1 ZAF_pm replaces Battery_plus

The replacement triggers a list of changes in the application described in the following.

8.2.1.1 ApplicationIdle replaces AppPowerDownReady

Battery_plus included AppPowerDownReady() as an external function which the application had to implement. This module is no longer used. Instead, ApplicationIdle() is added to all applications in the SDK. This function is called from ApplicationPoll() and checks a number of things in order to tell whether the app/framework is ready idling. The easiest way to port is copying it from one of the SDK 6.8x applications.

8.2.1.2 No arguments for loadStatusPowerLevel and one less argument for Transport_OnApplicationInitSW

All functions taking a function pointer to a powerdown function in Battery_plus must have these arguments removed.

8.2.1.3 ApplicationPoll takes an argument and return a value

The argument tells the application whether the protocol is ready to sleep and the return value tells the protocol whether the application is ready to sleep.

8.2.2 ApplicationInitSW must return node type

Returning the node type tells the protocol what type of device it is: listening or non-listening.




8.2.3 App must trigger Smart Start after initialization

This applies to both an included node and a non-included node. The Smart Start functionality in the protocol will take care of what to do.

8.2.4 The module slave_learn_plus is moved to the protocol

As a result ZW_NetworkLearnModeStart() replaces StartLearnModeNow() and ApplicationNetworkLearnModeCompleted() replaces LearnCompleted(). The node ID argument can have a couple of extra values to check for besides the Node ID.

SDK 6.71.0x has support multiple security levels, Multi-cast support, Command class Supervision for security S2, improved command Class API for Multi-cast support and some additional features (see Error! Reference source not found.).

8.3 Porting from 6.61.0x to 6.71.0x

8.3.1 Security configuration in Config_app.h

Please see caption 5.2.5 for configuration of security authentication and levels.

8.3.2 General changes in command classes

All command classes are changed for an improved API for Multi-cast support. Source endpoint parameter is part of the API. Idea is application call command class API with AGI profile and the command class extracts node destinations from AGI module. The Command class API has a new callback functionality to returns the status for each destination node and a finish flag for job done (see Error! Reference source not found.).

Example of unsolicited API in SDK 6.61.0x:

JOB_STATUS CmdClassBasicSetSend( #ifndef MULTI_CHANNEL_TRANSPORT BYTE option, BYTE dstNode, #else /* MULTI_CHANNEL_TRANSPORT */ TRANSMIT_OPTIONS_TYPE_EX* pTxOptionsEx, #endif /* MULTI_CHANNEL_TRANSPORT */ BYTE bValue, VOID_CALLBACKFUNC( pCbFunc )(BYTE val) );;

Example of unsolicited API in SDK 6.71.0x:

JOB_STATUS CmdClassBasicSetSend( AGI_PROFILE* pProfile, BYTE sourceEndpoint, BYTE bValue, VOID_CALLBACKFUNC(pCbFunc)(TRANSMISSION_RESULT * pTransmissionResult));




8.3.3 Utilities modules

The AGI module is changed for Multi-cast support. The application need only to configure AGI, why all functionality getting destination nodes now is handled by one function call, used by command classes.

agi.h Description

AGI_SpecificGroupIdSet(…)

AGI_NodeIdListInit(…)

AGI_NodeIdListGetNext(…)

ReqTxOptions(…)

ValidateNodeListStatus(…)

Discarded functions

ReqNodeList(…) New function use in all command classes to extract node list.

Association_plus.h Description

AssociationGetLifeLineNodeID() Discarded

battery_monitor.h Description

* Small changes in current API ActivateBattNotificationTrigger() New function to reactivate battery low report

Module OTA_util are extended to support firmware update of a host chip

Ota_util.h Description

OtaInit(…) Updated with callback function firmware update of host chip

OtaHostFWU_WriteFinish() New function for host update OtaHostFWU_Status(…) New function for host update handleFirmWareIdGet(…) New function to get firmware Id of target

IO handling uses a new setup why “io_zdp03a” module is update:

Discarded modules New modules

keyman.h + .c

one_button.h + .c

p_button.h + .c

key_driver.h + .c

gpio_driver.h + .c

interrupt_driver.h + .c

Transport-layer is changed for Multi-cast support and handling security levels.

Transport_OnApplicationInitSW(..) includes security authentication flag.

ApplicationSecureKeysRequested() is a new function to deliver security levels that is called byprotocol.




Discarded modules New modules

ZW_TransportNative.h + .c

ZW_TransportSecurity.h + .c

ZW_TransportZIP.h + .c

ZWZip6lowPanIphc.h + .c

ZW_AES128.h

ZW_TransportMulticast.h + .c

ZW_TransportSecProtocol.h + .c

New modules

Ev_man.c: event scheduler functionality (see 7.6)

ZW_task.h + .c: Task pool functionality (See 7.7)

ZW_test_interface.h + .c and ZW_test_interface_driver.h + .c: UART support functionality (see7.8)

Nvm_util.h + .c: NVM data migration (See Appendix C)




APPENDIX A IMPLEMENTING A NEW COMMAND CLASS

All implementations must be based on Command Classes defined in [13], [14], [15] and [16]. In addition, certain rules in the framework must be followed to ensure correct operation:

Unsolicited events must use the request buffer provided by the ZW_tx_mutex module.

Response events must use the response buffer provided by the ZW_tx_mutex module.

Only CC modules must use transmit buffers provided by the ZW_tx_mutex module.

The Handler for incoming commands

The Handler parses the frame based on the CC and chooses an action for reading and writing data to the application. The action is defined as an external function call in the Command Class module header file. It is up to the application to implement the function.

void

handleCommandClassCommandClassName (

RECEIVE_OPTIONS_TYPE_EX *rxOpt, /* IN receive options */

ZW_APPLICATION_TX_BUFFER *pCmd, /* IN Payload from the received frame */

BYTE cmdLength /* IN Number of command bytes including the

command */

)

{

/*Insert all command Class commands in the switch case*/

switch (pCmd->ZW_Common.cmd)

{

case COMMAND_1:

:

Break;

case COMMAND_2:

:

Break;

case COMMAND_3:

:

Break;

}

See 6.1.2 regarding details of the frame flow.

Incoming Get Command (Response job)

Implement an external get-function in module h-file and add Doxygen compatible function header on the function for automatic documentation generation:

/**

* @brief Comment function...

* @param description of input par.

* @return description return value.

*/

extern <return type> handleCommandNameGet(<input parameters>);

Implement response job in module c-file (Figure 12). Start to extract response buffer from ZW_tx_mutex

module by calling GetResponseBuffer(). If GetResponseBuffer()returns a NULL-pointer the




buffer is not free and the operation must be cancelled. The Z-Wave Plus Application Framework will always cancel an operation if no buffer is available. It is only possible to handle one response operation at a time.

Build the frame by filling in the CC and the command and call external function to get the value handleCommandNameGet().

Now call Transport_SendResponse()to transmit the buffer. Remember to add

ZCB_ResponseJobStatus as callback. The transmit buffer is automatically freed in the callback. If the

call of “Transport_SendResponse()” returns FALSE, it means that there is a transmission problem

and the transmit buffer must be freed by calling FreeResponseBuffer().

void

handleCommandClassCommandClassName (…)

{

switch (pCmd->ZW_Common.cmd)

{

case COMMAND_CLASS_NAME_GET:

{

if(TRUE == Check_not_legal_response_job(rxOpt))

{

/*Get/Report do not support endpoint bit-addressing*/

return;

}

{

/*extract transmit buffer for response job*/

ZW_APPLICATION_TX_BUFFER *pTxBuf = GetResponseBuffer();

/*Check if buffer is free*/

if(NON_NULL( pTxBuf ))

{

/*Build transmit option out from receive option rxOpt */

TRANSMIT_OPTIONS_TYPE_SINGLE_EX *pTxOptionsEx;

RxToTxOptions(rxOpt, &pTxOptionsEx); /*Build response frame */

pTxBuf->ZW_COMMAND_CLASS_NAME_ReportFrame.cmdClass COMMAND_CLASS_NAME;

pTxBuf-> ZW_COMMAND_CLASS_NAME_ReportFrame.cmd = COMMAND_CLASS_NAME_REPORT;

pTxBuf-> ZW_COMMAND_CLASS_NAME_ReportFrame.val = handleCommandNameGet();

if(ZW_TX_IN_PROGRESS != Transport_SendResponseEP(

(BYTE *)pTxBuf,

sizeof(ZW_COMMAND_CLASS_NAME_ReportFrame),

pTtxOptionsEx,

ZCB_ResponseJobStatus))

{

/*Job failed, free transmit-buffer pTxBuf by cleaning mutex*/

FreeResponseBuffer();

}

}

}

Break;

:

}

Figure 12, Module source code for a response job.

Appendix B shows a sequence diagram for a secure incoming Get frame.

Unsolicited event (Request job)

Implement an unsolicited event-function in module h-file and add Doxygen compatible function header on the function for automatic document generation (Figure 13). Use JOB_STATUS as return type on the function for returning status of the job. Function return status JOB_STATUS_BUSY if transmit buffer is




occupied or the ZW_SendData() call failed on protocol API. The value JOB_STATUS_SUCCESS is

returned if the frame was successfully sent.

/**

* @brief Comment function...

* @param[in] pProfile pointer to AGI profile

* @param[in] sourceEndpoint source endpoint

* @param[in] description of input par.

* @param pCbFunc callback function when job is done. Can be initialized to NULL.

* @return JOB_STATUS of the call.

*/

JOB_STATUS CommandClassNameRequestJob(

AGI_PROFILE* pProfile,

BYTE sourceEndpoint,

<input par>,

VOID_CALLBACKFUNC(pCbFunc)(TRANSMISSION_RESULT * pTransmissionResult));

Figure 13, Unsolicited event function declaration in the module header file.

Implement request job in module c-file (Figure 14). Start to extract response buffer from ZW_tx_mutex

module by calling GetRequestBuffer(pCbFunc). If GetRequestBuffer()returns NULL-pointer, the

buffer is not free and the operation must be cancelled. The Z-Wave Plus Application Framework will always cancel an operation if no buffer is available. It is only possible to handle one request at a time.

Build frame by filling in the CC, the Command and the value to send.

Now call Transport_SendRequest()to transmit the buffer. Remember to add

ZCB_RequestJobStatus as callback. The transmit buffer is automatically freed in the callback. If the

call of “Transport_SendRequest()” returns FALSE, there was a transmission problem and the

transmit buffer must be freed by calling FreeRequestBuffer().

Return JOB_STATUS_SUCCESS to tell the application that the job was sent and the application can now

wait for the callback status from the job in order to check whether it was successfully received at the destination.




JOB_STATUS

CommandClassNameRequestJob(

AGI_PROFILE* pProfile,

BYTE sourceEndpoint,

<input par>,

VOID_CALLBACKFUNC(pCbFunc)(BYTE val))

{

/*extract transmit buffer for request job*/

ZW_APPLICATION_TX_BUFFER *pTxBuf = GetRequestBuffer(pCbFunc);

if( IS_NULL( pTxBuf ) )

{

/*Ongoing job is active.. just stop current job*/

return JOB_STATUS_BUSY;

}

else

{

TRANSMIT_OPTIONS_TYPE_EX* pTxOptionsEx = NULL;

/*Build request frame */

pTxBuf->ZW_COMMAND_CLASS_NAME_ReportFrame.cmdClass COMMAND_CLASS_NAME;

pTxBuf-> ZW_COMMAND_CLASS_NAME_ReportFrame.cmd = COMMAND_CLASS_NAME_REPORT;

pTxBuf-> ZW_COMMAND_CLASS_NAME_ReportFrame.val = <input par>;

/*Get transmit options (node list)*/

pTxOptionsEx = ReqNodeList( pProfile,

(CMD_CLASS_GRP*) &(pTxBuf->ZW_Common.cmdClass),

sourceEndpoint);

if( IS_NULL( pTxOptionsEx ) )

{

/*Job failed, free transmit-buffer pTxBuf by cleaning mutex */

FreeRequestBuffer();

return JOB_STATUS_NO_DESTINATIONS;

}

if(ZW_TX_IN_PROGRESS != ZW_TransportMulticast_SendRequest(

(BYTE *)pTxBuf,

sizeof(ZW_COMMAND_CLASS_NAME_ReportFrame),

TRUE, /*TRUE: Add Supervision Get on S2 job*/

pTxOptionsEx,

ZCB_RequestJobStatus))

{

/*Job failed, free transmit-buffer pTxBuf by cleaning mutex*/

FreeRequestBuffer();

return JOB_STATUS_BUSY;

}

return JOB_STATUS_SUCCESS;

}

Figure 14, Unsolicited event function implementation in the module c-file.




APPENDIX B SCENARIO RECEIVING A GET COMMAND

This scenario (Figure 15) shows how an incoming secure frame (CC X Get) is handled through the layers from protocol to application. The application responds (CC X Report) and passes it back through the layers to the node in question.

Figure 15, Sequence diagram of how Z-Wave Plus Framework handle an incoming Get command.




APPENDIX C DATA MIGRATION

The SDK 6.7x contains an improved security implementation, Security S2.

SDK 6.5x and 6.6x supports device with or without Security 0. Any application based upon SDK 6.7x will support Security S2 and have legacy support for Security 0.

Therefore the NVM of a device with an application based upon SDK 6.5x or 6.6x must have its NVM data rearranged and the Security 0 key moved to Security S2.

Figure 16 shows how NVM data is migrated from a Security 0 based SDK 6.5x/6.6x application to 6.7x .

Figure 16, NVM data migration from SDK 6.5x/6.6x with security to SDK 6.7x based application

SDK 6.7x

Sec 0 network key

SDK 6.5x/6.6x with security

Sec 0 - Reserved

Pro

toco

l N

VM

are

a

Security NVM Layout

Sec 0 network key

6.7x App data

App

licatio

n N

VM

are

a

Pro

toco

l N

VM

are

a

App

licatio

n N

VM

are

a




Figure 17,NVM data migration from SDK 6.5x/6.6x without security to SDK 6.7x based application

The implementation of data migration can be found in:

<SDK_folder>\ProductPlus\ApplicationUtilities\nvm_util.c

Function: static void NvmApplicationDataMigrate(void)

The function will read the application content in the NVM and evaluate the layout type based on data content.

A switch statement is used to rearrange the NVM data based upon the layout type.

In case a product is limited in such a way that for example an upgrade from 6.5x/6.6x without security is not possible because all old products are security 0 enabled only, then the switch case can be optimized by removing case 0x03.

SDK 6.7x

Application NVM Layout (eeprom.h)

SDK 6.5x/6.6x without security

Sec 0 - Reserved

Security NVM Layout

6.7x App data

Pro

toco

l N

VM

are

a

App

licatio

n N

VM

are

a

Pro

toco

l N

VM

are

a

App

licatio

n N

VM

are

a




In case a product is limited in such a way that for example an upgrade from 6.5x/6.6x with security is not possible because all old products do not support security 0, then the switch cases can be optimized by removing cases 0x17, 0x15, 0x13, and 0x11.

Used values for identifying data migration paths are detailed in Table 8.

Table 8, Data migration cases

Value Description

0x03 Upgrade from SDK 6.6x based application without security.

0x17 Upgrade from SDK 6.6x based application with security. Securely included node.

0x15 Upgrade from SDK 6.5x based application with security. Securely included node.

0x13 Upgrade from SDK 6.6x based application with security. Non secure included node.

0x11 Upgrade from SDK 6.5x based application with security. Non secure included node.

0x01 Upgrade from SDK 6.5x based application without security.




APPENDIX D SLAVE MIGRATION USING 128KB EXTERNAL NVM

Migration from an existing slave product using 128KB external NVM and based on SDK 6.5x/6.6x to SDK 6.71.0x/6.81.0x is now possible using OTA firmware update. However, the migration process consists of a two-stage process as shown on the figure below:

Figure 18, App migration process.

The migration process relies on a new bootloader that support a new compressed OTZ hex file format (*.otz). Due to memory shortage in external NVM when using SDK 6.81.0x the bootloader update must be done in an SDK 6.61.0x environment. SDK 6.61.01and newer support building of intermediate apps containing the new bootloader.




REFERENCES

[1] Silicon Labs, SDS11847, Software Design Specification, Z-Wave Plus Device Type Specification. [2] Silicon Labs, SDS11846, Software Design Specification, Z-Wave Plus Role Type Specification. [3] Silicon Labs, SDS12657, Software Design Specification, Z-Wave Command Class, A-M. [4] Silicon Labs, SDS12652, Software Design Specification, Z-Wave Command Class, N-Z. [5] Silicon Labs, INS12366, Instruction, Working in 500 Series Environment User Guide. [6] ZAD, ZAD13111, Z-Wave Alliance Document, Z-Wave Plus Assigned Icon Types. [7] SDS11274, Software Design Specification, Security 2 Command Class [8] APL12956, Application Note, Z-Wave Association Basic [9] SDS13321, Software Design Specification, Supervision Command Class [10] APL13475, Application Note, Z-Wave Development Basics [11] SDS13826, Z-Wave Smart Start Requirements [12] SDS13968, Smart Start User Input Identifier Registry [13] SDS13781, Z-Wave Application Command Class Specification [14] SDS13782, Z-Wave Management Command Class Specification [15] SDS13783, Z-Wave Transport-Encapsulation Command Class Specification [16] SDS13784, Z-Wave Network-Protocol Command Class Specification


http://www.silabs.com

Silicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701USA

Smart. Connected. Energy-Friendly.

Productswww.silabs.com/products

Qualitywww.silabs.com/quality

Support and Communitycommunity.silabs.com

DisclaimerSilicon 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 and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Silicon Labs shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System 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.

Trademark InformationSilicon 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®, ISOmodem®, Micrium, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, 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. All other products or brand names mentioned herein are trademarks of their respective holders.

Z-Wave Plus Application Framework v6.8x · 2019-12-05 · ALL Based on INS13427– Z-Wave Plus...

Documents

Transcript of Z-Wave Plus Application Framework v6.8x · 2019-12-05 · ALL Based on INS13427– Z-Wave Plus...