105546r02ZB Zigbee Rf4ce Sc-ZigBee Remote Control Application Profile Public

ZigBee RF4CE: ZRC Profile
Specification
Version 2.0
ZigBee Document 13-0442-23
September 4th, 2014
Sponsored by: ZigBee Alliance
Accepted by
This document has been accepted for release by the ZigBee

Alliance Board of Directors
Abstract
This specification defines the protocol infrastructures and

services available to applications operating on the ZigBee
RF4CE platform using the ZigBee Remote Control 2.0
profile.
Keywords
ZigBee; RF4CE, application, ZRC, profile.
September 4th, 2014
Copyright 1996-2014 by the ZigBee Alliance.

2400 Camino Ramon, Suite 375, San Ramon, CA 94583, USA
http://www.zigbee.org
All rights reserved.
Permission is granted to members of the ZigBee Alliance to reproduce this document for their own use or the use of other ZigBee Alliance
members only, provided this notice is included. All other rights reserved. Duplication for sale, or for commercial or for-profit use is strictly
prohibited without the prior written consent of the ZigBee Alliance.
ZigBee RF4CE: ZRC Profile Specification, v2.0
ZigBee Document 13-0442-23, September 4th, 2014
This page is intentionally blank
Page ii
Copyright 2014, ZigBee Standards Organization. All rights reserved.
Notice of use and disclosure

The ZigBee Specification is available to individuals, companies and institutions free of charge for all
non-commercial purposes (including university research, technical evaluation, and development of
non-commercial software, tools, or documentation). No part of this specification may be used in
development of a product for sale without becoming a member of ZigBee Alliance.
Copyright ZigBee Alliance, Inc. (2008-2014). All rights Reserved. This information within this
document is the property of the ZigBee Alliance and its use and disclosure are restricted.
Elements of ZigBee Alliance specifications may be subject to third party intellectual property rights,
including without limitation, patent, copyright or trademark rights (such a third party may or may not
be a member of ZigBee). ZigBee is not responsible and shall not be held responsible in any manner for
identifying or failing to identify any or all such third party intellectual property rights.
This document and the information contained herein are provided on an AS IS basis and ZigBee
DISCLAIM ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
(A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY
INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK
RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN NO EVENT WILL ZIGBEE BE
LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA,
INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR
EXEMPLARY, INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND,
IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE
INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
LOSS OR DAMAGE.
All Company, brand and product names may be trademarks that are the sole property of their respective
owners.
The above notice and this paragraph must be included on all copies of this document that are made.
ZigBee Alliance, Inc.
2400 Camino Ramon, Suite 375
San Ramon, CA 94583
Page iii
Page iv
Participants
When this document was released, the RF4CE SIG Technical Working Group leadership was
composed of the following members:
Michael Sallas: Chair
Joseph Reddy: Vice chair
Ross Gilson: Secretary
Nick Shepherd: Technical Editor
Contributions were made to this document by the following members:

Sorin Aliciuc
Bram Van den Bosch
Jan van Ee
Ed Farrari
Ross Gilson
Arsham Hatambeiki
Wilco van Hoogstraeten
Phil Jamieson
Alin Lazar
Thomas De Prycker
Bill Reams
Joseph Reddy
Michael Sallas
Stig Torud
Jignesh Vaghela
Page v
Page vi
Revision Histor y
Revision
00
Date
Details
Editor
4th September,
2014
First approved release of ZigBee RF4CE: ZRC Profile

Specification Version 2.0
Nick Shepherd
Page vii
Page viii
Table of Contents
1
Introduction .............................................................................................................................................. 1
1.1 Definitions ....................................................................................................................................... 1
1.2 Conformance levels ......................................................................................................................... 2
1.3 Abbreviations .................................................................................................................................. 2
1.4 Conventions..................................................................................................................................... 2
1.4.1
Number formats .................................................................................................................. 2
1.4.2
Transmission order ............................................................................................................. 2
1.4.3
Message sequence charts .................................................................................................... 3
1.4.4
Reserved values .................................................................................................................. 3
1.5 References ....................................................................................................................................... 3
General ZRC command frame format ...................................................................................................... 4
Supported Features ................................................................................................................................... 5
ZRC command frames ............................................................................................................................. 7

4.1 Actions command frame ................................................................................................................. 7
4.1.1
Action control ..................................................................................................................... 7
4.1.2
Action data .......................................................................................................................... 8
ZRC profile constants and attributes ...................................................................................................... 10

5.1 ZRC profile constants.................................................................................................................... 10
5.2 ZRC profile attributes.................................................................................................................... 10
5.2.1
aplZRCProfileVersion ...................................................................................................... 12
5.2.2
aplZRCProfileCapabilities ............................................................................................... 12
5.2.3
aplActionRepeatTriggerInterval ....................................................................................... 13
5.2.4
aplActionRepeatWaitTime ................................................................................................ 14
5.2.5
aplActionBanksSupportedRx ............................................................................................ 14
5.2.6
aplActionBanksSupportedTx ............................................................................................. 14
5.2.7
aplActionCodesSupportedRx ............................................................................................ 14
5.2.8
aplActionCodesSupportedTx ............................................................................................ 15
5.2.9
aplMappableActions ......................................................................................................... 15
5.2.10 aplActionMappings ........................................................................................................... 16
5.2.11 aplIRDBVendorSupport .................................................................................................... 19
5.2.12 aplZRCActionBanksVersion ............................................................................................. 19
5.2.13 aplHomeAutomation ......................................................................................................... 19
5.2.14 aplHomeAutomationSupported ......................................................................................... 20
Functional description ............................................................................................................................ 21

6.1 Initialization .................................................................................................................................. 21
6.2 Action procedure ........................................................................................................................... 21
6.2.1
Actions procedure for Actions Originator ........................................................................ 22
6.2.2
Actions procedure for Actions Recipient .......................................................................... 22
6.2.3
Action procedure message sequence charts ...................................................................... 23
6.3 Binding Procedure ......................................................................................................................... 24
6.3.1
ZRC Originator side binding procedure............................................................................ 24
6.3.2
ZRC Recipient side binding procedure ............................................................................. 25
Page ix
6.4
Configuration Procedure................................................................................................................25
6.4.1
ZRC Recipient Side Configuration Procedure ..................................................................26
6.4.2
ZRC Originator Side Configuration Procedure .................................................................29
6.4.3
After Binding ....................................................................................................................31
6.5 Action Mapping Procedure............................................................................................................34
6.5.1
Action Mapping Update ....................................................................................................34
6.6 Notification Procedure...................................................................................................................34
6.6.1
Request Action Mapping Negotiation Sub Type ..............................................................35
6.6.2
Request Home Automation Pull Sub Type .......................................................................35
6.6.3
Request Selective Action Mapping Update Sub Type ......................................................35
7
Annex A: Use of HA Commands and Attributes ...................................................................................37

7.1 Introduction ...................................................................................................................................37
7.2 Configuration.................................................................................................................................37
7.3 HA Instances .................................................................................................................................38
7.4 HA Actions ....................................................................................................................................38
7.5 HA Attributes ................................................................................................................................38
7.6 Action and Attribute specific remarks ...........................................................................................39
7.6.1
Scenes ...............................................................................................................................39
7.6.2
Generic Actions ................................................................................................................39
7.7 Example:Use Case Without Feedback...........................................................................................39
7.7.1
Assumptions ......................................................................................................................39
7.7.2
Binding..............................................................................................................................39
7.7.3
After The Binding .............................................................................................................40
7.7.4
Button Press ......................................................................................................................40
7.8 Example: Use Case With Feedback...............................................................................................40
7.8.1
Assumptions ......................................................................................................................40
7.8.2
Binding..............................................................................................................................40
7.8.3
After The Binding .............................................................................................................41
7.8.4
Button Press ......................................................................................................................41
7.8.5
External Status Update ......................................................................................................41
Annex B: Standard IR Database format .................................................................................................42

8.1 Control Flags .................................................................................................................................42
8.2 Control data ...................................................................................................................................43
8.2.1
Number of Symbol Timing Definitions ............................................................................43
8.2.2
Number of Symbols in Press Frame ..................................................................................43
8.2.3
Number of Symbols in Repeat Frame ...............................................................................44
8.2.4
Number of Symbols in Release Frame ..............................................................................44
8.2.5
Number of Symbols in Toggle Sequence ..........................................................................44
8.2.6
Carrier Period (CP) ...........................................................................................................44
8.3 Symbol Timing Definitions ...........................................................................................................44
8.4 Frame Definitions ..........................................................................................................................45
8.4.1
Press Frame Definition......................................................................................................45
8.4.2
Repeat Frame Definition: ..................................................................................................45
8.4.3
Release Frame Definition:.................................................................................................45
8.5 Toggle Definition ..........................................................................................................................45
8.5.1
Example: ...........................................................................................................................46
Page x
Annex C: Example of a configuration phase consisting of GDP and ZRC configuration procedures ... 47
Page xi
Page xii
List of Figures
Figure 1 Format of the actions command frame ........................................................................................... 7
Figure 2 Format of the action record fields .................................................................................................. 7
Figure 3 Format of the action control field ................................................................................................... 7
Figure 4 Modifier Bits .................................................................................................................................. 8
Figure 5 Format of the action data field ....................................................................................................... 8
Figure 6 Format of the action banks supported rx and action banks supported tx attributes ...................... 14
Figure 7 Format of the action codes supported rx and action codes supported tx attributes entry ............. 15
Figure 8 Format of the aplMappableActions attribute ............................................................................... 15
Figure 9 Format of the aplActionMappings attribute entry ........................................................................ 16
Figure 10 Format of the Mapping Flags field............................................................................................. 16
Figure 11 Format of the RF Descriptor field .............................................................................................. 17
Figure 12 Format of the RF Config Sub-field ............................................................................................ 17
Figure 13 Format of the IR Descriptor field ............................................................................................... 18
Figure 14 Format of the IR Config Sub-field ............................................................................................. 18
Figure 15 Format of aplIRDBVendorSupport attribute .............................................................................. 19
Figure 16 Format of the aplHomeAutomation attribute entry .................................................................... 20
Figure 17 Format of the HA Attribute Status ............................................................................................. 20
Figure 18: Format of the Home Automation Supported attribute entry ........................................................ 20
Figure 19 Action procedure with a Key Down trigger ............................................................................... 23
Figure 20 Action procedure with key repeat trigger ................................................................................... 23
Figure 21 Action control one-shot procedure ............................................................................................. 24
Figure 22 Configuration Procedure ............................................................................................................ 26
Figure 23 Action mapping negotiation procedure ...................................................................................... 31
Figure 24 IRDB Vendor Support Announcement ...................................................................................... 32
Figure 25: Home Automation Supported Announcement procedure ............................................................ 33
Figure 26 - Format of the Dirty Flags field of the Request Home Automation Pull Sub Type Payload ...... 35
Figure 27 - Request Selective Action Mapping Update Sub Type ................................................................ 36
Figure 28 The HA Actions Recipient is combined with a ZigBee Pro node in a single physical device. .. 37
Figure 29 HA Actions and HA attributes ................................................................................................... 37
Figure 30 IR Code Format.......................................................................................................................... 42
Figure 31 Control Flags Format ................................................................................................................. 43
Figure 32 Relation of various timing values (with Mark Space Definition = 0, and Use Carrier = 1). ..... 45
Figure 33 Example of configuration phase consisting of GDP and ZRC configuration procedures .......... 47
Page xiii
Page xiv
List of Tables
Table 1 GDP command frames utilized by the ZRC profile ........................................................................ 4
Table 2 Values of the command code field for the ZRC profile .................................................................. 4
Table 3 Supported GDP Features per type of device ................................................................................... 5
Table 4 - Supported ZRC Features per type of device .................................................................................... 6
Table 5 Action type Description................................................................................................................... 7
Table 6 ZRC profile constants .................................................................................................................... 10
Table 7 ZRC attribute summary ................................................................................................................. 11
Table 8 Format of the ZRC profile capabilities attribute............................................................................ 13
Table 9 Flag Definitions ............................................................................................................................. 17
Table 10 Description of the RF Config Fields ........................................................................................... 18
Table 11 Description of the IR Config Fields ............................................................................................ 19
Table 12 - Client Notification sub-type ......................................................................................................... 35
Table 13 Format of Toggle Definition field. .............................................................................................. 46
Table 14 Toggle Definition field for the example given ............................................................................ 46
Page xv
Page xvi
ZigBee Document 13-0442r23ZB, September 4th, 2014
Introduction
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
This specification specifies the ZigBee RF4CE profile 0x03: ZigBee Remote Control 2.0 (ZRC 2.0).
The ZRC profile defines commands and procedures to enable CE RC applications. The ZRC profile
shall use the GDP 2.0 (see [R4] ), or later version, on top of the RF4CE network layer (see [R1] ).
The profile defines two types of device: a ZRC Originator and a ZRC Recipient. The ZRC Originator
shall act as the Binding Originator (see [R4] ), and may be used to support devices such as remote
controls. The ZRC Recipient shall act as the Binding Recipient (see [R4] ) and may be used to support
devices such as TVs and Set Top Boxes. A ZRC Originator may be realized by either an RF4CE
controller or an RF4CE target. Conversely, a ZRC Recipient shall only be realized by an RF4CE target
since more resources need to be available. When binding two RF4CE targets, like a TV and an STB,
one of them shall act as a ZRC Originator and the other shall act as a ZRC Recipient. In this case, the
one that acts as a ZRC Originator may act as a ZRC Recipient for other bindings.
19
1.1
Devices implementing this specification shall also implement the ZigBee Remote Control Specification
Version 1.1 (see [R3] ). When paired with a ZRC1.1 device, a ZRC2.0 device must follow all aspects
and rules of the ZRC1.1 specification, such as formatting of action commands, discovery commands,
etc.
Definitions
Action Mapping
Client
A ZRC Originator or ZRC Recipient, that has mappable actions that can be
remapped by the Action Mapping Server
Action Mapping
Server
A ZRC Originator or ZRC Recipient, that can remap the mappable actions of
an Action Mapping Client
Actions Originator
A ZRC Originator or ZRC Recipient, that is capable of sending Actions

commands
Actions Recipient
A ZRC Originator or ZRC Recipient, that is capable of receiving Actions

commands
Bind
Making a logical association between nodes at the profile layer by pairing

the nodes at the RF4CE-NWK layer (see [R1] ) , performing a mutual
configuration at the GDP layer (see [R4] ) and validating this association at
the GDP layer.
Device
An object that has IEEE 802.15.4 functionality.
HA Instance
An HA Instance is the combination of an instance of the HA action bank that

controls a device on the HA network, and an instance of the HA attribute set
that allows to monitor this device. The HA action bank and HA attribute set
share the same Instance ID.
HA Instance ID
A natural number between 0 and 31 that identifies the HA Instance.
HA Actions
Originator
An Actions Originator, that is capable of sending at least a subset of the HA

command set and/or has at least a subset of the HA attributes implemented.
HA Actions Recipient
An Actions Recipient, that is capable of receiving and properly processing

all the HA commands, and configuring all the HA attributes of a remote
node.
Node
A device that has ZigBee RF4CE functionality.
Originator
The device from which a ZigBee RF4CE transmission is sent.
Recipient
The device to which a ZigBee RF4CE transmission is directed.
ZRC Originator
An RF4CE target or RF4CE controller that supports this profile, and acts as
the binding originator for a given binding.
ZRC Recipient
A RF4CE target that supports this profile, and acts as the binding recipient
for a given binding.
Page 1
20
21
22
1.2
Conform ance levels
The following words, used throughout this document, have specific meanings:
May
A key word indicating a course of action permissible within the limits of the standard (may
equals is permitted).
Shall
A key word indicating mandatory requirements to be strictly followed in order to conform

to the standard; deviations from shall are prohibited (shall equals is required to).
Should
A key word indicating that, among several possibilities, one is

recommended as particularly suitable, without mentioning or excluding others; that a
certain course of action is preferred but not necessarily required; or, that (in the negative
form) a certain course of action is deprecated but not prohibited (should equals is
recommended that).
1.3
Abbr eviations
CE
Consumer electronics
CEC
Consumer electronics control
HA
Home Automation
HDMI
High-definition multimedia interface
ID
Identifier
IEEE
Institute of electrical and electronic engineers
LQI
Link quality indication
MAC
Medium access control
NIB
Network information base
NLDE
Network layer data entity
NLME
Network layer management entity
NWK
Network
ORG
Originator
PAN
Personal area network
PHY
Physical
POS
Personal operating space
RC
Remote control
REC
Recipient
RF
Radio frequency
RF4CE
Radio frequency for consumer electronics
SAP
Service access point
23
1.4
24
25
26
1. 4. 1 Numb e r f o r m at s
In this specification hexadecimal numbers are prefixed with the designation 0x and binary numbers
are prefixed with the designation 0b. All other numbers are assumed to be decimal.
27
28
29
30
31
1. 4. 2 T ran sm is si o n o r d e r
The frames in this specification are described as a sequence of fields in a specific order. All frame
formats are depicted in the order in which they are transmitted by the PHY, from left to right, where the
leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least
significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields that
Page 2
Conventions
32
33
are longer than a single octet are sent to the MAC in the order from the octet containing the lowest
numbered bits to the octet containing the highest numbered bits.
34
35
36
37
38
39
1. 4. 3 M essa g e se q u e n c e c ha rt s
During this specification, message sequence charts are used to illustrate the flow of various operations.
Instances are labeled with the layer (APL for the application or NWK for the network) followed by the
node type (ORG for the originator or REC for the recipient). Primitives are shown in normal style but,
for simplicity, without the entity prefix (i.e. NLDE or NLME), e.g. NLME-PAIR.response becomes
PAIR.response. Over the air command frames are labeled in italic text.
40
41
42
43
1. 4. 4 Re s erv ed v al u e s
Unless otherwise specified, all reserved fields appearing in a frame structure (c.f. Figure 3) shall be set
to zero on transmission and ignored upon reception. Reserved values appearing in multi-value fields
(c.f.Table 2) shall not be used.
44
45
46
47
48
49
50
51
52
53
54
55
56
1.5
References 1
[R1]
ZigBee RF4CE Specification, ZigBee Alliance document 094945, Version 1.0.1, November,
2010.
[R2] High-Definition Multimedia Interface Specification, HDMI Licensing, LLC, Version 1.3a,
November 10, 2006.
[R3] ZigBee Remote Control Profile Specification, Version 1.1.0, November 2010, ZigBee Alliance
document 094946r01,
[R4] ZigBee RF4CE Generic Device Profile, Version 2.0, September 2014, ZigBee Alliance
document 13-0396r29
[R5] ZigBee RF4CE: ZRC Profile Action Banks V2.0, ZigBee Alliance document 13-0614r08,
September 2014.
[R6] ZigBee Manufacturer Code Database, ZigBee Alliance document 053874r25, April 2014
[R7] ZigBee RF4CE: Device Type List, ZigBee Alliance document 094950r1, September 2014.
The version and date information in these references was correct at the time this document was released.
Page 3
57
General ZRC command frame format
58
59
60
The ZRC profile command frame format shall conform to the GDP Generic Command frame format,
see [R4] section 4.
The ZRC profile shall utilize the GDP commands listed in Table 1.
61
Table 1 GDP command frames utilized by the ZRC profile
62
GDP
command
code
ZRC Recipient
ZRC Originator
Tx
Rx
Tx
Rx
Description
0x00
Generic Response
O-
0x01
Configuration Complete
0x02
Heartbeat
0x03
Get attributes
0x04
Get attributes response
0x05
Push attributes
0x06
Set attributes
0x07
Pull attributes
0x08
Pull attributes response
0x09
Check Validation
0x0a
Client Notification
0x0b
Key Exchange
63
64
65
66
For commands defined in the ZRC profile, the GDP command frame sub-field of the frame control
field shall be set to 0 and the command code sub-field shall be set to one of the non reserved values
listed in Table 2.
67
Table 2 Values of the command code field for the ZRC profile
68
ZRC
command
code
0x00-0x05
0x06
0x07-0x0f
ZRC Recipient
ZRC Originator
Description
Reference
Tx
Rx
Tx
Rx
Reserved
Actions
4.1
Reserved
69
70
Page 4
71
Supported Features
72
73
The ZRC profile shall utilize the GDP features listed in Table 3. All features not explicitly listed may
be supported optionally.
Table 3 Supported GDP Features per type of device
74
GDP Feature
75
76
77
78
79
80
81
82
ZRC Recipient
ZRC Originator
Binding Originator
Binding Recipient
Identify Client
Identify Server
Notification Client
O see Note 1
O see Note 1
Notification Server
O see Note 2
see Note 2;
O when RF4CE Target
- when RFCE Controller
Poll Client
O see Note 3
Poll Server
O when RF4CE Target

- when RFCE Controller
Key Exchange Initiator
Key Exchange
Responder
M when RF4CE Target
Notes:
1.
2.
3.
Notification Client is Mandatory if Identify Client is supported

Notification Server is Mandatory if Identify Server is supported
When RF4CE Controller, Poll Client is Mandatory if Notification Client is supported
The ZRC profile shall utilize the ZRC features listed in Table 4. All features not explicitly listed may
be supported optionally.
Page 5
Table 4 - Supported ZRC Features per type of device
83
GDP Feature
84
85
86
87
ZRC Recipient
ZRC Originator
Actions Originator
Actions Recipient
O when RF4CE
Target
- when RF4CE
Controller
Action Mapping Client
O when Actions
Originator
- when not Actions
Originator
Action Mapping Server
O when Actions
Recipient
- when not Actions
Recipient
HA Actions Originator
O when Actions
Originator
- when not Actions
Originator
O when Actions
Recipient
- when not Actions
Recipient
Note that the certification process may impose additional requirements on supported features for
product certification. The implementers should consult the PICS document for certification
requirements.
Page 6
88
89
90
91
92
93
94
95
96
4.1
ZRC command frames

Actions command frame
The actions command frame is generated as a result of a trigger on the Actions Originator and is sent to
an Actions Recipient to request the recipient fulfill the requested action. This command shall be
directed either to a specific node that is already in the pairing table or broadcast (to all nodes in all
PANs in which case the frame shall only pass the RF4CE NWK source filtering in those nodes that are
paired with the current node). The Actions command frame shall be formatted as illustrated in Figure 1.
For each trigger that occurs, a separate Action record is created in the Actions command frame.
Bits: 8
Variable
Frame control
x0000110
Action
record 1
ZRC header
ZRC payload
Action
record n
Each action control record field shall be formatted as illustrated in Figure 2.

Bits: 8
Variable
Action control
Action data
Figure 2 Format of the action record fields
100
101
102
103
Variable
Figure 1 Format of the actions command frame
97
98
99
4. 1. 1 Ac t io n c o n t ro l
The action control field is 8 bits in length, and is formatted as illustrated in Figure 3.
Bits: 0-1
Action
type
2-3
Reserved
4-7
Modifier
bits
Figure 3 Format of the action control field
104
105
4. 1. 1 .1 Ac t io n t yp e
106
107
The action type field is 2 bits in length and is described in Table 5.

Table 5 Action type Description
108
Action type
Action name
Description
0b00
Reserved
0b01
Start
The action generated when a trigger occurs that may be

repeated such as the Key Down trigger.
0b10
Repeat
The action generated by a repeating trigger such as a Key

Repeat trigger. A Repeat action shall be preceded by a Start
action.
0b11
Atomic
An action generated in response to any application-defined

trigger that does not require repeats. An example of this
could be a key press that the application does not want to
repeat.
109
Page 7
110
When the action type field is set to the reserved value, the action record shall be ignored.
111
4. 1. 1 .2 M o d if ie r Bit s
112
113
114
115
116
The modifier bits field is 4 bits in length and indicates the modifier bits for this action record, see
Figure 4. These modifier bits shall at all times be included by the source, but it depends on the action
bank (see Modifier Bits Parsing column in [R5] section 2) of this action record if these modifier bits
are parsed by the recipient or ignored by the recipient, as indicated by [R5] section 2.
Bits: 0
GUI modifier
ALT modifier
SHIFT modifier
CTRL modifier
Figure 4 Modifier Bits
117
118
4. 1. 1 .2 .1 G UI mo d if ie r
119
120
The GUI modifier is 1 bit in length and when set to 1 indicates that the GUI modifier is enabled for
this action record.
121
4. 1. 1 .2 .2 AL T mo d if i e r
122
123
The ALT modifier is 1 bit in length and when set to 1 indicates that the ALT modifier is enabled for
this action record.
124
4. 1. 1 .2 .3 SH IF T m o d if i er
125
126
The SHIFT modifier is 1 bit in length and when set to 1 indicates that the SHIFT modifier is enabled
for this action record.
127
4. 1. 1 .2 .4 CT RL m o d i f i er
128
129
The CTRL modifier is 1 bit in length and when set to 1 indicates that the CTRL modifier is enabled
for this action record.
130
4. 1. 2 Ac t io n d at a
131
132
The Action data has a variable length, and is formatted as illustrated in Figure 5.
Bits:8
Action payload
length
Action bank
Action code
0/16
Action Vendor
Variable
Action payload
Figure 5 Format of the action data field
133
134
4. 1. 2 .1 Ac t io n p a ylo ad l en g t h
135
136
The action payload length field is 1 octet in length and shall contain the length of the action payload
field.
137
4. 1. 2 .2 Ac t io n b an k
138
139
140
The action bank field is 1 octet in length and specifies the action bank being addressed, see section 2 of
[R5] .
Page 8
141
4. 1. 2 .2 .1 HDM I- C EC
142
143
144
The HDMI CEC action bank supports the use of up to 256 different HDMI CEC User Control codes.
The action bank and action codes that correspond to specific HDMI-CEC commands are defined in
[R5] .
145
4. 1. 2 .2 .2 HI D
146
147
148
149
150
The HID Usage Pages support the use of 65536 different Usage IDs per table. The action code (see
section4.1.2.3) is only 8 bits in length and can thus only accommodate 256 different Usage IDs per
action bank. For this reason, the HID Usage Tables that contain more than 256 different Usage IDs,
are split over multiple action banks. The action banks and action codes that correspond to specific HID
commands are defined in [R5] .
151
4. 1. 2 .2 .3 Ho m e Au t o m at io n
152
153
154
155
156
The Home Automation action bank supports the use of 256 different HA commands.
The Home Automation action bank is replicated 32 times: it resides on action banks 0x80 to 0x9f. This
enables having multiple instances of the HA action set, e.g. two sets of On/Off control buttons on the
HA Actions Originator, to control two different lamps. The bottom 5 bits indicate the instance ID. The
action banks and action codes that correspond to specific HA commands are defined in [R5] .
157
4. 1. 2 .2 .4 V en d o r Sp e c if i c
158
159
160
161
Each vendor can define up to 32 vendor specific action banks, identified by the combination of its
vendor ID (16-bits) and a vendor specific action bank ID (0-31). [R6] contains a list of ZigBee Vendor
IDs.
There are 3 action bank ranges, each accommodating the full set of 32 vendor specific action banks.
162
163
164
165
166
167
168
169
170
171
172
0xa0-0xbf: The vendor ID is implicit, it shall be assumed to be equal to the vendor ID of the
source. The bottom 5 bits indicate the vendor specific action bank ID.
0xc0-0xdf: The vendor ID is implicit, it shall be assumed to be equal to the vendor ID of the
recipient. The bottom 5 bits indicate the vendor specific action bank ID.
0xe0-0xff: The vendor ID is explicitly included in the action data, as a command vendor field.
The bottom 5 bits indicate the vendor specific action bank ID.
Note with respect to command discovery:
The vendor specific action banks with implicit vendor ID shall be included in the command
discovery.
The vendor specific action banks with explicit vendor ID shall NOT be included in the
command discovery, since the vendor ID is not known during the command discovery.
173
4. 1. 2 .3 Ac t io n c o d e
174
The action code field is 8-bits in length and shall contain the operand.
175
4. 1. 2 .4 Ac t io n Ve n d o r
176
177
178
The action vendor field is 16-bits in length and shall contain the vendor ID, see [R6] . It shall only be
included when indicated so in the Vendor ID Included column of [R5] section 2 for the given command
bank.
179
4. 1. 2 .5 Ac t io n p a ylo ad
180
181
The action payload field has a variable length and shall contain the additional operands, if any, required
by the command specified in the action code field. For details of this field, see [R5]
Page 9
182
183
184
185
5.1
ZRC profile constants and attributes

ZRC profile constants
The constants that define the characteristics of the ZRC profile are presented in Table 6.
Table 6 ZRC profile constants
186
Constant
Description
Value
aplcMaxConfigWaitTime
The maximum time the

Binding Recipient shall wait to
receive a command frame from
a Binding Originator during its
configuration phase.
100 milliseconds
aplcMaxActionRepeatTriggerInterval
The maximum time between

consecutive actions command
frame transmissions indicating
a repeated action.
200 milliseconds
aplcShortRetryDuration
The time that an action control

record should be repeated, see
Table 10.
100 milliseconds
187
188
189
190
191
192
193
194
195
196
5.2
ZRC profile attribut es
The ZRC profile defines attributes required to manage the way the ZRC profile operates. These
attributes are presented in Table 7.
When attributes are pushed by a remote node to a node, or the node gets attributes from a remote node,
the node shall process the received attributes, and it shall store in non-volatile storage any information
contained in these attributes that the node requires for its future operation (e.g. the ZRC Profile Version
of the remote node it is binding with).
When a node pulls attributes, it may store in non-volatile storage any information contained in these
attributes (e.g. the Action Mappings to be used by the node).
Page 10
Table 7 ZRC attribute summary
197
Index
interpretation
of Second
Array
Dimension
Entry Type
Remote
Attribute
Access
Default
Reserved for GDP

use
0x800x9f
aplZRC
ProfileVersion
0xa0
Scalar
16-bit
unsigned
integer
0x0200
Get/Push
0x0200
aplZRCProfile
Capabilities
0xa1
Scalar
Bitmap
of 32
bits
All Zeros
to
All Ones
Get/Push
Device
dependent
8-bit
unsigned
integer
50 to
aplcMax
Action
Repeat
Trigger
Interval
(0.5 *
aplcMax
Action
Repeat
Trigger
Interval)
AR
(2 *
aplcMax
Action
Repeat
Trigger
Interval)
aplActionRepeat
TriggerInterval
0xa2
Scalar
AO
Optional
Index
interpretation
of First Array
Dimension
-
Mandatory
Scalar or
Array
-
Entry Range
Identifier
0x000x7f
Attribute
Reserved for stack
use
aplActionRepeat
WaitTime
0xa3
Scalar
16-bit
unsigned
integer
(2 *
aplcMax
Action
Repeat
Trigger
Interval)
to (4 *
aplcMax
Action
Repeat
Trigger
Interval)
aplActionBanks
SupportedRX
0xa4
Scalar
Bitmap
of 256
bits
All Zeros
to
All Ones
AR
Get/Push
Device
dependent
aplActionBanks
SupportedTX
0xa5
Scalar
Bitmap
of 256
bits
All Zeros
to
All Ones
AO
Get/Push
Device
dependent
aplIRDBVendor
Support
0xa6
Scalar
Variable
length
NA
MC
Get/Push
Device
dependent
aplZRCActionBanks
Version
0xa7
Scalar
16-bit
unsigned
integer
0x0100
0xffff
Get/Push
0x0100
Reserved for scalar

profile attributes
0xa80xbf
aplActionCodes
SupportedRX
0xc0
One
dim.
Array
Action
bank
Bitmap
of 256
bits
All Zeros
to
All Ones
AR
Get/Push
Device
dependent
aplActionCodes
SupportedTX
0xc1
One
dim.
Array
Action
bank
Bitmap
of 256
bits
All Zeros
to
All Ones
AO
Get/Push
Device
dependent
One dim.
Array
0...n-1 with
n = number
of
mappable
actions
3 octets
NA
MC
Get/Push
Device
dependent
aplMappableActions
0xc2
Page 11
Scalar or
Array
Index
interpretation
of First Array
Dimension
Index
interpretation
of Second
Array
Dimension
Entry Type
Entry Range
Mandatory
Optional
Remote
Attribute
Access
Default
0xc3
One
dim.
Array
Variable
length
NA
MC
Pull
Device
dependent
aplHomeAutomation
0xc4
Two
dim.
Array
HA
Instance ID
HA
Attribute
ID
Variable
length
NA
HO
Pull
Dynamic
aplHomeAutomation
Supported
0xc5
One
Dim
Array
HA
Instance ID
Bitmap
of 256
bits
All Zeros
to
All Ones
HO
Get/Push
Device
dependent
Reserved for arrayed

profile attributes
0xc60xdf
Reserved for scalar

profile attributes
0xe00xff
Attribute
Identifier
aplActionMappings
Index of the
aplMappabl
eActions
entry to
which this
entry of
aplActions
Mappings
refers
198
Notes:
199
1. The Mandatory and Option columns use following abbreviations:
200
201
202
203
204
205
206
A: All nodes
AO: Actions Originator
AR: Actions Recipient
MS: Action Mapping Server
MC: Action Mapping Client
HO: Home Automation Actions Originator
HR: Home Automation Actions Recipient
207
5. 2. 1 apl Z R C Pr o f i le V e rs io n
208
209
210
211
212
213
The aplZRCProfileVersion attribute contains a single entry formatted as a 16-bit unsigned integer. It
shall specify the version of the ZRC profile specification to which the device was designed. The
format of this value shall be 0xJJMN representing a version JJ.M.N, where JJ is the major version
number, M is the minor version number and N is the sub-minor version number. For this version of the
ZRC profile specification, the aplZRCProfileVersion attribute shall be set to the value 0x0200,
representing v2.0.
214
5. 2. 2 apl Z R C Pr o f i le C ap a b i l it i es
215
216
217
The aplZRCProfileCapabilities attribute contains a single entry of 32 bits in length as presented in

Table 8. It shall indicate what features of the ZRC.2.0 profile this node is supporting.
Page 12
Table 8 Format of the ZRC profile capabilities attribute
218
Bit
Field
Description
supportActionsOriginator
When set to 1, the node is capable of

sending Actions commands
supportActionsRecipient
When set to 1, the node is capable of

receiving and properly processing Actions
Commands
supportHAActionsOriginator
When set to 1, the node can act as an HA

Actions Originator.
supportHAActionsRecipient
When set to 1, the node can act as an HA

Actions Recipient. A node that has this bit
set shall also implement the GDP
Notification Server.
supportActionMappingClient
When set to 1, the node can act as an

Action Mapping Client. A node that has
this bit set shall also implement the GDP
supportActionMappingServer
When set to 1, the node can act as an

Action Mapping Server. A node that has
this bit set shall also implement the GDP
supportVendorSpecificIRDBFormats
When set to 1, the node supports at least

one vendor specific IRDB format. This
field shall only be set to one if the node
also has the supportActionMappingClient
bit set. A node that has this bit set, shall
also implement the
aplIRDBVendorSupport attribute.
informAboutSupportedActions
For a ZRC Recipient:

When set to 1, the ZRC Recipient request
the ZRC Originator to be informed about
the actions the ZRC Originator supports
transmitting, during the configuration
procedure.
For a ZRC Originator:
When set to 1, the ZRC Originator shall
interrogate the ZRC Recipient about the
actions the ZRC Recipient supports
receiving, during the configuration
procedure
831
Reserved
219
5. 2. 3 ap l A ct io nR ep ea tT rig ge rIn t e r va l
220
221
222
223
224
The aplActionRepeatTriggerInterval attribute contains a single entry of 8 bits in length. It shall specify
the maximum interval in milliseconds at which actions command frames containing action records with
action type repeat shall be transmitted. Actions command frames containing action records with an
action type set to repeat can occur more frequently if there is an update to one of the action records
contained in the frame, see section 6.2.
Page 13
225
5. 2. 4 apl A ct io nR ep ea t Wa it T im e
226
227
228
The aplActionRepeatWaitTime attribute contains a single entry of 16 bits in length. It shall specify the
duration in milliseconds that a recipient of an actions command frame containing a non-atomic action
type waits before terminating the operation.
229
5. 2. 5 apl A ct io n B an ks S u p p o rt ed Rx
230
231
232
233
234
235
236
The aplActionBanksSupportedRx attribute contains a single entry of 256 bits in length. It shall indicate
what action banks the node supports receiving.
The least significant bit of this field corresponds to the action bank with ID 0x00 and the most
significant bit of this field corresponds to the action bank with ID 0xff, as illustrated in Figure 6.
237
238
Figure 6 Format of the action banks supported rx and action banks supported tx
attributes
239
240
241
The action banks are enumerated using the action bank number described in [R5] section 2.
For each bit, if the corresponding action bank is supported the bit shall be set to one. Otherwise, the bit
shall be set to zero.
242
5. 2. 6 apl A ct io n B an ks S u p p o rt edT x
243
244
245
246
247
248
249
The aplActionBanksSupportedTx attribute contains a single entry of 256 bits in length. It shall indicate
what action banks the node supports transmitting.
The least significant bit of this field corresponds to the action bank with ID 0x00 and the most
significant bit of this field corresponds to the action bank with ID 0xff, as illustrated in Figure 6.
The action banks are enumerated using the action bank number described in [R5] section 2.
For each bit, if the corresponding action bank is supported the bit shall be set to one. Otherwise, the bit
shall be set to zero.
250
5. 2. 7 apl A ct io nCo d e s Su p p o rt ed Rx
251
252
253
254
255
256
The aplActionCodesSupportedRx attribute contains a one-dimensional array of entries, indexed by the

action bank described in [R5] section 2. Each entry is 256 bits in length and shall indicate which
actions codes the node supports receiving for the corresponding action bank.
The least significant bit of this field corresponds to the action code with ID 0x00 and the most
significant bit of this field corresponds to the action code with ID 0xff, as illustrated in Figure 7.
Page 14
257
258
259
Figure 7 Format of the action codes supported rx and action codes supported tx
attributes entry
260
261
For each bit, if the corresponding action commands in the action bank is supported the bit shall be set
to one. Otherwise, the bit shall be set to zero.
262
5. 2. 8 ap l A ct io n Co d e s Su p p o rt ed T x
263
264
265
266
267
268
269
The aplActionCodesSupportedTx attribute contains a one-dimensional array of entries, indexed by the

action bank described in [R5] section 2. Each entry is 256 bits in length and shall indicate which
actions codes the nodes supports receiving for the corresponding action bank.
The least significant bit of this field corresponds to the action code with ID 0x00 and the most
significant bit of this field corresponds to the action code with ID 0xff, as illustrated in Figure 7.
For each bit, if the corresponding action commands in the action bank is supported the bit shall be set
to one. Otherwise, the bit shall be set to zero.
270
5. 2. 9 ap l Ma p p ab le A ct io n s
271
272
273
274
275
276
277
278
279
The aplMappableActions attribute contains a one-dimensional array of entries where each entry
corresponds to an action caused by a trigger on the Action Mapping Client. Each trigger which causes
an action in the array can be assigned a different action by the Action Mapping Server. The action
bank, action code and action device type contained in the entry represent the default action of the
trigger to remap. The action bank corresponds to the action bank defined in Section 5.2.5. The action
code corresponds to the action code defined in Section 5.2.7. The action device type allows an Action
Mapping Client to allow the same action bank and code to be mapped for different device types. Figure
8 shows the layout of an aplMappableActions attribute entry.
Bits: 8
Action device type
280
8
Action bank
8
Action code
Figure 8 Format of the aplMappableActions attribute
281
5. 2. 9 .1 Ac t io n d ev i ce t yp e f i eld
282
283
284
The Action device type field is 8-bits in length and shall contain a device type from [R7] . A ZRC
Recipient shall interpret a wildcard device type of 0xff in the Action device type field as invalid. The
Action Device Type indicates to what device type the RF Descriptor is to be sent.
285
5. 2. 9 .2 Ac t ion b an k f ie ld
286
The Action bank field is 8-bits in length and shall contain the bank of the action to map.
287
5. 2. 9 .3 Ac t ion c o d e f ie ld
288
289
The Action code field is 8-bits in length and shall contain the code of the action to map.
Page 15
290
5. 2. 1 0 ap l A ct io n Ma p p in g s
291
292
293
294
295
296
297
298
299
300
The aplActionMappings attribute contains a one dimensional array of entries, where each entry
corresponds to a description of the RF and IR code associated with a given action. This action is
described by the entry of aplMappableActions attribute that has the same index as the entry of the
aplActionMappings. The index into aplActionMappings should correspond to the index of the action
specified in aplMappableActions. For any action the Action Mapping Server does not want to re-map,
it should set the Use Default flag in the Mapping Flags field for the corresponding entry. Figure 9
details an index of the aplActionMappings attribute. The attribute can be read and written by both the
Action Mapping Server remotely and the Action Mapping Client locally. The length of the attribute is
variable depending on the Mapping Flags field.
Bits: 8
0/Variable
Mapping Flags
0/Variable
RF Descriptor
IR Descriptor
Figure 9 Format of the aplActionMappings attribute entry
301
302
5. 2. 1 0. 1
303
304
305
306
307
308
309
310
Figure 10 shows the formatting of the Mapping Flags field and Table 9 gives a description for each
flag. If the RF Specified bit is set then an RF Descriptor shall be included. If the IR specified is set
then an IR Descriptor will be included. If Use Default is set the Action Mapping Client shall use its
default behavior for the specified button and the RF Specified flag and IR Specified flag should be
ignored. The Permanent flag indicates if the descriptors should be used for future key presses.
If an entry in the aplMappableActions attribute has a device type of 0xff then the corresponding entry
in aplMappableActions shall have Use Default set.
Bits: 0
RF Specified
M ap p in g F l ag s
1
IR Specified
2
RF Descriptor
First
3-5
Reserved
6
Use Default
Figure 10 Format of the Mapping Flags field
311
312
Page 16
7
Permanent
Table 9 Flag Definitions
313
Bit
Field
Description
When set to 1, this indicates that an RF
descriptor is included in this attribute, and that an
RF message should be generated when this key is
pressed and kept pressed. If Use Default is set,
this field shall be ignored (treated as if it was
zero).
When set to 1, this indicates that an IR
descriptor is included in this attribute, and that an
IR message should be generated when this key is
pressed and kept pressed. If Use Default is set,
this field shall be ignored (treated as if it was
zero).
RF Specified
IR Specified
RF Descriptor First
3-5
When set to '1', the RF command is being sent out

until the key is released or until the minimum
number of transmissions are made , before the IR
command is sent out. When set to '0', the IR
command is being sent out until the key is
released or until the minimum number of
transmissions is made, before the RF command is
sent out.
Reserved
Use Default
Permanent
When set to 1, this indicates that the default

(known by the Action Mapping Client) RF and IR
codes shall be used.
When set to 1, this indicates that the codes are
permanent and can be used for all further triggers.
314
5. 2. 1 0. 2
RF De s c rip t o r
315
316
317
Figure 11 details the format of the RF Descriptor. It has a variable length and is only included if the
corresponding bit is set in the Mapping Flags field.
318
Bits: 8
RF Config
RF4CE Tx
Options
Variable
Action data Length
Action Data for

Action Record (see
Figure 2)
319
Figure 11 Format of the RF Descriptor field
320
321
322
323
324
325
326
Figure 12 and Table 10 detail the RF Config field.

The RF4CE Tx Options is 8 bits in length and shall contain the TX Options to be used when issuing the
NLDE.DataRequest primitive for the corresponding Action command frame.
The Action Data Length is 8 bits in length and shall contain the length in octets of the Action Data for
Action Record field
For details of the action data for an action record, see section 4.1.2.
Bits: 0 - 3
Minimum number
of transmissions
327
4
Keep transmitting
until key release
5
Short RF Retry
6
Atomic Action
7
Reserved
Figure 12 Format of the RF Config Sub-field

Page 17
328
Table 10 Description of the RF Config Fields
329
Bit
Field
Description
0-3
Minimum number of
transmissions
This field indicates the minimum number

of transmissions for this code. For
acknowledged RF transmissions, this field
shall be set to 1.
Keep Transmitting
Until Key Release
When set to 1, this indicates that the RF

code should continue being transmitted
after the minimum number of transmissions
have taken place, when the key is kept
pressed.
Short RF Retry
If this bit is set and in case Multiple

channel, Unicast, Acknowledge
transmission is specified in the RF4CE Tx
Options field, the action control record
should be made on each available channel,
repeated either for aplcShortRetryDuration
(instead of the standard
nwkcMaxDutyCycle) or until an
acknowledgement is received, whichever is
sooner.
Atomic Action
If this bit is set to 1, then the RF

Descriptor shall be transmitted with an
action type of Atomic with no repeats. If
this bit is set to 0, then the RF descriptor
shall begin with an action type of Start with
repeats supported.
Reserved
330
5. 2. 1 0. 3
IR D es c ri p t o r
331
332
333
Figure 13 details the format of the IR Descriptor. It has a variable length and is only included if the
corresponding bit is set in the Mapping Flags field. Table 11 gives a description of the IR Config field.
Bits: 8
IR Config
0/16
IR Vendor ID
8
IR Code Length
Variable
IR Code
Figure 13 Format of the IR Descriptor field
334
335
Bits: 0
Vendor Specific
1-7
Reserved
Figure 14 Format of the IR Config Sub-field
336
337
Page 18
Table 11 Description of the IR Config Fields
338
Bit
Field
Description
Vendor Specific
If this bit is set to 1, then the IR descriptor

is formatted in a vendor specific manner
The vendor ID that indicates the origin of
the format is contained in the IR descriptor.
If this bit is set to 0, then the IR format
specified in Annex B: Standard IR
Database format is used and an IR Vendor
ID is not included.
1-7
Reserved
339
For non vendor specific IR codes, see Annex B: Standard IR Database format.
340
5. 2. 1 0. 3. 1
341
342
343
344
The IR Vendor ID field is 16 bits in length and indicates the vendor of the IR Database format used in
the IR Code field. It shall be set to one of the vendor IDs that the Action Mapping Client has indicated
to support in the aplIRDBVendorSupport attribute. The IR Vendor field is only included if the Vendor
Specific bit is set.
345
5. 2. 1 0. 3. 2
346
The IR Code Length field is 8 bits in length and contains the length in octets of the IR Code field.
347
5. 2. 1 0. 3. 3
348
349
350
351
The IR Code field contains the description of the IR code that shall be transmitted if the corresponding
key is pressed. If the standard IR database format is used (Vendor Specific bit set to 0), the format of
the IR code field is described in section 8. If a vendor specific IR database format is used (Vendor
Specific bit set to 1), the format of the IR code field goes beyond the scope of this specification.
352
5. 2. 1 1 ap l IR DB V en d o rS u p p o rt
353
354
355
356
The aplIRDBVendorSupport attribute contains a single entry of variable length and is formatted as
illustrated in Figure 15. This entry is a vector of vendor IDs. Each vendor ID identifies a vendor for
which this device supports the vendor specific IRDB format.
357
IR V en d o r ID
IR Co d e L en g t h
IR Co d e
Bits: 16
16
Vendor ID 0
Vendor ID n-1
Figure 15 Format of aplIRDBVendorSupport attribute
358
5. 2. 1 2 ap l Z R CA ct i o n B an k s V er s io n
359
360
361
362
The aplZRCActionBanksVersion attribute contains a single entry formatted as a 16-bit unsigned

integer. It shall specify the version of the ZRC Action Banks specification (see [R5] ) to which the
device was designed. The format of this value shall be 0xJJMN representing a version JJ.M.N, where
JJ is the major version number, M is the minor version number and N is the sub-minor version number.
363
5. 2. 1 3 ap l Ho me Au t o m at io n
364
365
366
367
368
The aplHomeAutomation attribute contains a two dimensional array of entries, indexed by the HA
Instance ID and the HA Attribute ID as described in [R5] section 2.
The aplHomeAutomation attribute allows the HA Actions Originator to receive feedback from the HA
network, as described in section 7. By pulling the values of the different entries, it is informed on the
state and state changes of the devices on the HA network it controls, and the responses on its requests.
Page 19
369
370
Each entry has a variable length and is formatted as illustrated in Figure 16.
Bits: 8
HA Attribute
Status
Variable
HA Attribute
Value
Figure 16 Format of the aplHomeAutomation attribute entry
371
372
5. 2. 1 3. 1
H A At t ri b u t e St at u s
373
374
The HA Attribute Status field, is 8 bits in length and is formatted as illustrated in Figure 17.
Bits: 0
Value available
1-7
Reserved
Figure 17 Format of the HA Attribute Status
375
376
5. 2. 1 3. 1. 1
V alu e Av a il ab le
377
378
379
The Value Available field is 1 bit in length and indicates if the HA Actions Recipient has a value
available for the HA Attribute value. If this bit is set, the HA Attribute Value shall be included in the
aplHomeAutomation attribute entry.
380
5. 2. 1 3. 2
381
382
383
The HA Attribute Value field has a variable size and contains the value of the HA attribute specified by
the HA Instance ID and the HA Attribute ID. It is only included if the Value Available field in the HA
Attribute Status was set to 1. For further details, see[R5] .
384
5. 2. 1 4 apl Ho me Au t o m at io nS u p p o rt ed
385
386
387
388
389
390
391
The aplHomeAutomationSupported attribute contains a one-dimensional array of entries, indexed by

the HA Instance ID. Each entry is 256 bits in length and shall indicate which HA attributes
(aplHomeAutomation attribute) are supported for the corresponding HA Instance (see section 7.3).
The least significant bit of this field corresponds to the HA attribute with ID 0x00
(aplHomeAutomation[HA Instance ID, 0]) and the most significant bit of this field corresponds to the
HA attribute with ID 0xff (aplHomeAutomation[HA Instance ID, 255]), as illustrated in Figure 7.
H A At t ri b u t e V al u e
392
Figure 18: Format of the Home Automation Supported attribute entry
393
394
395
396
For each bit, if the corresponding HA attribute for the given HA Instance is supported the bit shall be
set to one. Otherwise, the bit shall be set to zero. If a node has at least one of the bits of the
aplHomeAutomationSupported attribute set to one, it shall implement the Notification Client.
Page 20
397
Functional description
398
399
All nodes operating according to the ZRC profile shall support security and shall ensure that the
security capable sub-field of nwkcNodeCapabilities is set to one.
400
401
402
403
404
405
406
407
6.1
408
409
410
411
412
413
414
415
A single polling constraint record is included with the Identifier set to value of 0x01 (GDP
Heartbeat)
All other nodes shall set the supportPollClient bit in the aplGDPCapabilities attribute to '0' and shall
configure the value of number of polling methods in the aplPollConstraints attribute to 0.
In the case that a node supports the reception of Hearbeat command frames, it shall set the
"supportPollServer" bit in the aplGDPCapabilities attribute to '1'. In the other case, it shall set this bit
to '0'.
416
417
418
419
420
6.2
421
422
423
424
425
A trigger is any event on a device that causes an action to occur. A trigger can be caused by a key
press, a sensor activation, a timer, or any application defined construct that is intended to cause
something to happen on the target. A trigger is the cause of an action. Common triggers for a standard
remote control device are Key Down, Key Repeat, Key Up, and Atomic triggers. Triggers are defined
by the application and they represent the hooks of the application into action records sent to the target.
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
For example, a key press of a repeating key may result in a Key Down trigger for that key. When the
Key Down trigger occurs, a Start action shall be sent to the recipient. A Key Repeat trigger occurs
every aplActionRepeatTriggerInterval while the key is pressed causing Repeat actions to be sent to the
recipient. The recipient shall process the Start action and the Repeat action as a repeating operation at
its own application defined rate. The Actions Originator shall stop generating Key Repeat triggers for
that key when a Key Up trigger occurs which is generated when the user releases the key. The Actions
Originator shall send one additional actions command immediately after a Key Up trigger occurs that
does not contain an action record corresponding to that Key.
A key press, sensor activation, or some other event on the Actions Originator may cause an Atomic
trigger that may result in an Atomic action being sent to the recipient. An Atomic action does not
repeat and is only sent once. A recipient shall execute the associated operation for that action and shall
not expect a repeat.
An Actions Originator that supports the ZRC profile shall support the generation of a minimum of one
action record at a time. A Actions Recipient that supports the ZRC profile shall support the processing
of multiple simultaneous action records. When a second trigger is initiated by the Actions Originator a
new actions command shall be immediately transmitted to the Actions Recipient, containing all current
action records. The aplActionRepeatTriggerInterval shall be reset when an actions command is
transmitted. On a Key Up trigger on the Actions Originator a new actions command shall be
immediately transmitted to the Actions Recipient, containing all current action records. If no action
records exist, only an actions command shall still be transmitted without any action records indicating
that no triggers are currently occurring.
Every actions command frame shall reflect the triggers that have occurred since the last actions
command frame was transmitted, as well as any currently repeating keys for which a Key Up trigger
has not yet occurred. If a Key Down trigger occurred on a certain key, an action record for that key
Initialization
A node operating according to the ZRC2.0 profile shall set all NIB attributes, except for
nwkActivePeriod and nwkDutyCycle, to their default values, see [R1] .
A node operating according to the ZRC2.0 profile shall configure the GDP attributes as described
below.
A node that supports transmission of periodic Heartbeat command frames shall set the
supportPollClient bit in the aplGDPCapabilities attribute to '1' and shall configure the
aplPollConstraints attribute as follows:
The number of polling methods supported shall be set to value greater or equal to 1
Action pr ocedure
Actions are sent from some Actions Originator (such as an RC) to a recipient node (such as a TV) in
response to a trigger on the Actions Originator. Actions shall be started, repeated or sent atomically.
Actions are the way in which an event on an Actions Originator can cause an effect on an Action
Recipient.
Page 21
450
451
452
453
454
with an action type of Start shall be included. If a Key Repeat trigger occurred, an action record for
the respective key with an action type of Repeat shall be sent. If any Key Up trigger occurred, an
actions command frame shall be sent without an Action record for that key a Key Up trigger was
received for. If a Key Down trigger occurred on a certain key that should not be repeated, an action
record for the trigger shall be sent with an action type of atomic.
455
456
457
458
459
460
461
462
463
464
6. 2. 1 Ac t io n s p r o c ed u r e f o r Ac t io ns O rig in at o r
On a Key Down Trigger, the Actions Originator shall generate and transmit an action record with an
action type of Start to the appropriate recipient. Action records are always encapsulated in an actions
command frame as shown in Figure 1.
A Key Repeat trigger shall occur every aplActionRepeatTriggerInterval. On a Key Repeat trigger, the
Actions Originator shall generate and transmit an action record with an action type of Repeat to the
appropriate recipient. When a Key Up trigger occurs for the repeated key, an actions command frame
shall be sent without an action record for the key that a Key Up trigger was received for.
On an Atomic Trigger, the Actions Originator shall generate and transmit an action record with an
action type of Atomic to the appropriate recipient.
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
6. 2. 2 Ac t io n s p r o c ed u r e f o r Ac t io ns R e cip ie nt
On receipt of an actions command frame, the Actions Recipient shall process each of the action records
as follows.
If the action type in the action control record is set to Start, or if the action type in the action control
record is set to Repeat and the recipient did not receive a Start action control record, the Actions
Recipient shall execute the requested operation for the corresponding action. The Actions Recipient
shall expect additional actions commands indicating either a repeat, or an actions command not
containing an action record for this trigger indicating an end of the repeated action.
If the action type in the action record is set to Repeat, the recipient shall continue to execute the
requested operation for the corresponding action repeatedly at an application specific rate. The actions
command frame with the action type set to Repeat is received in the following cases: following sending
an actions command frame in which the action type was set to Start for this command; or following
sending an actions command frame in which the action type was set to Repeat for this command.
While an action record with the action type set to Repeat for a given action is received within a rate of
aplActionRepeatWaitTime, the recipient shall continue the operation for this action. If an actions
command frame is not received within aplActionRepeatWaitTime, or an actions command frame is
received within aplActionRepeatWaitTime that does not contain an action record for the given
command, the recipient shall terminate the operation for this action.
Page 22
484
6. 2. 3 Ac t io n p ro ce d u re m e ss ag e s equ en c e ch ar t s
Actions
originator
User
Actions
Recipient

containing an Action record
with Action type of Start for
given key
Key Down trigger
Perform
single
operation
aplActionRepeat
TriggerInterval
aplActionRepeat
WaitTime
without Action record
for given key
Key Up trigger
RC key is not pressed long enough to cause a Key Repeat trigger.

Actions Originator only performs a single operation. Actions Originator
sends an Actions command frame in response to the Key Up trigger.
485
486
Figure 19 Action procedure with a Key Down trigger
487
488
489
490
491
492
493
Figure 19 illustrates a key press of a repeatable key. A Key Down trigger occurs when the user presses
the key and an actions command frame is transmitted containing an action record with action type
Start. Every aplActionRepeatTriggerInterval, a Key Repeat trigger will occur. When a Key Repeat
trigger occurs, the Actions Originator sends an actions command frame containing an action record
with action type Repeat.
When a Key Up trigger for the given key occurs, the Actions Originator shall send an actions command
frame with no action record for the given key.
User
Key Down trigger
Actions
Originator
Actions
Recipient
User

containing an Action record with
Action type of Start for given key
Key Down trigger
Actions
Originator
Actions
Recipient

Action type of Start for given key
Perform single operation
aplActionRepeat
TiggerInterval
aplActionRepeatWaitTime
Actions command frame containing

an Action record with Action type of
Repeat for given key
aplActionRepeat
TiggerInterval
Begin operation cycle
Key Repeat trigger

aplActionRepeat
TiggerInterval
Perform single operation

Action type of Repeat for given key
aplActionRepeat
TiggerInterval
Key Up Trigger
Begin operation cycle

Action type of Repeat for given key
Key Repeat trigger
Key Repeat trigger

aplActionRepeat
TiggerInterval
Actions command frame containing

an Action record with Action type of
Repeat for given key
Key Repeat trigger
aplActionRepeat
TiggerInterval

for given key
Key Up trigger

for given key
Stop operation cycle

Stop operation cycle
a) RC key is pressed long enough to cause a Key Repeat trigger. Actions

recipient performs single operation and then begins cycle. Action originator
transmits an Actions command frame in response to the Key Up trigger but it is
not received by the Actions recipient.
b) RC key is pressed long enough to cause a Key Repeat trigger. Actions

Recipient performs single operation and then begins cycle. Actions Originator
transmits an Actions command frame in response to the Key Up trigger that is
received by the Actions Recipient.
494
495
496
Figure 20 Action procedure with key repeat trigger
Page 23
497
498
499
500
501
502
503
Figure 20 illustrates the action procedure in which a Key Down trigger occurs and then multiple Key
Repeat triggers occur in response to the user keeping the key pressed for some time. A Key Down
trigger occurs when the user presses the key and an actions command frame is transmitted with an
action record with action type Key Pressed. Every aplActionRepeatTriggerInterval a Key Repeat
trigger occurs if the given key is still pressed. Every time the Key Repeat trigger occurs, an actions
command frame is generated and transmitted with an action record for the given key with an action
type of Key Repeat until the user releases the key.
504
505
506
507
508
509
The Actions Recipient receives the actions command frame containing the action record for the pressed
key with an action type of Key Repeat and begins repeating the original command at an application
defined rate. While the Actions Recipient receives an action record for this key with an action type of
Key Repeat within aplActionRepeatWaitTime, it continues the operation until either this timer expires
or the recipient receives an actions command frame with no action record for the given key. At this
point, the Actions Recipient terminates the operation corresponding to the given key.
510
511
512
513
514
515
516
After sending an actions command frame with an action record with an action type of Key Repeat, the
Actions Originator shall always send an actions command frame with no action record for the given
key, indicating its release.
The Actions Recipient starts a timer and stops its repeated operation (a) if no actions command frame is
received within aplActionRepeatWaitTime or (b) on receipt of the actions command frame with no
action record for the given key.
User
Atomic trigger
Actions
Originator
Actions
Recipient

containing an Action record
with Action type of Atomic for
given key
Perform
single
operation
Atomic trigger occurs on Actions Originator.
517
518
Figure 21 Action control one-shot procedure
519
520
Figure 21 illustrates the procedure when an atomic trigger occurs. An actions command frame with an
action type of atomic for the operation is sent to the target.
521
522
523
524
6.3
525
6. 3. 1 Z RC O rig in at o r s id e b in d ing p ro ce du re
526
527
528
529
530
531
532
533
This section contains the specific settings for ZRC 2.0 to be used in the binding procedure described in
the GDP 2.0 specification, and illustrates the binding behavior.
For the discovery process, the ZRC Originator shall set the following parameters: the profile identifier
list disclosed as supported by the node shall contain at least the values 0x01 and 0x03 (both ZRC
profile identifiers) and the list of profile identifiers by which incoming discovery response command
frames are matched shall contain at least the values 0x01 and 0x03 (ZRC profile identifiers).
For the pairing process with a ZRC2.0 Recipient, the profile identifier list disclosed as supported by the
node in the pair request shall contain at least the value 0x03, but not 0x01.
Binding Procedur e
Devices implementing the ZRC profile shall support the Validation-based Binding procedure, specified
in the GDP2.0. In the Validation-based Binding procedure, a ZRC Originator shall act as a Binding
Originator and a ZRC Recipient shall act as a Binding Recipient.
Page 24
534
535
536
For the pairing process with a ZRC1.x Target, the profile identifier list disclosed as supported by the
node in the pair request shall contain at least the value 0x01, but not 0x03.
For a description of the configuration phase of ZRC 2.0, see section 6.4.
537
6. 3. 2 Z RC R e cip i en t s id e b in d i n g p r o c ed u r e
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
If a discovery request is received for which the profile identifier list contains at the value 0x03, and if
the conditions mentioned in section 7.2 of [R4] are fulfilled, the application of a ZRC Recipient node
shall respond to discovery requests containing at least the 0x03 profile identifier. The discovery
response shall contain at least the profile identifier 0x03, but not the 0x01 profile identifier. The user
string of the discovery response shall be formatted as described in the GDP2.0 profile
If a discovery request is received for which the profile identifier list contains the value 0x01, but not
the value 0x03, and if the Push Button Stimulus Received flag (see [R4] ) is pending, and if the
conditions mentioned in [R1] section 3.5.9.3 are fulfilled, the application of a ZRC Recipient node
shall respond to discovery requests containing the 0x01 profile identifier, but not the 0x03 profile
identifier. The discovery response shall contain the 0x01 profile identifier, but not the 0x03 profile
identifier in this case. The ZRC1.1 specification for discovery/pairing is followed in this instance.
For the pairing process with a ZRC2.0 Originator, the profile identifier list disclosed as supported by
the node in the pair response shall contain at least the values 0x03, but not 0x01.
For the pairing process with a ZRC1.x Controller, the profile identifier list disclosed as supported by
the node in the pair response shall contain at least the values 0x01, but not 0x03.
For a description of the configuration phase see section 6.4.
554
555
556
557
558
559
560
561
562
563
564
565
6.4
Configuration Pr ocedure
Since the ZRC 2.0 profile is operating according to the GDP specification (see section 7.2 of [R4] ), it
implements a configuration procedure in which profile dependent information is exchanged between
ZRC Recipient and ZRC Originator. The configuration procedure is terminated successfully by the
configuration complete/generic response command frame exchanges. The configuration procedure is
shown in Figure 22.
This configuration procedure is described in more detail for the ZRC Recipient and ZRC Originator
separately in the sections below.
Section 9 contains an example of a configuration phase consisting of GDP and ZRC configuration
procedures
Page 25
ZRC
Recipient
Enter ZRC
configuration state
Exchange
Version,
Capability
Information
ZRC Originator
PushAttribute (aplZRCProfileVersion, aplZRCProfileCapabilities,

aplZRCActionBanksVersion)
Enter ZRC
configuration state
GenericResponse
GetAttributes (aplZRCProfileVersion, aplZRCProfileCapabilities,
GetAttributesRsp (aplZRCProfileVersion, aplZRCProfileCapabilities,
GetAttributes (aplActionBanksSupportedRx)
GetAttributesRsp (aplActionBanksSupportedRx)
[Action
Banks
Discovery]
PushAttributes (aplActionBanksSupportedTx)
GenericResponse
GetAttributes (aplActionsSupportedRx,BankA-BankB)
...
[Action
Codes Rx
Discovery
by Recipient]
GetAttributesRsp (aplActionsSupportedRx,BankA-BankB)
GetAttributes (aplActionCodesSupportedRx,...-BankZ)
GetAttributesRsp (aplActionCodesSupportedRx,...-BankZ)
PushAttributes (aplActionCodesSupportedTx,BankA-BankB)
GenericResponse
...
[Action
Codes Tx
Discovery
PushAttributes (aplActionCodesSupportedTx,...-BankZ)
GenericResponse
Configuration complete
GenericResponse
566
Figure 22 Configuration Procedure
567
568
6. 4. 1 Z RC R e cip i en t S id e C o n f ig u r at io n P ro c ed u re
569
570
6. 4. 1 .1 E xc h an g e o f v e r sio n an d c ap ab il it y i nf o rm at i on f ro m Z R C
O ri g in at o r t o Z R C Re cip i ent
571
572
573
574
575
576
First, the ZRC Recipient shall collect the ZRC profile version, ZRC profile capabilities information and
the ZRC action banks version from the ZRC Originator. To collect this information from the ZRC
Originator, the ZRC Recipient shall request that the NWK layer enables its receiver and waits either for
a maximum duration of aplcMaxConfigWaitTime or until a push attributes command frame that
contains the aplZRCProfileVersion attribute, the aplZRCProfileCapabilities attribute and the
aplZRCActionBanksVersion is received from the ZRC Originator.
577
578
579
580
581
582
Page 26
If such a frame is received within aplcMaxConfigWaitTime the ZRC Recipient shall attempt to
process it. The ZRC Recipient shall generate and transmit a corresponding generic response
command frame, containing the appropriate response code.
If no such frame is received within aplcMaxConfigWaitTime, the ZRC Recipient shall
consider the configuration a failure and the ZRC configuration procedure shall be terminated.
All other incoming frames from the ZRC Originator shall be discarded.
583
584
6. 4. 1 .2 E xc h an g e o f v e r sion and c ap ab il it y i nf o rm at i on s et t i n g s f ro m
Z RC R e cip i en t t o Z R C O ri gin at o r
585
586
587
588
589
590
Next, the ZRC Recipient shall wait until the ZRC Originator interrogates it for the ZRC profile version,
ZRC capabilities and the ZRC action banks version. To do this, the ZRC Recipient shall request that
the NWK layer enables its receiver and wait either for a maximum duration of
aplcMaxConfigWaitTime or until a get attributes command frame containing the
aplZRCProfileVersion, aplZRCProfileCapabilities and the aplZRCActionBanksVersion attributes is
received from the ZRC Originator.
591
592
593
594
595
596
If such a frame is received within aplcMaxConfigWaitTime, the ZRC Recipient shall attempt
to process it. The ZRC Recipient shall generate and transmit a corresponding get attributes
response command frame, containing the requested attributes, back to the ZRC Originator.
597
6. 4. 1 .3 M u t u al ex ch an g e of s u p p o rt ed a ct io n b an k s
598
599
600
601
602
603
604
605
606
607
608
If the ZRC Recipient indicates that it wants to be informed about the actions the ZRC Originator
supports transmitting (by having the informAboutSupportedActions bit set to 1 in the
aplZRCProfileCapabilites), or if the ZRC Originator indicates that it wants to be informed about
the actions the ZRC Recipient supports receiving (by having the informAboutSupportedActions
bit set to 1 in the aplZRCProfileCapabilites), the procedure described in this section shall be
executed. Otherwise it shall be skipped.
Next, ZRC Recipient shall wait until the ZRC Originator interrogates it about the action banks it
supports receiving.
To do this, the ZRC Recipient shall request that the NWK layer enables its receiver and wait either for
a maximum duration of aplcMaxConfigWaitTime or until a get attributes command frame is received
from the ZRC Originator, containing the aplActionBanksSupportedRx attribute.
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
to process it. The ZRC recipient shall generate and transmit a corresponding get attributes
response command frame, containing the requested attributes, back to the ZRC Originator.
Next, the ZRC Recipient shall collect information from the ZRC Originator about the action banks that
the ZRC Originator supports transmitting.
To collect this information from the ZRC Originator, the ZRC Recipient shall request that the NWK
layer enables its receiver and waits either for a maximum duration of aplcMaxConfigWaitTime or until
a push attributes command frame that contains the aplActionBanksSupportedTx attribute, is received
from the ZRC Originator.
to process it. The ZRC recipient shall generate and transmit a corresponding generic response
628
629
6. 4. 1 .4 E xc h an g e o f a ct io n c o d e s su ppo rt ed f or r ec e iv e f ro m ZR C
Re ci p i en t t o Z R C O r i g in at o r
630
631
632
633
634
635
If the ZRC Originator indicates that it wants to be informed about the actions the ZRC Recipient
supports receiving (by having the informAboutSupportedActions bit set to 1 in the
aplZRCProfileCapabilites), the procedure described in this section shall be executed. Otherwise it
shall be skipped.
Until the ZRC Recipient has been interrogated about the aplActionCodesSupportedRx attribute for each
non-HA action bank that is indicated to be supported by both the aplActionBanskSupportedRx attribute
Page 27
636
637
638
639
640
of the ZRC Recipient, and the aplActionBanksSupportedTx attribute of the ZRC Originator (ANDoperation on both attributes, and blanking out the HA action banks), the ZRC Recipient shall request
that the NWK layer enables its receiver and wait either for a maximum duration of
aplcMaxConfigWaitTime or until an get attributes command frame that contains the
aplActionCodesSupportedRx attribute is received from the ZRC Originator.
641
642
643
644
645
646
647
648
649
650
651
652
653
If a get attributes command frame that contains the aplActionCodesSupportedRx attribute, is

received within aplcMaxConfigWaitTime, the ZRC Recipient shall attempt to process it. The
ZRC Recipient shall generate and transmit a corresponding get attributes response command
frame, containing the requested attributes, back to the ZRC Originator.
If no get attributes command frame that contains the aplActionCodesSupportedRx attribute, is
received within aplcMaxConfigWaitTime, the ZRC Recipient shall consider the configuration
a failure and the ZRC configuration procedure shall be terminated.
The ZRC Recipient shall expect these get aplActionCodesSupportedRx attribute operations to
be performed in increasing index order. The ZRC Recipient may consider the configuration a
failure and terminate the ZRC configuration if the order is violated.
The aplActionCodesSupportedRx attributes of the ZRC Recipient for the HA Action Banks are not
exchanged during the configuration phase.
654
655
6. 4. 1 .5 E xc h an g e o f a ct io n c o d e s su ppo rt ed f or t r an sm it f ro m Z RC
656
657
658
659
660
661
662
663
664
665
666
shall be skipped.
Until the ZRC Recipient has received the aplActionCodesSupportedTx attributes of the ZRC Originator
for each action bank that is indicated to be supported by both the aplActionBanskSupportedRx attribute
of the ZRC Recipient, and the aplActionBanksSupportedTx attribute of the ZRC Originator (ANDoperation on both attributes), the ZRC Recipient shall request that the NWK layer enables its receiver
and waits either for a maximum duration of aplcMaxConfigWaitTime or until a push attributes
command frame that contains at least one aplActionCodesSupportedTx attribute, is received from the
ZRC Originator.
667
668
669
670
671
672
673
674
675
If such a frame is received within aplcMaxConfigWaitTime the ZRC Recipient shall attempt to
process it. The ZRC Recipient shall generate and transmit a corresponding generic response
The ZRC Recipient shall expect these push aplActionCodesSupportedTx attribute operations
to be performed in increasing index order. The ZRC Recipient may consider the configuration
a failure and terminate the ZRC configuration if the order is violated.
676
6. 4. 1 .6 Co mp l et in g t h e c o n f i g u r at io n p h as e f o r t h is p ro f i l e
677
678
679
680
681
682
683
684
685
Finally, the ZRC Recipient shall wait until a configuration complete command frame is received. If a
configuration complete command frame is received, the ZRC Recipient shall generate and transmit a
generic response command frame, containing the appropriate response code. The response code shall
indicate Configuration Failure if the ZRC Recipient wants to abort the ongoing binding procedure
with the ZRC Originator based on attribute values that were retrieved during this configuration phase.
In the other case in which the ZRC Recipient wants to continue with the ongoing binding procedure
with the ZRC Originator, the response code field shall indicate Success.
If no such frame is received within aplcMaxConfigWaitTime, the ZRC Recipient shall consider the
configuration a failure and the ZRC configuration procedure shall be terminated.
Page 28
686
6. 4. 2 Z RC O rig in at o r S id e Co n f ig u r at io n P ro ce d u r e
687
688
6. 4. 2 .1 E xc h an g e o f v e r sion and c ap ab il it y i nf o rm at i on f ro m Z R C
689
690
691
692
693
694
695
696
First, the ZRC Originator shall inform the ZRC Recipient about the profile version it implements,the
profile capabilities it supports, and the action banks version it implements.
To do this, the ZRC Originator shall generate and transmit a single push attributes command frame,
containing the aplZRCProfileVersion attribute, the aplZRCProfileCapabilities attribute and
aplZRCActionBanksVersion to the ZRC Recipient.
If the generic response command frame is not received from the ZRC Recipient or if the response code
of the generic response command frame is not indicating success, the ZRC originator shall consider the
configuration a failure and the ZRC configuration procedure shall be terminated.
697
698
6. 4. 2 .2 E xc h an g e o f v e r sion and c ap ab il it y i nf o rm at i on f ro m Z R C
Re ci p i en t t o Z R C O r i gin at o r
699
700
701
702
703
704
705
706
707
Next, the ZRC Originator shall interrogate the ZRC Recipient to determine the profile version the ZRC
Recipient implements, the profile capabilities the ZRC Recipient supports and the action bank version
it implements.
To do this, the ZRC Originator shall generate and transmit a single get attribute command frame,
containing the aplZRCProfileVersion attribute, the aplZRCProfileCapabilities attribute and the
aplZRCActinBanksVersion.
If no get attributes response command frame is received from the ZRC Recipient or if the attribute
status field of the get attributes response command frame is not indicating success, the ZRC Originator
shall consider the configuration a failure and the ZRC configuration procedure shall be terminated.
708
6. 4. 2 .3 M u t u al E xc h an g e of s u p p o rt ed a ct io n b an k s
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
aplZRCProfileCapabilites), or if the ZRC Originator indicates that it wants to be informed about
the actions the ZRC Recipient supports receiving (by having the informAboutSupportedActions
bit set to 1 in the aplZRCProfileCapabilites), the procedure described in this section shall be
executed. Otherwise it shall be skipped.
Next, the ZRC Originator shall interrogate the ZRC Recipient about the action banks it supports
receiving.
To do this, the ZRC Originator shall generate and transmit a get attributes command frame, containing
the aplActionBanksSupportedRx attribute, to the ZRC Recipient.
If no get attributes response command frame is received from the ZRC Recipient or if the attribute
Next, the ZRC Originator shall inform the ZRC Recipient about the action banks it supports
transmitting.
To do this, the ZRC Originator shall first generate and transmit a push attributes command frame,
containing the aplActionBanksSupportedTx attribute, to the ZRC Recipient.
of the generic response command frame is not indicating success, the ZRC Originator shall consider
the configuration a failure and the ZRC configuration procedure shall be terminated.
729
730
6. 4. 2 .4 E xc h an g e o f a ct io n c o d e s su p p o rt ed f o r r ec e iv e f ro m ZR C
Re ci p i en t t o Z R C O r i g in at o r
731
732
733
734
If the ZRC Originator indicates that it wants to be informed about the actions the ZRC Recipient
supports receiving (by having the informAboutSupportedActions bit set to 1 in the
shall be skipped.
Page 29
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
The ZRC Originator shall generate and transmit get attributes command frames to the ZRC Recipient
to retrieve the aplActionCodesSupportedRx attributes for each non-HA action bank that is indicated to
be supported by both the aplActionBanskSupportedRx attribute of the ZRC Recipient, and the
aplActionBanksSupportedTx attribute of the ZRC Originator (AND-operation on both attributes, and
blanking out the HA action banks). These get attributes command frames, containing the
aplActionCodesSupportedRx attributes, shall be indexed by the corresponding action bank. These get
aplActionCodesSupportedRx attribute operations shall be performed in increasing index order. Two
aplActionCodesSupportedRx attributes shall be retrieved in a single get attribute command frame
unless only one more aplActionCodesSupportedRx attribute needs to be retrieved, in which case the
remaining aplActionCodesSupportedRx attribute shall be retrieved in one more get attributes command
frame.
If the get attributes response command frame is not received from the ZRC Recipient or if the attribute
The aplActionCodesSupportedRx attributes of the ZRC Recipient for the HA Action Banks are not
exchanged during the configuration phase.
The ZRC Originator shall assume that all existing HA actions of the HA Actions Banks are
supported by the ZRC Recipient, if the supportHAActionsRecipient bit is set in the
aplZRCProfileCapabilities of the ZRC Recipient.
The ZRC Originator shall assume that none of the HA actions of the HA Action Banks are
supported by the ZRC Recipient, if the supportHAActionsRecipient bit is not set in the
aplZRCProfileCapabilities of the ZRC Recipient.
757
758
6. 4. 2 .5 E xc h an g e o f a ct io n c o d e s su ppo rt ed f or t r an sm it f ro m Z RC
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
shall be skipped.
The ZRC Originator shall generate and transmit push attributes command frames to the ZRC Recipient
to exchange the aplActionCodesSupportedTx attribute for each action bank that is indicated to be
supported by both the aplActionBanskSupportedRx attribute of the ZRC Recipient, and the
aplActionBanksSupportedTx attribute of the ZRC Originator (AND-operation on both attributes). These
push attributes command frames, containing the aplActionCodesSupportedTx attributes, shall be
indexed by the corresponding action bank. These push aplActionCodesSupportedTx attribute operations
shall be performed in increasing index order. Two aplActionCodesSupportedTx attributes shall be
pushed in a single push attribute command frame unless only one more aplActionCodesSupportedTx
attribute needs to be pushed, in which case the remaining aplActionCodesSupportedTx attribute shall
be pushed in one more single push attributes command frame.
of the generic response command frame is not indicating success, the ZRC Originator shall consider
the configuration a failure and the ZRC configuration procedure shall be terminated.
776
6. 4. 2 .6 Co mp l et in g t h e c o n f i g u r at io n p h as e f o r t h is p ro f i l e
777
778
779
780
781
782
783
784
785
Finally, the ZRC Originator shall generate and transmit a configuration complete command frame to
the ZRC Recipient. The status field shall indicate Configuration Failure if the ZRC Originator wants
to abort the ongoing binding procedure with the ZRC Recipient based on attribute values that were
retrieved during this configuration phase. In the other case in which the ZRC Originator wants to
continue with the ongoing binding procedure with the ZRC Recipient, the status field shall indicate
Success. The ZRC Originator shall then request that the NWK layer enable its receiver and wait
either for a maximum duration of aplcMaxResponseWaitTime or until a generic response command
frame is received from the recipient. If a generic response command frame is not received within
aplcMaxResponseWaitTime, the ZRC Originator shall terminate the ZRC configuration operation.
Page 30
786
6. 4. 3 Af t e r B in d ing
787
6. 4. 3 .1 Ac t io n m ap p in g n ego t iat ion p ro ce du re
788
789
790
791
792
793
794
795
If from the two nodes that have bound, one node supports action mapping in the client role (indicated
by having the supportActionMappingClient bit set in the aplZRCProfileCapabilities) and the other
supports action mapping in the server role (indicated by having the supportActionMappingServer bit
set in the aplZRCProfileCapabilities), the procedure described in this section shall be executed. This
procedure may be initiated by the Action Mapping Client at any desired moment. The procedure as
shown in Figure 23 is described in more detail for Action Mapping Server and Action Mapping Client
In the any other case, the procedure described in this section shall not be executed.
...
Binding Successful
Binding Successful
PushAttributes (aplMappableActions)
GenericResponse
PullAttributes (aplActionMappings, CommandA)
PullAttributesRsp(aplActionMappings, CommandA)
PullAttributes (aplActionMappings, CommandB)
...
PullAttributesRsp(aplActionMappings, CommandB)
[Action
mapping
Negotiation]
PullAttributes (aplActionMappings, CommandZ)

PullAttributesRsp(aplActionMappings, CommandZ)
796
797
798
Figure 23 Action mapping negotiation procedure
799
6. 4. 3 .1 .1 Ac t io n M ap p in g S e rv er
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
After the binding is successfully completed, the Action Mapping Server shall collect information from
the Action Mapping Client about which actions the Action Mapping Client supports mapping.
If the Action Mapping Server receives a push attributes command frame that contains the
aplMappableActions ZRC attribute from the Action Mapping Client, the Action Mapping Server shall
generate and transmit a corresponding generic response command frame, containing the appropriate
response code. If the Action Mapping Client has more aplMappableActions entries to push than can fit
into one frame, the Action Mapping Client may generate as many push attribute frames as is necessary
to push all aplMappableActions to the Action Mapping Server.
The Action Mapping Server shall use the information in the aplMappableActions to determine what
available actions it wants to remap and what actions it wants to remap them to. For each of the
available entries, the Action Mapping Server shall wait until the Action Mapping Client interrogates it
about the decision.
If the Action Mapping Server receives a pull attributes command frame from the Action Mapping
Client, containing the aplActionMappings ZRC attribute, the Action Mapping Server shall generate and
transmit a corresponding pull attributes response command frame, containing the requested attributes,
back to the Action Mapping Client.
The Action Mapping Server shall maintain the aplActionMappings attribute in non-volatile memory as
long as it intends the Action Mapping Client to maintain the mappings described in
aplMappableActions. This allows the Action Mapping Client to retrieve the mappings on a power cycle
if it does not have the resources to store them.
Page 31
820
821
822
823
The aplActionMappings may be pulled immediately after the aplMappableActions are pushed, but may
also be pulled later on, for example when the corresponding key down trigger is received. The
aplMappableActions entries may be pulled multiple times, for example when the permanent bit in the
previous aplMappableAction entry pull was not set.
824
6. 4. 3 .1 .2 Ac t io n M ap p in g Cl ie n t
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
After the binding is successfully completed, the Action Mapping Client shall inform the Action
Mapping Server about the actions it supports remapping for.
To do this, the Action Mapping Client shall first generate and transmit a push attributes command
frame containing the aplMappableActions ZRC attribute to the Action Mapping Server. If
aplMappableActions contains more actions maps than will fit in a single NWK data frame, then the
Action Mapping Client shall generate as many additional push attribute command frames necessary to
transmit all entities in aplMappableActions to the Action Mapping Server.
If the generic response command frame is not received from the Action Mapping Server or if the
response code of the generic response command frame is not indicating success for each push attributes
command frame, the Action Mapping Client shall consider the action mapping negotiation procedure a
failure and the procedure shall be terminated.
Next, the Action Mapping Client shall interrogate the Action Mapping Server about which actions it
wants to remap and what actions it wants to map to them.
To do this, the Action Mapping Client Originator shall generate and transmit a pull attributes command
frame, containing the aplActionMappings attribute, to the Action Mapping Server, for each of the
actions it supports remapping for.
If no pull attributes response command frame is received from the Action Mapping Server or if the
attribute status field of the pull attributes response command frame is not indicating success, the Action
Mapping Client shall consider the action mapping negotiation procedure a failure and the procedure
shall be terminated.
If the action mapping procedure fails, the Action Mapping Client should retry the action mapping
procedure negotiation later.
847
6. 4. 3 .2 IR DB V en d o r Su p p o rt An n o u n c em en t p ro c ed u r e
848
849
850
851
852
853
854
If the Action Mapping Client indicates that it supports vendor specific IRDB formats (by having the
supportVendorSpecificIRDBFormats bit set to 1 in the aplZRCProfileCapabilites), the procedure
described in this section shall be executed. This procedure shall be executed before the Action
Mapping Client initiates the Action mapping negotiation procedure, to ensure the Action Mapping
Server knows what IRDB Vendors the Action Mapping Client supports. The procedure as shown in
Figure 24, is described in more detail for Action Mapping Server and Action Mapping Client
855
[IRDB Vendor Support

Announce]
...
Binding Successfull
Binding Successfull
PushAttributes (aplIRDBVendorSupport)
GenericResponse
856
Figure 24 IRDB Vendor Support Announcement
857
858
6. 4. 3 .2 .1 Ac t io n M ap p in g S e rv er
859
860
861
862
After the binding is successfully completed, Action Mapping Server shall collect information from the
Action Mapping Client about the vendor specific IR database formats it supports.
If the Action Mapping Server receives a push attributes command frame that contains the
aplIRDBVendorSupport ZRC attribute, from the Action Mapping Client, the Action Mapping Server
Page 32
863
864
shall generate and transmit a corresponding generic response command frame, containing the
appropriate response code.
865
6. 4. 3 .2 .2 Ac t io n M ap p in g Cl ie n t
866
867
868
869
870
871
872
873
874
875
After the binding is successfully completed, the Action Mapping Client shall inform the Action
Mapping Server about the about the vendor specific IR database formats it supports.
To do this, the Action Mapping Client shall generate and transmit a push attributes command frame,
containing the aplIRDBVendorSupport GDP attribute, to the Action Mapping Server.
If the generic response command frame is not received from the Action Mapping Server or if the
response code of the generic response command frame is not indicating success, the Action Mapping
Client shall consider the IRDB vendor support announcement procedure a failure and the procedure
shall be terminated.
If the IRDB vendor support announcement procedure fails, the Action Mapping Client should retry the
IRDB Vendor Support Announcement procedure later.
876
6. 4. 3 .3 Ho m e Au t o m at io n Su p p o r t e d An n o u n c e me n t p ro ce du re
877
878
879
880
881
882
883
884
If from the two nodes that have bound, one node supports acting as a HA Actions Originator (indicated
by having the supportHAActionsOriginator bit set in the aplZRCProfileCapabilities) and the other
supports acting as a HA Actions Recipeint (indicated by having the supportHAActionsRecipient bit set
in the aplZRCProfileCapabilities), the procedure described in this section shall be executed. This
procedure may be initiated by the HA Actions Originator at any desired moment. It shall have been
executed successfully before the HA Action Originator pulls a aplHomeAutomation attribute. The
procedure as shown in Figure 25 is described in more detail for HA Actions Originator and HA Actions
Recipient separately in the sections below.
885
HA Actions Originator
...
Binding Successfull
Binding Successfull
PushAttributes (aplHomeAutomationSupported, Instance A)

GenericResponse
[Home Automation
Supported Announce]
...
PushAttributes (aplHomeAutomationSupported, Instance Z)
GenericResponse
886
887
Figure 25: Home Automation Supported Announcement procedure
888
6. 4. 3 .3 .1 H A Ac t i o n s R e ci pi en t
889
890
891
892
893
894
After the binding is successfully completed, HA Actions Recipient shall collect information from the
HA Actions Originator about the HA attributes it supports.
If the HA Actions Recipient receives a push attributes command frame that contains the
aplHomeAutomationSupported ZRC attribute, from the HA Actions Originator, the HA Actions
Recipient shall generate and transmit a corresponding generic response command frame, containing the
appropriate response code.
895
6. 4. 3 .3 .2 H A Ac t i o n s O ri g in at o r
896
897
After the binding is successfully completed, the HA Actions Originator shall inform the HA Actions
Recipient about the HA attributes it supports.
Page 33
898
899
900
901
902
903
904
905
906
To do this, the HA Actions Originator shall generate and transmit a push attributes command frame,
containing the aplHomeAutomationSupported ZRC attribute, to the HA Actions Recipient, for each of
the HA Instances it supports.
If the generic response command frame is not received from the HA Actions Recipient or if the
response code of the generic response command frame is not indicating success, the HA Actions
Originator shall consider the Home Automation Supported Announcement procedure a failure and the
procedure shall be terminated.
If the Home Automation Supported Announcement procedure fails, the HA Actions Originator should
retry the Home Automation Supported Announcement procedure later.
907
6.5
908
909
910
911
912
913
Action Mapping allows an Action Mapping Client to advertise triggers that can mapped to different
Actions defined by the Action Mapping Server. The Action Mapping Client advertises the triggers that
can be mapped in the aplMappableActions attribute and the Action Mapping Server informs the Action
Mapping Client which of these triggers it wants to remap in the aplActionMappings attribute. When
the Action Mapping Client has received a mapping for a trigger it has advertised, it shall use
aplActionMappings when the corresponding trigger occurs.
914
915
916
917
918
The action mapping Client may push a full or partial list of its mappable actions at any time. The action
Mapping Server shall update its list of existing mappable actions for this Client accordingly. If the
action mapping Client wants to invalidate one of the existing mappable actions on the Server, it can do
so by pushing the entry with the corresponding index and setting the action device type for this entry to
0xff..
919
6. 5. 1 Ac t io n M ap p in g Up d a t e
920
921
922
923
924
925
926
927
The Action Mapping Server can cause the Action Mapping client to update the aplMappableActions
attribute at any moment in time, by sending a Client Notification command frame with either the
Request Action Mapping Negotiation sub type for a full update (see 6.6.1) or Request Selective
Action Mapping Update (see 6.6.3) for a partial update.
On receipt of the Client Notification command frame with Request Action Mapping Negotiation sub
type or Request Selective Action Mapping Update, the Notification Client shall check if it is an
Action Mapping Client. If it is not an Action Mapping Client, it shall discard the frame without further
processing. If it is an Action Mapping Client
928
929
930
931
932
933
934
935
936
937
Action Mapping Pr ocedure
6.6
For a Client Notification with Request Action Mapping Negotiation sub type, the Action
Mapping Client shall update its action mapping entries for all of its indices by invoking the
Action mapping negotiation procedure, as described in 6.4.3.1.
For a Client Notification with Request Selective Action Mapping Update sub type, the
Action Mapping Client shall update its action mapping entries for at least the corresponding
indices before the next trigger corresponding to those indices occurs.
Notification Pr ocedure
The ZRC profile defines ZRC specific Client Notification sub types to the Notification feature
described in [R4] .
Page 34
Table 12 - Client Notification sub-type
938
Client Notification sub-type

Client Notification payload
Value
0x00 0x3f
Description
Reserved for GDP Client Notification
Sub Types.
(See [R4] )
Variable.
0x40
RequestActionMappingNegotiation
No Payload
0x41
RequestHomeAutomationPull
HA Instance ID
(1 octet)
0x42
RequestSelectiveActionMappingUpdate
Indices for Action Mapping Client

to inform Action Mapping Server
about.
0x43 0x7f
Reserved for profile-specific (nonGDP) Client Notification Sub Types.
Variable.
0x80 - 0xbf
Reserved
Reserved
0xc0 0xff
Reserved for vendor specific Client

Notification Sub Types. The contents of
this field shall be interpreted according
to the vendor id of the Recipient.
Variable.
HA Attribute
Dirty Flags
(32 octets)
939
6. 6. 1 Req u e st Ac t i o n M ap p in g N eg o t iat io n Su b T yp e
940
941
The Client Notification command frame with Request Action Mapping Negotiation has no Client
Notification payload.
942
6. 6. 2 Req u e st Ho m e Au t o m at i on Pu ll Sub T yp e
943
944
945
946
947
948
949
950
The Client Notification command frame with Request Home Automation pull has a Client Notification
payload that contains two fields.
The first field is one octet in length, and contains the HA Instance ID for which the
aplHomeAutomation attribute pull is requested.
The second field is 32 octets in length, and contains the HA Attribute Dirty Flags. This is a bitmap that
indicates for what HA Attributes of the specified HA Instance a pull is requested. The least significant
bit of this field corresponds to the HA attribute with ID 0x00 and the most significant bit of this field
corresponds to the HA attribute with ID 0xff, as illustrated in Figure 26.
951
952
953
Figure 26 - Format of the Dirty Flags field of the Request Home Automation Pull Sub
Type Payload
954
955
956
The HA attributes are enumerated using the HA attribute ID described in [R5] section 5.
For each bit, if the corresponding HA attribute of the specified HA Instance is requested to be pulled,
the bit shall be set to one. Otherwise, the bit shall be set to zero.
957
6. 6. 3 Req u e st Se le ct iv e Ac t io n M ap p in g U p d at e Su b T yp e
958
959
The Client Notification command frame with Request Selective Action Mapping Update has the
payload shown in Figure 27:
Page 35
960
Bits: 8
16
16
MappableActionIndexListLength
aplMappableAction
Index 0
aplMappableAction Index
MappableActionIndexListLength - 1
961
Figure 27 - Request Selective Action Mapping Update Sub Type
962
963
The MappableActionIndexListLength shall contain the number of indices that follow in the remaining
fields.
964
965
The remaining fields shall contain the aplMappableAction indices the Action Mapping Server wants
the Action Mapping Client to perform the selective action mapping update on.
966
Page 36
967
968
969
970
971
972
973
7.1
Annex A: Use of HA Commands and Attributes

Introduction
The HA actions and attributes allow the HA Actions Originator to acts like a wireless I/O panel, over
the RF4CE link, for an HA Actions Recipient device that is part of a ZigBee Pro-based Home
Automation network. The combination of HA Actions Originator and HA Actions Recipient can be
considered a single entity from a ZigBee Pro-based Home Automation network perspective.
HA Actions
Originator
RF4CE link
HA Actions
Recipient
ZPRO
ZPRO
ZPRO
ZPRO
ZPRO
ZPRO
HA network
974
975
976
Figure 28 The HA Actions Recipient is combined with a ZigBee Pro node in a single
physical device.
977
978
979
980
981
982
983
From a ZigBee Pro-based Home Automation network perspective the HA Actions Originator, HA
Actions Recipient and corresponding ZigBee Pro node can be considered as a single entity, while the
HA Actions Recipient and the ZigBee Pro node are one physical device, and the HA Actions
Originator is another physical device.
If the HA Actions Recipient is part of a ZigBee Pro-based Home Automation network, the HA actions
are used to allow the HA Actions Originator to control devices on this network. The HA attributes can
be used to get feedback on the status of the devices on this network back to the HA Actions Originator.
ZRC
Actions
Originator
HA Attrib.
Control
HA Actions
ZRC
Actions
Recipient
Feedback
Pull Attribute (HA attribute)
Pull Attribute Response (HA attribute)
Client Notification
(Request Home Automation Pull sub type)
984
Figure 29 HA Actions and HA attributes
985
986
The text below refers to the ZigBee Pro-based Home Automation network as HA network.
987
988
989
990
7.2
Configuration
If from the two nodes that have bound, one node can act as an HA Actions Originator (indicated by
having the supportHAActionsOriginator bit set in the aplZRCProfileCapabilities) and the other can act
as an HA Actions Recipient (indicated by having the supportHAActionsRecipient bit set in the
Page 37
991
992
993
994
995
996
997
998
999
1000
1001
aplZRCProfileCapabilities), the HA Actions Originator can send HA Actions to the HA Actions

Server, and the HA Actions Originator can pull HA attributes from the HA Server.
An HA Actions Recipient shall support all the HA action banks and all the HA actions in these HA
action banks, as well as all the HA attributes as described in [R5] . I.e. if a node has the
supportHAActionsRecipient bit set in the aplZRCProfileCapabilities, it shall also indicate that all HA
actions banks are supported in the aplActionBanksSupportedRx attribute, and it shall indicate that all
existing actions are supported in the aplActionsSupportedRx attributes corresponding to these HA
action banks.
An HA Actions Originator shall at least support one of the HA actions. The HA Actions Originator
shall indicate the exact set of HA action banks and HA actions in the aplActionBanksSupportedTx and
aplActionCodesSupportedTx attributes.
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
7.3
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
7.4
1028
1029
1030
1031
1032
7.5
H A Instances
The HA action bank is duplicated 32 times (Action Bank 0x80-0x9f). Each instance of the HA action
bank should be thought of controlling a single device on the HA network. The HA Actions Recipient
shall make sure that it allows each instance of the HA command bank to be bound to different devices
on the HA network. Since there are 32 instances of the HA command bank, each HA Actions
Originator can control up to 32 devices on the HA network (abstracting groups and scenes).
This allows for one HA Actions Originator to have multiple identical buttons. For example, an HA
Actions Originator with more than one toggle button can use different instances of the HA command
bank to control the different devices on the HA network, each button being tied to one instance of the
HA command bank.
The HA attributes are also instantiated 32 times. This is done using the index mechanism of the
attribute exchange (arrayed attributes).
The combination of an instance of the HA action bank that controls a device on the HA network, and
an instance of the HA attribute set that allows to monitor this device is called an HA Instance. They
share the same Instance ID.
H A Actions
HA Actions banks are used like the other action banks. Actions command frames are sent from the HA
Actions Originator to the HA Actions Recipient, indicating one of the HA action banks and one of the
non-reserved HA action codes in their Action records.
The HA Actions Recipient translates the HA action codes into commands of the equivalent ZCL/ZHA
clusters (see section 1) and uses the bindings that were set up on the HA Actions Recipient via its
GUI, or any other means, to control the desired device on the HA network.
If the ZCL/ZHA commands feature a ZCL/ZHA response command, the HA Actions Originator should
pull the associated ZRC HA attribute to be informed about the content of the ZCL/ZHA response
command. For example, after the HA Action Originator has sent a Lock Door Action, the HA Action
Originator should pull the Lock Door Response Attribute to be informed about the result.
H A Attributes
The HA Attribute are used like the other attributes. The HA Actions Originator can pull the value for
its HA attribute when it wants to be informed about the state of the devices on the HA network.
To ensure that the values of the HA attribute that the HA Actions Recipient puts in the pull response
commands are up to date, the following strategy shall be used.
1033
1034
1035
1036
If the HA Actions Recipient is not sure it has an up to date value for the HA attribute entry
that is requested by the HA Actions Originator via a pull request, it shall set the Value
Available bit in the HA Attribute Status of the HA attribute in the pull response to 0. At that
moment, it shall also immediately try to get an up to date value for this attribute.
1037
1038
1039
If the HA Actions Originator receives a pull response with the Value Available bit in the HA
Attribute Status set to 0, it shall ignore the content of the HA Attribute Value field. The HA
Actions Originator should issue another pull request in the near future.
1040
1041
1042
Furthermore, if the HA Actions Recipient is informed about a state change of the devices on the HA
network, it can trigger the HA Actions Originator to update the aplHomeAutomation attribute, by
sending a Client Notification command frame with Request Home Automation Pull sub type (see
Page 38
1043
1044
1045
1046
1047
1048
1049
6.6.2). It shall indicate in the payload what Instances and what HA Attributes have been changed. On
receipt of the Client Notification command frame with Request Home Automation Pull sub type, the
HA Action Recipient shall pull the aplHomeAutomation attribute for the instance, specified in the
Instance filed of the payload, and for the (supported) attributes, specified in HA Attribute Dirty Flags
field of the payload. A node that is not an HA Action Originator that receives a Client Notification
command frame with Request Home Automation Pull sub type, may discard the frame without
further processing.
1050
7.6
1051
1052
1053
1054
1055
1056
7. 6. 1 S ce n e s
The HA command banks contains some commands that can be mapped to the ZCL Scenes cluster. The
numbering of the scenes on the HA Actions Originator is a local numbering and has to be mapped to
the numbering on the HA network. Indeed, when multiple HA Actions Originators are bound to the
same HA Actions Recipient, the scenes the different HA Actions Originators are referring to might be
different, or might at least be numbered differently.
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
7. 6. 2 G en e ri c Ac t io n s
Generic actions do not have an equivalent ZCL/ZHA command.
With the generic actions, the HA Actions Originator can use a single HA instance to control different
devices on the HA network. In this case, the HA Actions Recipient may maintain a list of
devices/groups that can be controlled by the HA Actions Originator. How this list is populated by the
HA Actions Recipient is out of the scope of this specification and can be implementation specific. It is
the HA Actions Recipient that decides which HA device from this list should be controlled at any given
moment, based on the Generic actions received so far.
When the Previous Destination/Group is received, the HA Actions Recipient will change the HA
device/group that will be controlled to the previous device/group in the list.
When the Next Destination/Group is received, the HA Actions Recipient will change the HA
device/group that will be controlled to the next device/group in the list.
1069
1070
1071
1072
1073
1074
1075
7.7
1076
7. 7. 1 As s u mp t i o n s
1077
The assumption is that:
1078
1079
1080
Action and Attribute specific remarks
Example: Use Case Without Feedback
This example describes a remote control (RC) that has two pairs of on/off buttons. For the first on/off
button pair, HA Instance ID 0 is used. For the second on/off button pair, HA Instance ID 1 is used. In
this way, each pair can control a different device on the HA network.
It binds with a set top box (STB) allowing it to controls two on/off outputs on the HA network.
The RC does not support feedback about the status of the on/off outputs (e.g. no LEDs that reflect the
current status of the on/off outputs).
the RC is a ZRC Originator, implemented as an RF4CE controller,

the RC does not support polling
the STB is a ZRC Recipient, implemented as a RF4CE Target.
1081
7. 7. 2 Bind in g
1082
1083
1084
1085
1086
1087
1088
1089
The RC (binding originator) binds with the STB (binding recipient).

During the GDP configuration phase, the RC sets the supportPollClient bit to 0, since no feedback is
supported (and the RC has no other functionality that requires this feature).
During the ZRC configuration phase, the RC sets the supportActionsOriginator bit and the
supportHAActionsOriginator bit in the aplZRCProfileCapabilities to 1, to advertise itself as an HA
Actions Originator.
During the ZRC configuration phase, the STB sets the supportActionsRecipient bit, the
supportHAActionsRecipient bit and the informAboutSupportedActions bit in the
Page 39
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
aplZRCProfileCapabilities to 1, to advertise itself as an HA Actions Recipient and ensure it is

informed about the HA Actions the RC supports.
As a result, during the ZRC configuration, the RC informs the STB about the actions it supports via the
procedure described in 6.4.2.3. Next to the HDMI and HID banks the RC might support, the RC
indicates to support the HA Action Bank with HA Instance ID 0 (Action Bank 0x80) and the HA
Action Bank with HA Instance ID 1 (Action Bank 0x81) in the aplActionBanksSupported attribute. In
aplActionCodesSupported for Action Bank 0x80, the bits 0x20 and 0x21 are set, to indicate that the RC
supports a set of Off and an On commands, matching the first on/off button pair. Also in
aplActionCodesSupported for Action Bank 0x81, the bits 0x20 and 0x21 are set, to indicate that the RC
supports another set of Off and On commands, matching the second on/off button pair.
1100
7. 7. 3 Af t e r T h e Bi n d i n g
1101
1102
1103
After the binding, the Home Automation Supported Announcement procedure is executed (see section
6.4.3.3). Since the RC does not support feedback, all bits are zero in the aplHomeAutomationSupported
attribute.
1104
7. 7. 4 But t o n P re s s
1105
1106
1107
1108
1109
When the user presses one of the On or Off buttons, an Action command is sent. This action command
frame has a single action record. The Action Control indicates Atomic in the Action Type. In the
case of the On button of the second On/Off pair was pressed; the Action Data indicates HA Action
Bank with HA Instance ID 1 (Action Bank 0x81) as Action Bank, and On (Action Code 0x21) as
Action Code. The Action Data contains no Action Payload.
1110
1111
1112
1113
1114
1115
1116
7.8
1117
7. 8. 1 As s u mp t i o n s
1118
The assumption is that:
1119
1120
1121
Example: Use Case With Feedback
This example describes a remote control (RC) that has a pair of up/down buttons to control a
characteristic of a device that can be set to a level, for example the brightness of a light. For this
up/down button pair, HA Instance ID 0 is used.
The RC binds with a set top box (STB) allowing it to controls a level output on the HA network.
The RC supports feedback about the status of the level output (e.g. some LEDs that reflect the current
status of the level).
the RC is a ZRC Originator, implemented as an RF4CE controller,

the RC supports polling
the STB is a ZRC Recipient, implemented as a RF4CE Target.
1122
7. 8. 2 Bind in g
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
The RC (binding originator) binds with the STB (binding recipient).

During the GDP configuration phase, the RC sets the supportPollClient bit to 1, since feedback is
supported.
During the ZRC configuration phase, the RC sets the supportActionsOriginator bit and the
supportHAActionsOriginator bit in the aplZRCProfileCapabilities to 1, to advertise itself as an HA
Actions Originator.
During the ZRC configuration phase, the STB sets the supportActionsRecipient bit, the
supportHAActionsRecipient bit and the informAboutSupportedActions bit in the
aplZRCProfileCapabilities to 1 to advertise itself as an HA Actions Recipient, and ensure it is
informed about the HA Actions the RC supports.
As a result, during the ZRC configuration, the RC informs the STB about the actions it supports via the
procedure described in 6.4.2.3. Next to the HDMI and HID banks the RC might support, the RC
indicates to support the HA Action Bank with HA Instance ID 0 (Action Bank 0x80) in the
aplActionBanksSupported attribute. In aplActionCodesSupported for Action Bank 0x80, the bit 0x31 is
set, to indicate that the RC supports the Move command, matching the up/down button pair.
Page 40
1138
7. 8. 3 Af t e r T h e Bi n d i n g
1139
1140
1141
1142
After the binding, the Home Automation Supported Announcement procedure (see section 6.4.3.3) is
executed. Bit 0x30 is set in the aplHomeAutomationSupported attribute of HA Instance 0, to indicate
that the RC supports the Current Level attribute, that the RC will show to the user (e.g. via some
LEDs). After the binding, the Poll Negotiation procedure (see section 7.2.9.2 in [R4] ) is executed
1143
7. 8. 4 Bu t t o n P re s s
1144
1145
1146
1147
1148
1149
1150
1151
1152
When the user presses the Up or Down button, an Action command is sent.
This action command frame has a single action record. The Action Control indicates Atomic in the
Action Type. The Action Data indicates HA Action Bank with HA Instance ID 0 (Action Bank
0x800) as Action Bank, and Move (Action Code 0x31) as Action Code.
The Action Data contains an Action Payload, being the payload of the Move Command, as shown in
Section 5.2.1.1 of [R5] . In case the Up button was pressed, the Move Mode is Up. In case the Down
button was pressed, the Move Mode is Down. The rate field is 0xFF.
After the Action command is sent, the RC might start pulling the STB for an up to date value of the
Current Level of the HA attributes of HA Instance 0 (aplHomeAutomation[0,0x30]).
1153
7. 8. 5 E xt e rn a l St at u s Up d a t e
1154
1155
1156
1157
1158
1159
1160
1161
The RC polls the STB as configured during the Poll Negotiation procedure. When the level of the
device the RC is controlling is updated by another device than the RC and the STB is informed about
this event, the STB will send a Client Notification command frame with Request Home Automation
Pull sub type, the next time the STB is polled by the RC. This Client Notification command payload
(6.6.2) contains HA Instance ID 0, and has bit 0x30 of the HA Attribute Dirty Flags set to 1 to request
a pull of Current Level. After receiving the Client Notification attribute, the RC pulls the Current Level
of the HA attributes of HA Instance 0 (aplHomeAutomation[0,0x30]).
Page 41
1162
Annex B: Standard IR Database format
1163
1164
Figure 30 describes the format of the IR Code of section 5.2.10.3) in case the standard (non-vendor
specific) IR database format is used.
1165
Amount of
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Octets
1
Description:
Control Flags (2 octets)
1
1
Number of symbol timing definitions (n)
Number of symbols in pressed frame (x)
Number of symbols in repeat frame (y)
Number of symbols in release frame (z)
Number of symbols in toggle sequences (t)
Number of toggle sequences in toggle definition (s)
Carrier Period
Mark Timing Symbol 0
Space Timing Symbol 0
Mark Timing Symbol 1
Space Timing Symbol 1
Mark Timing Symbol n-1
Space Timing Symbol n-1
PF Symbol 0
PF Symbol 1
PF Symbol x-2
PF Symbol x-1
RF Symbol 0
RF Symbol 1
RF Symbol y-2
RF Symbol y-1
LF Symbol 0
LF Symbol 1
LF Symbol z-2
LF Symbol z-1
First Symbol to be toggled
Toggle Symbol 0, Seq 0
Toggle Symbol 1, Seq 0
Toggle Symbol t-2, Seq s-
Toggle Symbol t-1, Seq s-
Control Data
(8 octets)
Symbol Timing Definitions

[Each Symbol Timing Definition
consists of 2 octets Mark Definition
and 2 octets Space Definition. There
are at most 16 Symbol Timing
Definitions, as nibbles are used to
reference the symbols in the frame
definitions]
Press Frame Definition
Repeat Frame Definition
Release Frame Definition
Toggle Definition
Figure 30 IR Code Format
1166
1167
8.1
Control Flags
1168
The control flags field is 2 octets in length and contains a number of fields as described in Figure 31.
1169
Page 42
Octet:
Bit:
Description:
Repeat mode:
When set to 1, this indicates the Continuous repeat mode: the Repeat Frame is repeated as
long as the key is pressed;
When set to 0, this indicates the Non-Continuous repeat mode: the Repeat frame is
transmitted only once or the number of times as defined in the Number of Repeats field.
Use Carrier :
When set to 1, this indicates the Carrier mode;
When set to 0, this indicates the Non-Carrier mode
Mark Space Definition:

When set to 1, this indicates Single Marks and Single Spaces are used in the Symbol Timings
Definitions.
When set to 0, this indicates a Mark/Space Pair is used in the Symbol Timing Definitions.
3
4
5
Reserved
6
7
0
1
2
3
Number of Repeats (4 bits value):

For Continuous repeat mode, this is the minimum number of times the repeat frame has to be
transmitted.
For Non-Continuous repeat mode, this is the number of times the repeat frame has to be
transmitted regardless the amount of the time the key is pressed.
4
5
6
Reserved
7
Figure 31 Control Flags Format
1170
1171
1172
8.2
Control data
1173
8. 2. 1 Nu mb e r o f S ymb o l T imin g D ef in it io n s
1174
1175
1176
1177
1178
This field is 8 bits in length and specifies the number of symbol timing definitions in the Symbol
Timings Definitions field.
This field is also used to calculate the offset of the various symbols. As each timing value takes 4
octets, this value shall be multiplied by 4 to get the offset of the Pressed Frame Definition. The
maximum number of entries is 16.
1179
8. 2. 2 Nu mb e r o f S ymb o l s i n Pr e ss F r am e
1180
1181
1182
1183
1184
1185
1186
This field is 8 bits in length and specifies the number of symbols referenced in the Press Frame
Definition field.
Since each symbol is referenced with a nibble, the number of octets used in Press Frame Definitions is
half of this value. If an odd number of symbols are used, the last nibble is not used, so the number of
octets is rounded upwards (i.e. a padding nibble is added).
If, for the given IR protocol, the Press Frame is identical to the Repeat frame, the Press Frame Defiition
field shall be omitted, and the value of the Number of symbols in Press Frame field shall be 0.
The control data field is 8 octets in length and contains a number of fields as shown in Figure 30.
Page 43
1187
8. 2. 3 Nu mb e r o f S ymb o l s i n R ep e at F r am e
1188
1189
1190
1191
1192
This field is 8 bits in length and specifies the number of symbols referenced in the Repeat Frame
Definition field.
Since each symbol is referenced with a nibble, the number of octets used in the Repeat Frame
Definition field is half of this length. If an odd number of symbols are used, the last nibble is not used,
so the number of octets is rounded upwards (i.e. a padding nibble is added).
1193
8. 2. 4 Numb e r o f S ymb o l s i n R el e as e F ra me
1194
1195
1196
1197
1198
1199
1200
1201
This field is 8 bits in length and specifies the number of symbols referenced in the Release Frame
Definition field.
Since each symbol is referenced with a nibble, the number of octets used in Release Frame Definitions
is half of this value. If an odd number of symbols are used, the last nibble is not used, so the number of
octets is rounded upwards (i.e. a padding nibble is added).
If, for the given IR protocol, the Release Frame is identical to the Repeat frame, the Release Frame
Defiition field shall be omitted, and the value of the Number of symbols in Release Frame field shall be
0.
1202
8. 2. 5 Nu mb e r o f S ymb o l s i n T o g g l e S eq u en c e
1203
This field is 8 bits in length and specifies the number of Symbols in a single Toggle Sequence.
1204
8. 2. 6 Ca r ri e r P e rio d ( C P)
1205
1206
1207
1208
1209
This field is 16 bits in length and defines the number of 8 MHz pulses to be used in a single carrier
pulse according to the formula:
Carrier Period = 8 MHz / IR Carrier frequency.
For a 38 kHz carrier this shall be 8 * 10^-6 / 38 * 10^-3 = 210 pulses.
If the Carrier type is 0 (pulse mode), the Carrier Period value shall be ignored.
1210
1211
1212
1213
1214
1215
1216
1217
1218
8.3
1219
1220
1221
1222
1223
Symbol Timing Defi nitions
These fields define the length of the various timings used in the IR command.
For each of the n symbols, the timing of the symbols is defined by specifying the length of a Mark
period and the length of a Space period. This is done in 4 s units and little endian format.
If the Mark Space Definition field in the Control Flags is set to 0, each symbol is defined by the
concatenation of a mark and space period. If the Mark Space Definition field in the Control Flags is set
to 1, each symbol is defined by either a mark period, or a space period, so in this case, each Symbol
Timing Definition shall have either the Mark Timing, or the Space Timing set to 0.
During the mark period, the behavior depends on the Use Carrier field in the Control Flags.
If Use Carrier is set to 0, the IR signal is continuously on during the mark period.
If Use Carrier is set to 1, the IR signal is being modulated (turned on and off) according to
the carrier period (with a 30 % duty cycle).
During the space period, the IR signal is off.
Page 44
IR On
IR Off
Carrier Period
Mark
Space
Total Period
1224
Figure 32 Relation of various timing values
(with Mark Space Definition = 0, and Use Carrier = 1).
1225
1226
1227
8.4
Frame Definitions
1228
8. 4. 1 P re s s F r am e D ef i n it i on
1229
1230
1231
1232
1233
The Press Frame Definition contains the sequence of symbols for the press frame. The symbols are
referenced by a nibble. The nibble indicates what symbol from the Symbol Timing Definitions field
shall be used in each location in the sequence.
The press frame is transmitted as the first frame over the IR link. If the press frame is identical to the
repeat frame, no data is stored in the Press Frame Definition field and the length is zero.
1234
8. 4. 2 Rep e at F r a me D ef i n it io n :
1235
1236
1237
1238
1239
1240
1241
1242
1243
The Repeat Frame Definition contains the sequence of symbols for the repeat frame. The symbols are
If the Repeat Mode in the Control Flags is set to 1, the repeat frame shall be repeated as long as the
key is pressed, and at least the number of times indicated in the Number Of Repeats field of the Control
Flags.
If the Repeat Mode in the Control Flags is set to 0, the repeat frame shall be repeated exactly the
amount of times indicated in the Number Of Repeats field of the Control Flags, independent from the
fact if the key is kept pressed or not.
1244
8. 4. 3 Re le a se F r am e De f in i t io n :
1245
1246
1247
1248
1249
1250
The Release Frame Definition contains the sequence of symbols for the release frame. The symbols are
The release frame is transmitted as the last frame over the IR link when the key is released. If the
release frame is identical to the repeat frame, no data is stored in the Release Frame Definition field
and the length is zero.
1251
1252
1253
1254
1255
1256
8.5
Toggle Definition
Some IR sequences are using a toggle mechanism in the IR codes. When the same key is pressed
several times, different IR code frames are transmitted. The toggle mechanism modifies one or a few
consecutive symbol in the repeat frame sequence. Up to 4 different toggle sequences shall be
supported.
Table 13 shows the format of the Toggle Definition field.
Page 45
Table 13 Format of Toggle Definition field.
1257
Offset
Length
Name
Description
The position of the first symbol from the
Repeat Frame Definition to be modified.
1 octet
Start Position
Ceil(t/2)
octets
Toggle
Sequence 0
1+
ceil(t/2)
Ceil(t/2)
octets
Toggle
Sequence 1
The sequences of symbols that replaces the

Symbols of the Repeat Frame.
Ceil(t/2)
octets
Toggle
Sequence s-1
Each Toggle Symbol Sequence is padded

with zeroes to an octet boundary.
1+
(s-1) *
Ceil(t/2)
1258
1259
1260
Where:
t is the number of symbols in toggle sequence defined in the Control Data field; and
s is the number of toggle sequences in toggle definition defined in the Control Data field.
1261
8. 5. 1 E xa mp l e:
1262
1263
1264
1265
Given an IR code with 4 toggle sequences that differ in symbol 2, 3 and 4 of the Repeat Frame, the
Toggle Definition field is described in Table 14
Furthermore, in this case, the Control Data section contains following values:
1266
1267
1268
1269
Number of symbols in toggle sequences (t) is set to 3

Number of toggle sequences in toggle definition (s) is set to 3. Indeed, one of the toggle
sequences is defined in Repeat Frame Definition and the three alternatives are defined in the
Toggle Definition field.
Table 14 Toggle Definition field for the example given
1270
Offset
0
Bits: 7
0x02 = Start Position
Symbol Timing Definition Reference for

Symbol 2 of Repeat Frame - Alternative 1


0x0



0x0



0x0
1271
Page 46
Toggle
Definition
1272
1273
Annex C: Example of a configuration phase consisting of

GDP and ZRC configuration procedures
1274
1275
1276
Figure 33 shows an example of a configuration phase consisting of GDP and ZRC configuration
procedures in which neither side requests ZRC command discovery.
ZRC Recipient
ZRC Originator
Temporary Pairing
Done
Temporary Pairing
Done
aplcConfigBlackoutTime
Enter GDP
configuration state
Exchange
Version,
Capability
Information &
Validation
Settings
PushAttribute (aplGDPVersion, aplGDPCapabilities)
Enter GDP
configuration state
GenericResponse
GetAttributes (aplGDPVersion, aplGDPCapabilities)
GetAttributesRsp (aplGDPVersion, aplGDPCapabilities)
PullAttributes (aplAutoCheckValidationPeriod, aplLinkLostWaitTime)
PullAttributesRsp (aplAutoCheckValidationPeriod, aplLinkLostWaitTime)
GenericResponse
Enter ZRC
configuration state
Exchange
Version,
Capability
Information
PushAttribute (aplZRCProfileVersion, aplZRCProfileCapabilities,
Enter ZRC
configuration state
aplZRCActionBanksVersion
GenericResponse
GetAttributes (aplZRCProfileVersion, aplZRCProfileCapabilities,
GetAttributesRsp (aplZRCProfileVersion, aplZRCProfileCapabilities,
GenericResponse
Start of Validation
Start of Validation
1277
1278
1279
Figure 33 Example of configuration phase consisting of GDP and ZRC configuration

procedures
1280
Page 47

105546r02ZB Zigbee Rf4ce Sc-ZigBee Remote Control Application Profile Public

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

105546r02ZB Zigbee Rf4ce Sc-ZigBee Remote Control Application Profile Public

Încărcat de

Drepturi de autor:

Formate disponibile

ZigBee RF4CE: ZRC Profile

This document has been accepted for release by the ZigBee

This specification defines the protocol infrastructures and

ZigBee; RF4CE, application, ZRC, profile.

September 4th, 2014

Copyright 1996-2014 by the ZigBee Alliance.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

Notice of use and disclosure

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

Contributions were made to this document by the following members:

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

First approved release of ZigBee RF4CE: ZRC Profile

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

General ZRC command frame format ...................................................................................................... 4

Supported Features ................................................................................................................................... 5

ZRC command frames ............................................................................................................................. 7

ZRC profile constants and attributes ...................................................................................................... 10

Functional description ............................................................................................................................ 21

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

Annex A: Use of HA Commands and Attributes ...................................................................................37

Annex B: Standard IR Database format .................................................................................................42

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0

ZigBee Document 13-0442-23, September 4th, 2014

This page is intentionally blank

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee Document 13-0442-23, September 4th, 2014

ZigBee RF4CE: ZRC Profile Specification, v2.0

Copyright 2014, ZigBee Standards Organization. All rights reserved.

ZigBee RF4CE: ZRC Profile Specification, v2.0