Notice
of
Use
Copyright
Notice,
License
and
Disclosure
Disclaimer
Copyright
©
Connectivity
Standards
Alliance
(2021).
(2021-2023).
All
rights
reserved.
This
The
information
within
this
document
is
the
property
of
the
Connectivity
Standards
Alliance
and
its
use
and
disclosure
are
restricted.
restricted,
except
as
expressly
set
forth
herein.
Elements
Connectivity
Standards
Alliance
hereby
grants
you
a
fully-paid,
non-exclusive,
nontransferable,
worldwide,
limited
and
revocable
license
(without
the
right
to
sublicense),
under
Connectivity
Standards
Alliance’s
applicable
copyright
rights,
to
view,
download,
save,
reproduce
and
use
the
document
solely
for
your
own
internal
purposes
and
in
accordance
with
the
terms
of
the
license
set
forth
herein.
This
license
does
not
authorize
you
to,
and
you
expressly
warrant
that
you
shall
not:
(a)
permit
others
(outside
your
organization)
to
use
this
document;
(b)
post
or
publish
this
document;
(c)
modify,
adapt,
translate,
or
otherwise
change
this
document
in
any
manner
or
create
any
derivative
work
based
on
this
document;
(d)
remove
or
modify
any
notice
or
label
on
this
document,
including
this
Copyright
Notice,
License
and
Disclaimer.
The
Connectivity
Standards
Alliance
specifications
does
not
grant
you
any
license
hereunder
other
than
as
expressly
stated
herein.
Elements
of
this
document
may
be
subject
to
third
party
intellectual
property
rights,
including
without
limitation,
patent,
copyright
or
trademark
rights
(such
a
rights,
and
any
such
third
party
may
or
may
not
be
a
member
of
the
Connectivity
Standards
Alliance).
Alliance.
Connectivity
Standards
Alliance
members
grant
other
Connectivity
Standards
Alliance
members
certain
intellectual
property
rights
as
set
forth
in
the
Connectivity
Standards
Alliance
IPR
Policy.
Connectivity
Standards
Alliance
members
do
not
grant
you
any
rights
under
this
license.
The
Connectivity
Standards
Alliance
is
not
responsible
for,
and
shall
not
be
held
responsible
in
any
manner
for
for,
identifying
or
failing
to
identify
any
or
all
such
third
party
intellectual
property
rights.
Please
visit
www.csa-iot.org
for
more
information
on
how
to
become
a
member
of
the
Connectivity
Standards
Alliance.
This
document
and
the
information
contained
herein
are
provided
on
an
"AS
IS"
“AS
IS”
basis
and
the
Connectivity
Standards
Alliance
DISCLAIMS
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)
RIGHTS);
OR
(B)
ANY
IMPLIED
WARRANTIES
OF
MERCHANTABILITY,
FITNESS
FOR
A
PARTICULAR
PURPOSE,
TITLE
OR
NON-INFRINGEMENT.
NONINFRINGEMENT.
IN
NO
EVENT
WILL
THE
CONNECTIVITY
STANDARDS
ALLIANCE
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,
INCIDENTAL,
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 in this document may be trademarks that are the sole property of their respective owners.
This
legal
notice
and
disclaimer
must
be
included
on
all
copies
of
this
document
that
are
made.
document.
Connectivity
Standards
Alliance
508
Second
Street,
Suite
206
Davis,
CA
95616,
USA
Revision History
| Revision | Date | Details | Editor |
|---|---|---|---|
01 | September 23, 2022 | Version 1.0 | Robert Szewczyk |
01 | May 17, 2023 | Version 1.1 | Robert Szewczyk |
References
The following standards and specifications contain provisions, which through reference in this document constitute provisions of this specification. All the standards and specifications listed are normative references. At the time of publication, the editions indicated were valid. All standards and specifications are subject to revision, and parties to agreements based on this specification are encouraged to investigate the possibility of applying the most recent editions of the standards and specifications indicated below.
CSA Reference Documents
| Reference | Reference Location/URL | Description |
|---|---|---|
|
https://github.com/CHIP-Specifications/connectedhomeip-spec/raw/build-sample/pdf/main.pdf |
Matter Core Specification - Under development |
|
|
Organizational Processes and Procedures, 13-0625, revision 8, November 2021 |
Provisional
Per [CSA-PNP] , when a specification is completed there may be sections of specification text (or smaller pieces of a section) that are not certifiable at this stage. These sections (or smaller pieces of a section) are marked as provisional prior to publishing the specification. This specification uses well-defined notation to mark Provisional Conformance (see [MatterCore] , Section 7.3) or notes a section of text with the term "provisional".
List of Provisional Items
The following is a list of provisional items.
-
Support for Heating/Cooling Unit is provisional.
-
Support for Fan device type is provisional.
1. Base Device Type
This chapter describes the base device type .
1.1. Base Device Type
1.1.1. Revision History
This is the revision history for this document. Because this document defines common requirements for all device types, changes to this document may affect many device types. Therefore, each device type definition affected by a change here, SHALL have its revision number incremented, with a new entry added to its history with a description that matches the description here.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
1.1.2. Overview
This defines common conformance for all device types depending on, but not limited to:
-
Certification programs (e.g. Zigbee, Matter, etc.)
-
Underlying protocol stack (e.g. 802.15.4, Wi-Fi, Thread, Zigbee PRO, IPv6, TCP/IP)
-
Regional regulations
-
Interfaces (UI, cloud, etc.)
-
Scale (e.g. residential vs commercial)
-
Other common limitations or capabilities (e.g. battery powered or sleepy nodes).
-
etc.
1.1.3. Conditions
Each section below is a category of conditions, each defining a list of conformance condition names and unique tags. The separation into categories is for reading purposes only.
1.1.3.1. Certification Program Conditions
At the time of the first publication of this document, many certification programs have terminated, or only allow re-certification, such as the Zigbee Home Automation standard.
| Certification Program | Tag | Description |
|---|---|---|
|
Zigbee Home Automation |
ZHA |
Zigbee Home Automation standard |
|
Zigbee Smart Energy |
ZSE |
Zigbee Smart Energy standard |
|
Green Power |
GP |
Zigbee Green Power standard |
|
Zigbee |
Zigbee |
Zigbee standard |
|
SuZi |
SuZi |
Zigbee PRO Sub-GHz standard |
|
Matter |
Matter |
Matter standard |
1.1.3.3. Interface Conditions
| Interface Tag | Description |
|---|---|
|
LanguageLocale |
The node supports localization for conveying text to the user |
|
TimeLocale |
The node supports localization for conveying time to the user |
|
UnitLocale |
The node supports localization for conveying units of measure to the user |
Note that "supports localization" in the table above refers to supporting update of localization via cluster interactions.
1.1.4. Common Capability Conditions
This category is for common limitations or capabilities of a node.
| Capability Tag | Description |
|---|---|
|
Sleepy |
The node is normally asleep and wakes to perform function |
|
Awake |
The node is always able to communicate |
|
Simplex |
One way communication, client to server |
1.1.5. Device Type Class Conditions
This category is for classifications of device type. Some of these classifications are dependent on other conditions.
| Class Tag | Description |
|---|---|
|
Node |
the device type is classified as a Node device type (see Data Model specification) |
|
App |
the device type is classified as an Application device type (see Data Model specification) |
|
Simple |
the
device
type
is
classified
as
a
Simple
device
type
(see
Data
Model
|
|
Dynamic |
the device type is classified as a Dynamic device type (see Data Model specification) |
|
Client |
there exists a client application cluster on the endpoint |
|
Server |
there exists a server application cluster on the endpoint |
|
Composed |
the device type is composed of 2 or more device types (see System Model specification) |
|
Multiple |
a Composed device type that is composed of 2 or more endpoints with the same device type (see System Model specification) |
|
EZ-Initiator |
the endpoint is an Initiator for Zigbee EZ-Mode Finding & Binding |
|
EZ-Target |
the endpoint is a Target for Zigbee EZ-Mode Finding & Binding |
|
BridgedPowerSourceInfo |
the endpoint represents a Bridged Device, for which information about the state of its power source is available to the Bridge |
1.1.6. Base Cluster Requirements for Zigbee
Each device type definition SHALL include these clusters, as a minimum set, based on the conformance defined below. This conformance table SHALL assume the Zigbee conformance condition is TRUE (in Conformance column).
| Cluster Name | Client/Server | Quality | Conformance |
|---|---|---|---|
|
Basic |
Server |
I |
|
|
Identify |
Server |
Simple |
|
|
Identify |
Client |
EZ-Initiator |
1.1.7. Base Cluster Requirements for Matter
Each device type definition SHALL include these clusters, as a minimum set, based on the conformance defined below. This conformance table SHALL assume the Matter conformance condition is TRUE (in Conformance column).
| Cluster Name | Client/Server | Quality | Conformance |
|---|---|---|---|
|
Descriptor |
Server |
M |
|
|
Binding |
Server |
Simple & Client |
|
|
FixedLabel |
Server |
[App & Server & Multiple] |
|
|
UserLabel |
Server |
[App & Server & Multiple] |
2. Utility Device Types
This chapter describes the utility device types. The utility device types are summarized in the table below:
| Device ID | Device name |
|---|---|
|
0x0016 |
|
|
0x0011 |
|
|
0x0012 |
|
|
0x0014 |
|
|
0x000e |
|
|
0x0013 |
2.1. Root Node
This defines conformance for a root node endpoint (see System Model specification). This endpoint is akin to a "read me first" endpoint that describes itself and the other endpoints that make up the node.
Device types with Endpoint scope SHALL NOT be supported on the same endpoint as this device type.
Clusters with an Application role SHALL NOT be supported on the same endpoint as this device type.
Other device types with Node scope MAY be supported on the same endpoint as this device type.
2.1.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
2.1.4.
2.1.3.
Conditions
| Condition | Description |
|---|---|
|
CustomNetworkConfig |
The
node
only
supports
out-of-band-configured
networking
(e.g.
rich
user
interface,
manufacturer-specific
means,
custom
commissioning
flows,
or
future
IP-compliant
network
technology
not
yet
directly
supported
by
|
Please see the Base Device Type definition for additional conformance tags.
2.1.5.
2.1.4.
Cluster
Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0028 |
Basic Information |
Server |
I |
M |
|
0x001F |
Access Control |
Server |
I |
M |
|
0x002E |
Power Source Configuration |
Server |
I |
O |
|
0x0038 |
Time Synchronization |
Server |
I |
P, O |
|
0x003F |
Group Key Management |
Server |
I |
M |
|
0x0030 |
General Commissioning |
Server |
I |
M |
|
0x0031 |
Network Commissioning |
Server |
!CustomNetworkConfig |
|
|
0x003C |
Administrator Commissioning |
Server |
I |
M |
|
0x003E |
Node Operational Credentials |
Server |
I |
M |
|
0x002B |
Localization Configuration |
Server |
I |
LanguageLocale |
|
0x002C |
Time Format Localization |
Server |
I |
TimeLocale |
|
0x002D |
Unit Localization |
Server |
I |
UnitLocale |
|
0x0033 |
General Diagnostics |
Server |
I |
M |
|
0x0032 |
Diagnostic Logs |
Server |
I |
O |
|
0x0034 |
Software Diagnostics |
Server |
I |
O |
|
0x0037 |
Ethernet Network Diagnostics |
Server |
I |
[Ethernet] |
|
0x0036 |
Wi-Fi Network Diagnostics |
Server |
I |
[Wi-Fi] |
|
0x0035 |
Thread Network Diagnostics |
Server |
I |
[Thread] |
2.3. OTA Requestor
An OTA Requestor is a device that is capable of receiving an OTA software update.
2.4. OTA Provider
An OTA Provider is a node that is capable of providing an OTA software update to other nodes on the same fabric.
2.4.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
2.4.3. Cluster Requirements
Each node supporting this device type SHALL include these clusters based on the conformance defined below. A node SHALL only ever have, at most, one instance of the OTA Provider’s required clusters.
| ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|
|
OTA Software Update Requestor |
Client |
O |
|
|
OTA Software Update Provider |
Server |
M |
2.5. Aggregator
This
section
defines
conformance
device
type
aggregates
endpoints
as
a
collection.
Clusters
on
the
endpoint
indicating
this
device
type
provide
functionality
for
the
collection
of
descendent
endpoints
present
in
the
PartsList
of
the
endpoint’s
descriptor,
for
example
the
Actions
cluster.
The
purpose
of
this
device
type.
type
is
to
aggregate
functionality
for
a
collection
of
endpoints.
The
definition
of
the
collection
or
functionality
is
not
defined
here.
When using this device type as a collection of bridged nodes, please see the "Bridge" section in the System Model specification.
2.5.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
2.5.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x000E |
Aggregator |
Dynamic Utility |
Endpoint |
2.5.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|
|
Actions |
Server |
O |
2.5.5.
Overall
Requirements
Endpoint
Composition
For
additional
requirements
and
guidance
when
using
this
An
Aggregator
endpoint’s
Descriptor
cluster
PartsList
attribute
SHALL
list
the
collection
of
endpoints
aggregated
by
the
Aggregator
device
type,
please
see
type
using
the
"Bridge"
section
flat
pattern
defined
in
[System
Model].
the
"Endpoint
Composition"
section
of
the
System
Model
specification.
2.6. Bridged Node
This
defines
conformance
for
a
Bridged
Node
root
endpoint.
This
endpoint
is
akin
to
a
"read
me
first"
endpoint
that
describes
itself
and
any
other
endpoints
that
make
up
the
Bridged
Device.
Node.
A
bridged
node
root
Bridged
Node
endpoint
represents
a
device
on
a
foreign
network,
but
is
not
the
root
endpoint
of
the
bridge
node
itself.
2.6.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
2.6.3. Conditions
Please see the Base Device Type definition for conformance tags.
This device type SHALL only be used for Nodes which have a device type of Bridge.
2.6.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|
|
Bridged Device Basic Information |
Server |
I |
M |
|
Power Source Configuration |
Server |
I |
BridgedPowerSourceInfo |
|
Power Source |
Server |
BridgedPowerSourceInfo |
2.6.5. Endpoint Composition
A Bridged Node endpoint SHALL support one of the following composition patterns:
Separate Endpoints: All application device types are supported on separate endpoints, and not on the Bridged Node endpoint. The Bridged Node endpoint’s Descriptor cluster PartsList attribute SHALL indicate a flat list of all endpoints representing the functionality of the bridged node, including the endpoints supporting the application device types.
One Endpoint: Both the Bridged Node and one or more application device types are supported on the same endpoint (following application device type rules). Endpoint composition SHALL conform to the application device type(s) definition.
3. Application Device Types
The following chapters list the application device types defined in this version of the Device Library. They are grouped per functional area in a chapter and are summarized in the table below:
| Device ID | Device name |
|---|---|
|
lighting |
|
|
0x0100 |
|
|
0x0101 |
|
|
0x010C |
|
|
0x010D |
|
|
smart plugs/outlets and other actuators |
|
|
0x010A |
|
|
0x010B |
|
|
0x0303 |
|
|
switches and controls |
|
|
0x0103 |
|
|
0x0104 |
|
|
0x0105 |
|
|
0x0840 |
|
|
0x0304 |
|
|
0x000F |
|
|
sensors |
|
|
0x0015 |
|
|
0x0106 |
|
|
0x0107 |
|
|
0x0302 |
|
|
0x0305 |
|
|
0x0306 |
|
|
0x0307 |
|
|
0x0850 |
|
|
closures |
|
|
0x000A |
|
|
0x000B |
|
|
0x0202 |
|
|
0x0203 |
|
|
HVAC |
|
|
0x0300 |
|
|
0x0301 |
|
|
0x002B |
|
|
media |
|
|
0x0028 |
|
|
0x0023 |
|
|
0x0022 |
|
|
0x0024 |
|
|
0x0029 |
|
|
0x002A |
|
|
generic |
|
|
0x0027 |
|
4. Lighting Device Types
4.1. On/Off Light
The On/Off Light is a lighting device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. In addition, an on/off light is also capable of being switched by means of a bound occupancy sensor.
4.1.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
4.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
O |
|
|
0x0406 |
Occupancy Sensing |
Client |
O |
The inclusion of the Level Control cluster on this device is recommended to provide a consistent user experience when the device is grouped with additional dimmable lights and the “with on/off” commands are used. For this device, since its only states are on or off, if the Level Control cluster is implemented, it SHALL not have any effect on the actual light level except for those commands that cause an on/off state change, that is, the “with on/off” commands. In addition, if the Level Control cluster is implemented, the device SHALL accept and process Level Control cluster commands, adjusting the value of the CurrentLevel attribute accordingly and, where necessary, adjusting the On/Off cluster OnOff attribute.
4.1.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
As the TriggerEffect command of the Identify cluster and the OffWithEffect command of the On/Off cluster specify light effects that require dimming of the light output, and such is not possible on this device type, the specified light effects MAY be replaced by pure on/off light effects.
4.2. Dimmable Light
A Dimmable Light is a lighting device that is capable of being switched on or off and the intensity of its light adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dimmer Switch. In addition, a Dimmable Light device is also capable of being switched by means of a bound occupancy sensor or other device(s).
4.2.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
4.2.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0101 |
Dimmable Light |
On/Off Light |
Simple |
Endpoint |
4.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
M |
|
|
0x0406 |
Occupancy Sensing |
Client |
O |
4.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
4.3. Color Temperature Light
A Color Temperature Light is a lighting device that is capable of being switched on or off, the intensity of its light adjusted, and its color temperature adjusted by means of a bound controller device such as a Color Dimmer Switch.
4.3.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
4.3.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x010c |
Color Temperature Light |
Dimmable Light |
Simple |
Endpoint |
4.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
M |
|
|
0x0300 |
Color Control |
Server |
M |
4.3.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
||
|
0x0300 |
Color Control |
Feature |
CT |
M |
||
|
0x0300 |
Color Control |
Attribute |
RemainingTime |
M |
4.4. Extended Color Light
An Extended Color Light is a lighting device that is capable of being switched on or off, the intensity of its light adjusted, and its color adjusted by means of a bound controller device such as a Color Dimmer Switch or Control Bridge. The device supports adjustment of color by means of hue/saturation, enhanced hue, color looping, XY coordinates, and color temperature. In addition, the extended color light is also capable of being switched by means of a bound occupancy sensor.
4.4.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation; integrate DM CCB 3501 |
4.4.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x010d |
Extended Color Light |
Color Temperature Light |
Simple |
Endpoint |
4.4.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
M |
|
|
0x0300 |
Color Control |
Server |
M |
4.4.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0x0003 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
||
|
0x0300 |
Color Control |
Feature |
HS |
O |
||
|
0x0300 |
Color Control |
Feature |
EHUE |
O |
||
|
0x0300 |
Color Control |
Feature |
CL |
O |
||
|
0x0300 |
Color Control |
Feature |
XY |
M |
||
|
0x0300 |
Color Control |
Feature |
CT |
M |
||
|
0x0300 |
Color Control |
Attribute |
RemainingTime |
M |
5. Smart Plugs/Outlets and other Actuators
5.1. On/Off Plug-in Unit
An On/Off Plug-in Unit is a device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. The On/Off Plug-in Unit is typically used to control a conventional non-communicating light by switching its mains connection. Other appliances can be controlled this way as well.
5.1.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
5.1.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x010a |
On/Off Plug-in Unit |
Simple |
Endpoint |
5.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
O |
The inclusion of the Level Control cluster on this device is recommended to provide a consistent user experience when the device is grouped with additional dimmable lights and the “with on/off” commands are used. For this device, since its only states are on or off, if the Level Control cluster is implemented, it SHALL not have any effect on the actual light level except for those commands that cause an on/off state change, that is, the “with on/off” commands. In addition, if the Level Control cluster is implemented, the device SHALL accept and process Level Control cluster commands, adjusting the value of the CurrentLevel attribute accordingly and, where necessary, adjusting the On/Off cluster OnOff attribute.
5.1.4.1. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
As the TriggerEffect command of the Identify cluster and the OffWithEffect command of the On/Off cluster specify light effects that require dimming of the light output, and such is not possible on this device type, the specified light effects MAY be replaced by pure on/off light effects.
5.2. Dimmable Plug-In Unit
A Dimmable Plug-In Unit is a device that is capable of being switched on or off and have its level adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dimmer Switch. The Dimmable Plug-in Unit is typically used to control a conventional non-communicating light through its mains connection using phase cutting.
5.2.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
5.2.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x010b |
Dimmable Plug-In Unit |
Simple |
Endpoint |
5.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0008 |
Level Control |
Server |
M |
5.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0003 |
Identify |
Command |
TriggerEffect |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedAddScene |
M |
||
|
0x0005 |
Scenes |
Command |
EnhancedViewScene |
M |
||
|
0x0005 |
Scenes |
Command |
CopyScene |
M |
||
|
0x0006 |
On/Off |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Feature |
OO |
M |
||
|
0x0008 |
Level Control |
Feature |
LT |
M |
||
|
0x0008 |
Level Control |
Attribute |
CurrentLevel |
1 to 254 |
||
|
0x0008 |
Level Control |
Attribute |
MinLevel |
1 |
||
|
0x0008 |
Level Control |
Attribute |
MaxLevel |
254 |
5.3. Pump
A Pump device is a pump that may have variable speed. It may have optional built-in sensors and a regulation mechanism. It is typically used for pumping fluids like water.
5.3.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
5.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0200 |
Pump Configuration and Control |
Server |
M |
|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0008 |
Level |
Server |
O |
|
|
0x0005 |
Scenes |
Server |
O |
|
|
0x0004 |
Groups |
Server |
O |
|
|
0x0402 |
Temperature Measurement |
Server |
O |
|
|
0x0403 |
Pressure Measurement |
Server |
O |
|
|
0x0404 |
Flow Measurement |
Server |
O |
|
|
0x0402 |
Temperature Measurement |
Client |
O |
|
|
0x0403 |
Pressure Measurement |
Client |
O |
|
|
0x0404 |
Flow Measurement |
Client |
O |
|
|
0x0406 |
Occupancy Sensing |
Client |
O |
5.3.5. Cluster Restrictions
5.3.5.1. On/Off Cluster (Server) Clarifications
The actions carried out by a Pump device on receipt of commands are shown in the following.
| Command | Action on Receipt |
|---|---|
|
Off |
If the pump is powered on, store the current level then immediately power it off. |
|
On |
If the pump is powered off, power it on and move immediately to the level stored by a previous Off command. If no such level has been stored, move immediately to the maximum level allowed for the pump. |
|
Toggle |
If the pump is powered on, proceed as for the Off command. If the device is powered off, proceed as for the On command. |
5.3.5.2. Level Control Cluster (Server) Clarifications
The Level Control cluster SHALL allow controlling the pump setpoints. However, the transition time is always ignored.
The setpoint of the pump is a percentage related to the level according to the following table.
| Level | Setpoint | Meaning |
|---|---|---|
|
0 |
N/A |
Pump is stopped. |
|
1 – 200 |
Level / 2 (0.5 – 100.0%) |
Pump setpoint in percent. |
|
201 – 255 |
100.0% |
Pump setpoint is 100.0% |
5.3.6. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6. Switches and Controls Device Types
This Chapter specifies a number of "controller" device types like On/Off Light Switch and Dimmer Switch. Some products implementing these device types are intended to replace legacy switches or dimmers that directly control the power to a load. For such products, manufacturers are encouraged to implement an additional endpoint on the same product holding an "actuator" device type like an On/Off Light (or On/Off Plug-in Unit) or Dimmable Light (or Dimmable Plug-in Unit), consistent with the type of control it can provide to the load. In case product can control multiple loads separately, multiple such endpoints to each hold a device type for each load.
Additionally, having a central control function allows much richer automation triggered by a press of a switch. In such case, a switch works more like a sensor. For this, the Generic Switch device type is defined. See Section 6.6, “Generic Switch” . Manufacturers are encouraged to implement the Generic Switch device type as well in products that are generically referred to as switches. See Section 6.6.5, “Relation with other Switch device types (informative)” for examples how these device types can be combined.
6.1. On/Off Light Switch
An On/Off Light Switch is a controller device that, when bound to a lighting device such as an On/Off Light, is capable of being used to switch the device on or off.
6.1.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
6.1.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0103 |
On/Off Light Switch |
Simple |
Endpoint |
6.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0005 |
Scenes |
Client |
O |
|
|
0x0006 |
On/Off |
Client |
M |
6.1.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6.2. Dimmer Switch
A Dimmer Switch is a controller device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off and adjust the intensity of the light being emitted.
6.2.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
6.2.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0104 |
Dimmer Switch |
On/Off Light Switch |
Simple |
Endpoint |
6.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0005 |
Scenes |
Client |
O |
|
|
0x0006 |
On/Off |
Client |
M |
|
|
0x0008 |
Level Control |
Client |
M |
6.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6.3. Color Dimmer Switch
A Color Dimmer Switch is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to adjust the color of the light being emitted.
6.3.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
6.3.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0105 |
Color Dimmer Switch |
Dimmer Switch |
Simple |
Endpoint |
6.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0005 |
Scenes |
Client |
O |
|
|
0x0006 |
On/Off |
Client |
M |
|
|
0x0008 |
Level Control |
Client |
M |
|
|
0x0300 |
Color Control |
Client |
M |
6.3.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6.4. Control Bridge
A Control Bridge is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to switch the device on or off, adjust the intensity of the light being emitted and adjust the color of the light being emitted. In addition, a Control Bridge device is capable of being used for setting scenes.
6.4.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Revision is zero before revision numbers are defined and is required. |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
6.4.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
M |
|
|
0x0004 |
Groups |
Client |
M |
|
|
0x0005 |
Scenes |
Client |
M |
|
|
0x0006 |
On/Off |
Client |
M |
|
|
0x0008 |
Level Control |
Client |
M |
|
|
0x0300 |
Color Control |
Client |
M |
|
|
0x0400 |
Illuminance Measurement |
Client |
O |
|
|
0x0406 |
Occupancy Sensing |
Client |
O |
6.4.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6.5. Pump Controller
A Pump Controller device is capable of configuring and controlling a Pump device.
6.5.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
6.5.3. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x001E |
Binding |
Client |
M |
|
|
0x0006 |
On/Off |
Client |
M |
|
|
0x0200 |
Pump Configuration and Control |
Client |
M |
|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
O |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0005 |
Scenes |
Client |
O |
|
|
0x0008 |
Level |
Client |
O |
|
|
0x0402 |
Temperature Measurement |
Client |
O |
|
|
0x0403 |
Pressure Measurement |
Client |
O |
|
|
0x0404 |
Flow Measurement |
Client |
O |
6.5.4. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
6.6. Generic Switch
This defines conformance for the Generic Switch device type.
6.6.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
6.6.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|
|
Identify |
Server |
M |
|
|
Switch |
Server |
M |
|
|
FixedLabel |
Server |
desc |
6.6.4.1. Instantaneous reporting
The
generic
mechanism
for
subscriptions
and
events
might
not
ensure
that
detected
interactions
with
the
switch
will
be
delivered
"instantaneously"
to
the
Switch
client
cluster
in
the
interested
party
(they
might
be
sent
only
after
some
time,
e.g.
due
to
batching
of
events
and
the
Min
Interval
behavior
for
subscriptions).
In
order
to
achieve
a
good
user
experience,
a
device
of
this
device
type
SHALL
send
updates
of
attributes
and
events
defined
in
the
Switch
cluster
without
delay
to
subscribed
parties.
6.6.4.2. Labeling for multi-switch devices
A Node which contains multiple switches will need to expose multiple endpoints each hosting an instance of this device type and the associated Switch cluster. Typically the switches on such a Node have an orientation (e.g. left and right for a two-button switch) or labeling (e.g. "dim up" and "dim down" icons printed on the buttons) relevant to the user. In order to allow other Nodes, which are interacting with this multi-button switch, to convey such information to the user (e.g. showing it in a user interface), a Node which has multiple endpoints hosting an instance of this device type and the associated Switch cluster, SHALL also host a Fixed Label server cluster on each of those endpoints. This Fixed Label cluster SHALL include at least one LabelList entry filled by the manufacturer, to identify the orientation or labeling of each of the associated buttons. The Label field of the tuples SHALL be populated so it can be correlated with the Label field of the tuples on other endpoints.
For a Node which has only one endpoint hosting an instance of this device type and the associated Switch cluster, use of the Fixed Label is optional, but can be beneficial in cases the switch has some user-recognizable labelling.
The Value of a LabelList tuple MAY be localized to local language, based on the value of the attribute ActiveLocale in the LocalizationConfiguration cluster.
Example 1: a device with two rocker switches (mounted side by side), which has two endpoints (11,12) for the switch-related functionality
-
endpoint 11 has device type Generic Switch and contains
-
cluster Switch (feature flags: LS) exposing the state and events of the left button
-
cluster Fixed Label with its LabelList containing one tuple: Label="button-orientation", Value="left button"
-
-
endpoint 12 has device type Generic Switch and contains
-
cluster Switch (feature flags: LS) exposing the state and events of the right button
-
cluster Fixed Label with its LabelList containing one tuple: Label="button-orientation", Value="right button"
-
Example 2: a device with four push buttons (mounted in a square), each labelled with an icon for a certain scene setting, which has four endpoints (21,22,23,24) for the switch-related functionality
-
endpoint 21 has device type Generic Switch and contains
-
cluster Switch (feature flags: MS) exposing the events of the top-left button
-
cluster Fixed Label with its LabelList containing two tuples:
-
Label="button-orientation", Value="top-left button"
-
Label="button-label", Value="watch tv"
-
-
-
endpoint 22 has device type Generic Switch and contains
-
cluster Switch (feature flags: MS) exposing the events of the top-right button
-
cluster Fixed Label with its LabelList containing two tuples:
-
Label="button-orientation", Value="top-right button"
-
Label="button-label", Value="dinner"
-
-
-
endpoint 23 has device type Generic Switch and contains
-
cluster Switch (feature flags: MS) exposing the events of the bottom-left button
-
cluster Fixed Label with its LabelList containing two tuples:
-
Label="button-orientation", Value="bottom-left button"
-
Label="button-label", Value="reading"
-
-
-
endpoint 24 has device type Generic Switch and contains
-
cluster Switch (feature flags: MS) exposing the events of the bottom-right button
-
cluster Fixed Label with its LabelList containing two tuples:
-
Label="button-orientation", Value="bottom-right button"
-
Label="button-label", Value="nightlight"
-
-
6.6.5. Relation with other Switch device types (informative)
The Generic Switch device type and the On/Off Light Switch device type both convey information about interactions with a switch to another device.
-
The On/Off Light Switch will send On/Off/Toggle commands from its On/Off (client) cluster to a device implementing the On/Off (server) cluster to control the on/off functionality of that device. An On/Off Light Switch device can also implement Groups and Scenes clusters and thus send group and scene commands. Basically, it is targeted at directly sending control commands to other devices. The binding table is used to tell the device where to send the commands.
-
The Generic Switch device type will send updates of attributes (for Latching Switch only) and events to subscribed parties which implement the Switch client cluster, as indications of interaction with the switch - leaving the interpretation (e.g. which device should be actuated because of the interaction) to the subscribed party. So it can be compared to a sensor-type device.
This allows a more comprehensive controller to combine the information from the switch with other inputs or information sources (e.g. time of day, user presence) to determine which control commands (e.g. on/off, scene recall, attribute change) are sent to other devices in the network.
A device manufacturer MAY implement both device types on the same switch device, to allow it to be used for both types of control, as in this example for a rocker switch which implements:
-
endpoint 31 with device type On/Off Light Switch which contains
-
(client) cluster On/Off exposing the On/Off/Toggle commands
-
-
endpoint 32 with device type Generic Switch which contains
-
(server) cluster Switch (feature flags: LS) exposing the state and events of the switch
-
When this device is used in a particular setup, binding tables and subscriptions can be used to determine how it is used:
-
used as an On/Off Light Switch (no subscriptions to endpoint 32)
-
used as a Generic Switch (no bindings on endpoint 31)
-
used as both at the same time. In this case, an interaction with the switch would result in an On/Off/Toggle command being sent to devices listed in the binding table of endpoint 31, as well as attribute update and events being sent towards devices having a subscription with endpoint 32.
7. Sensor Device Types
7.1. Contact Sensor
This defines conformance to the Contact Sensor device type.
7.1.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
1 |
Initial release |
7.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0045 |
Boolean State |
Server |
M |
The semantics of the boolean value reported by this cluster are:
-
FALSE=open or no contact
-
TRUE=closed or contact
7.1.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.2. Light Sensor
A Light Sensor device is a measurement and sensing device that is capable of measuring and reporting the intensity of light (illuminance) to which the sensor is being subjected.
7.2.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0400 |
Illuminance Measurement |
Server |
M |
7.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.3. Occupancy Sensor
An Occupancy Sensor is a measurement and sensing device that is capable of measuring and reporting the occupancy state in a designated area.
7.3.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0406 |
Occupancy Sensing |
Server |
M |
7.3.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.4. Temperature Sensor
A Temperature Sensor device reports measurements of temperature.
7.4.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.5. Pressure Sensor
A Pressure Sensor device measures and reports the pressure of a fluid.
7.5.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.5.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0403 |
Pressure Measurement |
Server |
M |
|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Client |
[Zigbee] |
7.5.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.6. Flow Sensor
A Flow Sensor device measures and reports the flow rate of a fluid.
7.6.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.6.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0404 |
Flow Measurement |
Server |
M |
|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Client |
[Zigbee] |
7.6.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.7. Humidity Sensor
A humidity sensor (in most cases a Relative humidity sensor) reports humidity measurements.
7.7.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Zigbee 3.0 |
|
2 |
New data model format and notation |
7.7.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0405 |
Relative Humidity Measurement |
Server |
M |
|
|
0x0004 |
Groups |
Client |
[Zigbee] |
7.7.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
7.8. On/Off Sensor
An On/Off Sensor is a measurement and sensing device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off.
7.8.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Revision is zero before revision numbers are defined and is required. |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
7.8.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Cluster | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0003 |
Identify |
Client |
M |
|
|
0x0004 |
Groups |
Client |
O |
|
|
0x0005 |
Scenes |
Client |
O |
|
|
0x0006 |
On/Off |
Client |
M |
|
|
0x0008 |
Level Control |
Client |
O |
|
|
0x0300 |
Color Control |
Client |
O |
7.8.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
8. Closure Device Types
8.1. Door Lock
A Door Lock is a device used to secure a door. It is possible to actuate a door lock either by means of a manual or a remote method.
8.1.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
Initial Matter release |
8.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
[Zigbee] |
|
|
0x0005 |
Scenes |
Server |
[Zigbee] |
|
|
0x0101 |
Door Lock |
Server |
M |
|
|
0x0009 |
Alarms |
Server |
[Zigbee] |
|
|
0x0020 |
Poll Control |
Server |
O |
|
|
0x000A |
Time |
Client |
[Zigbee] |
|
|
0x0038 |
TimeSync |
Client |
P, O |
8.1.5. Cluster Restrictions
It is OPTIONAL for a Door Lock Controller device to support finding and binding.
8.1.6. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank entry means no change.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
QRY (Query) |
Zigbee |
||
|
1 |
Door Lock |
Feature |
RID (RFID Credential) |
[Zigbee], P, O |
||
|
3 |
Door Lock |
Feature |
LOG (Logging) |
[Zigbee] |
||
|
8 |
Door Lock |
Feature |
USR (User) |
Matter & (PIN | RID | FPG | FACE) |
||
|
9 |
Door Lock |
Feature |
NOT (Notification) |
[Zigbee] |
||
|
0x0001 |
AccessControl |
Attribute |
Extension |
Matter |
||
|
0x0040 |
Door Lock |
Attribute |
AlarmMask |
[Alarms] |
||
|
0x0041 |
Door Lock |
Attribute |
KeypadOperationEventMask |
[Zigbee] |
||
|
0x0042 |
Door Lock |
Attribute |
RemoteOperationEventMask |
[Zigbee] |
||
|
0x0043 |
Door Lock |
Attribute |
ManualOperationEventMask |
[Zigbee] |
||
|
0x0044 |
Door Lock |
Attribute |
RFIDOperationEventMask |
[Zigbee] |
||
|
0x0045 |
Door Lock |
Attribute |
KeypadProgrammingEventMask |
[Zigbee] |
||
|
0x0046 |
Door Lock |
Attribute |
RemoteProgrammingEventMask |
[Zigbee] |
||
|
0x0047 |
Door Lock |
Attribute |
RFIDProgrammingEventMask |
[Zigbee] |
||
|
0x20 |
Door Lock |
Command |
Operating Event Notification |
[Zigbee] |
||
|
0x21 |
Door Lock |
Command |
Programming Event Notification |
[Zigbee] |
8.1.7. PICS
A Door Lock device SHALL support PICS items listed below.
Note: A Door Lock device MAY support other optional PICS items.
| Cluster |
|---|
|
PICS item |
|
Basic |
|
B.S B.S.A0000, B.S.A0007, B.S.Afffd |
|
Identify |
|
I.S I.S.A0000, I.S.Afffd I.S.C00.Rsp, I.S.C01.Rsp I.S.C00.Tx |
|
Groups |
|
G.S G.S.A0000, G.S.Afffd G.S.C00.Rsp, G.S.C01.Rsp, G.S.C02.Rsp, G.S.C03.Rsp, G.S.C04.Rsp, G.S.C05.Rsp G.S.C00.Tx, G.S.C01.Tx, G.S.C02.Tx, G.S.C03.Tx |
|
Scenes |
|
S.S S.S.A0000, S.S.A0001, S.S.A0002, S.S.A0003, S.S.A0004, S.S.Afffd S.S.C00.Rsp, S.S.C01.Rsp, S.S.C02.Rsp, S.S.C03.Rsp, S.S.C04.Rsp, S.S.C05.Rsp, S.S.C06.Rsp S.S.C00.Tx, S.S.C01.Tx, S.S.C02.Tx, S.S.C03.Tx, S.S.C04.Tx, S.S.C06.Tx |
|
Door Lock |
|
DRLK.S DRLK.S.A0000, DRLK.S.A0001, DRLK.S.A0002, DRLK.S.Afffd DRLK.S.C00.Rsp, DRLK.S.C01.Rsp DRLK.S.C00.Tx, DRLK.S.C01.Tx |
8.2. Door Lock Controller
A Door Lock Controller is a device capable of controlling a door lock.
8.2.1. Revision History
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
Initial Matter release |
8.2.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x000B |
Door Lock Controller |
Simple |
Endpoint |
8.2.3. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
[EZ-Target] |
|
|
0x0003 |
Identify |
Client |
[EZ-Initiator] |
|
|
0x0004 |
Groups |
Client |
Zigbee |
|
|
0x0005 |
Scenes |
Client |
Zigbee |
|
|
0x0101 |
Door Lock |
Client |
M |
|
|
0x0038 |
TimeSync |
Server |
P, O |
8.2.4. Cluster Restrictions
It is OPTIONAL for a Door Lock Controller device to support EZ-Mode finding and binding.
8.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank entry means no change.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
8.2.6. PICS
A Door Lock Controller device SHALL support PICS items listed in Table 20, “Door Lock Controller PICS Items” .
Note: A Door Lock Controller device MAY support other optional PICS items.
| Cluster | PICS Item |
|---|---|
|
Basic |
B.S B.S.A0000, B.S.A0007, B.S.Afffd |
|
Identify |
I.S I.S.A0000, I.S.Afffd I.S.C00.Rsp, I.S.C01.Rsp I.S.C00.Tx I.C I.C.Afffd I.C.C00.Rsp I.C.C01.Tx |
|
Groups |
G.C G.C.Afffd |
|
Scenes |
S.C S.C.Afffd |
|
Door Lock |
DRLK.C DRLK.C.Afffd |
8.3. Window Covering
This defines conformance to the Window Covering device type.
8.3.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0. |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
8.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
Awake, O |
|
|
0x0005 |
Scenes |
Server |
Awake, O |
|
|
0x0102 |
Window Covering |
Server |
M |
8.3.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0102 |
Window Covering |
Feature |
Absolute Position |
!Matter |
||
|
0x0102 |
Window Covering |
Command Field |
GoToLiftPercentage LiftPercentageValue |
!Matter |
||
|
0x0102 |
Window Covering |
Command Field |
GoToTiltPercentage TiltPercentageValue |
!Matter |
||
|
0x0102 |
Window Covering |
Command Field |
GoToLiftPercentage LiftPercent100thsValue |
Matter |
||
|
0x0102 |
Window Covering |
Command Field |
GoToTiltPercentage TiltPercent100thsValue |
Matter |
8.4. Window Covering Controller
A Window Covering Controller is a device that controls an automatic window covering.
8.4.1. Revision History
| Rev | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation |
8.4.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0203 |
Window Covering Controller |
Simple |
Endpoint |
8.4.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
O |
|
|
0x0003 |
Identify |
Client |
O |
|
|
0x0004 |
Groups |
Client |
Awake, O |
|
|
0x0005 |
Scenes |
Client |
Awake, O |
|
|
0x0102 |
Window Covering |
Client |
M |
8.4.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
||
|
0x0102 |
Window Covering |
Feature |
Absolute Position |
!Matter |
9. HVAC Device Types
9.1. Heating/Cooling Unit
A Heating/Cooling Unit is a device capable of heating or cooling a space in a house. It is not mandatory to provide both functionalities (for example, the device may just heat but not cool). It may be an indoor air handler.
|
Note
|
Heating/Cooling Unit device type is provisional. |
9.1.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to Zigbee 3.0 |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
Initial Matter release |
9.1.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0300 |
Heating/Cooling Unit |
Simple |
Endpoint |
9.1.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
M |
|
|
0x0006 |
On/Off |
Server |
M |
|
|
0x0201 |
Thermostat |
Client |
M |
|
|
0x0005 |
Scenes |
Server |
O |
|
|
0x0008 |
Level |
Server |
O |
|
|
0x0202 |
Fan Control |
Server |
P, O |
9.1.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
!Matter |
9.2. Thermostat
A Thermostat device is capable of having either built-in or separate sensors for temperature, humidity or occupancy. It allows the desired temperature to be set either remotely or locally. The thermostat is capable of sending heating and/or cooling requirement notifications to a heating/cooling unit (for example, an indoor air handler) or is capable of including a mechanism to control a heating or cooling unit directly.
9.2.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial Zigbee 3.0 release |
|
2 |
New data model format and notation, added Clusters required for Matter support, restricted legacy elements to Zigbee only |
9.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| ID | Name | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0003 |
Identify |
Server |
M |
|
|
0x0004 |
Groups |
Server |
Awake |
|
|
0x0201 |
Thermostat |
Server |
M |
|
|
0x0005 |
Scenes |
Server |
O |
|
|
0x0009 |
Alarms |
Server |
[Zigbee] |
|
|
0x0204 |
Thermostat User Interface Configuration |
Server |
O |
|
|
0x0405 |
Relative Humidity Measurement |
Client |
O |
|
|
0x000A |
Time |
Client |
[Zigbee] |
|
|
0x0038 |
TimeSync |
Server |
P, O |
|
|
0x0038 |
TimeSync |
Client |
P, O |
|
|
0x0202 |
Fan Control |
Client |
P, O |
|
|
0x0402 |
Temperature Measurement |
Client |
O |
|
|
0x0406 |
Occupancy Sensing |
Client |
O |
9.2.5. Element Requirements
Below list qualities and conformance that override the cluster specification requirements. A blank table cell means there is no change to that item and the value from the cluster specification applies.
| ID | Cluster | Element | Name | Constraint | Access | Conformance |
|---|---|---|---|---|---|---|
|
0 |
Identify |
Feature |
Query |
Zigbee |
||
|
3 |
Thermostat |
Feature |
Schedule Configuration |
[Zigbee], P |
||
|
29 |
Thermostat |
Attribute |
AlarmMask |
[Zigbee] |
||
|
4 |
Thermostat |
Command |
Get Relay Status Log |
[Zigbee] |
||
|
1 |
Thermostat |
Command |
Get Relay Status Log Response |
[Zigbee] |
9.3. Fan
This defines conformance to the Fan device type.
|
Note
|
Support for Fan device type is provisional. |
9.3.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
1 |
Initial release of this document |
10. Media Device Types
10.1. Video Player Architecture
10.1.1. Introduction
A Video Player endpoint (either Casting Video Player or Basic Video Player) represents a device that is able to play media to a physical output or to a display screen which is part of the device. For example, a Video Player can be a traditional TV device, a physical media playback device such as a DVD Player, a TV Set Top Box, or a content streaming device that provides input to another device like a TV or computer monitor.
Video Player features can be categorized into basic and content launching .
The basic features include (conceptually): On/Off, Volume Control, Playback Control, Channel Change, Input Control, Output Control, Sleep/Wake, Target Navigation and Keypad Navigation.
The content launching features include: discovery and launch of Content Apps, search and launch of content by content name and by URL.
A Basic Video Player is a commissionable node and supports these basic features which include, at a minimum, media playback controls (Media Playback cluster server) and remote controls (Keypad Input cluster server).
A Casting Video Player is a commissioner and supports both the Basic Video Player features and content launching features which include, at a minimum, the ability to launch content (Content Launcher cluster server).
A Content App is usually an application built by a Content Provider and exists as a separate endpoint on a Casting Video Player with a Content App Platform.
When a Casting Video Player includes a Content App Platform, it can launch Content Apps (Application Launcher cluster server) and represent these apps as separate endpoints on the Node.
A Video Remote Control is a commissionable node used to control basic features including, at a minimum, the ability to initiate keypad navigation (Keypad Input cluster client) and media playback (Media Playback cluster client).
A Casting Video Client is a commissionable node which extends the Video Remote Control features with the ability to initiate content launching (Content Launcher cluster client). A Casting Video Client is often associated with a Content App built by a specific Content Provider - for example, the Vendor Id of the Content App’s Application Basic cluster will match the Vendor Id of the Casting Video Client.
10.1.2. Clients of a Casting Video Player
The clients for a Video Player device can be categorized into 2 high-level groups.
-
Clients controlling the Video Player endpoint such as a remote control (eg : Video Remote device type)
-
Clients controlling specific Content App(s) such as a Phone App casting to a corresponding Content App (eg : Casting Video Client device type)
10.1.3. Endpoint Composition for Content Apps of a Casting Video Player
A Casting Video Player with a Content App Platform SHALL represent each Content App as its own dedicated endpoint where each is identified using the Device ID 0x0024 for "Content App".
The requirements for allocating and deallocating an endpoint address for a Content App SHALL be as described in the System Model specification (see "Dynamic Endpoint allocation").
The following diagram shows a Video Player device containing 3 separate Content Apps:
10.1.4. Commissioning
A Basic Video Player SHALL be commissioned like any commissionable node.
A Casting Video Player SHALL be a Commissioner. The primary reason for this requirement is to enable the Casting Video Player to verify, using device attestation, the vendor of a Client for the purpose of controlling content on the Casting Video Player, and to ensure that only clients authorized by a Content App can control it. In this way, a Commissionee associated with a Content App on the Casting Video Player can be commissioned by the Casting Video Player and granted access to the endpoint associated with that Content App.
When a Casting Video Player commissions a Client, such as a Video Remote Control or a Casting Video Client, the Casting Video Player SHALL determine the Content App access for the given Client following the rules defined in this section. Since the Client is being commissioned by the Casting Video Player, the Client, which may be a phone app, SHALL include attestation credentials which are used by the Casting Video Player to determine its Vendor ID.
-
A Casting Video Player SHOULD allow each Content App to specify which clusters it implements, and reflect these clusters in the corresponding endpoint for the given Content App. The method for conveying this information between the Content App and the Casting Video Player is specific to the vendor of the Casting Video Player.
-
A Casting Video Player SHALL allow each Content App to specify values for fields in the Application Basic cluster, such as Vendor ID and Application Name. A Casting Video Player SHALL also use this information to determine access control for Clients commissioned by the Casting Video Player. The method for conveying this information between the Content App and the Casting Video Player is specific to the vendor of the Casting Video Player.
-
A Casting Video Player device SHALL allow each Content App to provide an Allowed Controller Vendor ID list. The Allowed Controller Vendor ID list specifies a list of Vendor IDs for Clients that SHALL be granted access to the endpoint for the given Content App. The Casting Video Player device SHALL use the Allowed Controller Vendor ID list to determine access control for Clients commissioned by the Casting Video Player. Only Clients with a Vendor ID in the Allowed Controller Vendor ID list SHALL be granted access to the given Content App endpoint. The method for conveying this information between the Content App and the Casting Video Player is specific to the vendor of the Casting Video Player. When a Client is commissioned, its attested Vendor ID is used to determine access to Content App endpoints. The Allowed Controller Vendor ID list is contained in the AllowedVendorList attribute of the Application Basic cluster.
A Casting Video Player MAY enable a commissioning flow, which avoids Setup PIN entry by the user, when the following conditions are met: . The Client’s Vendor ID and a Rotating ID (used as a TempAccountIdentifier) are present in its commissionable node advertisement. . The Casting Video Player is able to determine an endpoint corresponding to the given Vendor ID which contains the Account Login cluster (for example, a Content App endpoint). . The Account Login cluster’s GetSetupPIN command returns a SetupPIN which is then used successfully to commission the Client.
A Casting Video Player MAY enable a Content App account login flow, which avoids login name and password entry by the user, when the following conditions are met: . The Client’s Vendor ID and a Rotating ID (used as a TempAccountIdentifier) are present in its commissionable node advertisement. . The Casting Video Player is able to determine an endpoint corresponding to the given Vendor ID which contains the Account Login cluster (for example, a Content App endpoint). . The Account Login cluster’s Login command returns successfully.
In these flows, when the Account Login cluster is located on a Content App endpoint, the Account Login cluster will often be implemented by a different vendor from the Casting Video Player itself. See AccountLoginCluster for further details on the use of these commands.
Since a Client commissioned by the Casting Video Player will only have access to one or more Content App endpoints and the Speaker endpoint (when present), it will not have the ability to access the Application Launcher cluster on the Casting Video Player endpoint. If they do not already exist, the Casting Video Player device SHALL create endpoints for each Content App to which the Client has access and notify the Client of such access by adding an entry for each Content App to the Binding cluster of the Client. The Casting Video Player device SHALL automatically launch the Content App upon commands targeted to a Content App endpoint.
Note: A Client commissioned by the Casting Video Player is able to determine if the corresponding Content App is visible to the user using the Status attribute on the Application Basic cluster for the Content App endpoint. This ensures that the Client cannot access foreground Content App information about any other Content App to which it does not have access. It also ensures that such a client will only need access to specific Content App endpoints and the Speaker endpoint (when present).
10.1.5. Determining Context
A client that controls multiple aspects of the Video Player functionality (like a voice assistant) may have access to multiple endpoints on the Video Player. To determine the current context on the Video Player when the user interacts with the client (for example, when the user interacts with the device using voice), the client can look at the state in the various clusters on the Casting Video Player.
Specifically:
-
Media Input cluster (when CurrentInput does NOT have type INTERNAL, then Video Player is displaying content from a physical input)
-
Application Launcher cluster (CurrentApp indicates the current application endpoint - which may be the Video Player endpoint when no Content App is in the foreground).
-
Target Navigator cluster on current application endpoint (indicates which navigation target the user is in)
The Video Player SHOULD provide a way for the user to view the list of clients with access to control the screen and SHOULD provide a way for the user to revoke this access.
10.1.6. Basic Video Player Features
10.1.6.1. On/Off/Toggle
This feature turns on/off the user-visible power state of the device, corresponding to the on/off/toggle button usually found on a remote or button on the device.
An On/Off cluster on the Video Player endpoint SHALL be used for this feature.
10.1.6.2. Volume Control
This feature controls the speaker volume of the device.
A Speaker endpoint SHALL be used for this feature when the device controls a speaker.
10.1.6.3. Media Playback Control
This feature controls media playback on the device which includes functionality such as Play, Pause, Stop, Rewind, and Fast Forward.
The Media Playback cluster SHALL be used for this functionality.
10.1.6.4. Channel Change
This feature controls channel control functionality on the device which includes functionality such as lineup discovery, change and skip channels.
The Channel cluster SHALL be used for this functionality.
10.1.6.5. Media Input Control
This feature controls the input selection on the device which includes functionality such as input discovery, selection and naming.
The Media Input cluster SHALL be used for this functionality.
10.1.6.6. Audio Output Control
This feature controls audio output selection on the device which includes functionality such as output discovery, selection and naming.
The Audio Output cluster SHALL be used for this functionality.
Note that when the current output is set to an output of type HDMI, adjustments to volume via a Speaker endpoint on the same node MAY cause HDMI volume up/down commands to be sent to the given HDMI output.
10.1.6.7. Sleep/Wake
This feature controls low power mode on the device which includes functionality such as sleep, and declaration of protocols supported for Wakeup.
The Low Power cluster SHALL be used for putting a device into low power (sleep) mode.
The WakeOnLAN cluster SHALL be used for declaring that a device supports the WakeOnLAN protocol.
10.1.6.8. Target Navigation
This feature controls on-screen navigation to custom-named targets, for example, "Settings", "On Demand" and "Search". A list of named targets can be provided for the Video Player endpoint itself, as well as for Content App represented as endpoints.
The Target Navigator cluster SHALL be used for listing navigation targets, invoking navigation to a target, and tracking the current target.
10.1.7. Content Launching Features
Many Video Player devices (traditional TVs, Set Top Boxes, Content Streamers) have advanced features that MAY include any of the following: - the ability to search for and playback content such as movies and TV shows - a platform for Content Apps that can themselves be launched, and instructed to search and playback content such as movies and TV shows - the ability to download and playback basic content referenced by URL
10.1.7.1. Discover and Launch Content App from another Device
This feature allows a client to discover the Content App identification catalogs supported by a Video Player device, and launch an Application based upon a Content App identifier within a given catalog. An example Content App identification catalog is the DIAL registry ( http://www.dial-multiscreen.org/ ).
The Application Launcher cluster SHALL be used for this functionality.
10.1.7.2. Launch Content from another Device
Content search and launch is defined by the Content Launcher cluster which includes feature flags for Content Search and URL Playback which are used to indicate which of these features is supported.
The Content Launcher cluster SHALL be used for this functionality.
10.2. Basic Video Player
This defines conformance to the Basic Video Player device type.
A Video Player (either Basic or Casting) represents a device that is able to play media to a physical output or to a display screen which is part of the device.
A Basic Video Player has playback controls (play, pause, etc.) and keypad remote controls (up, down, number input), but is not able to launch content and is not a content app platform (the Casting Video Player device type is used for these functions).
For example, a Basic Video Player can be a traditional TV device a physical media playback device such as a DVD Player, or a device that provides input to another device like a TV or computer monitor.
Please see Video Player Architecture for additional Basic Video Player requirements relating to Video Player device endpoint composition, commissioning, feature representation in clusters, and UI context.
10.2.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.2.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0028 |
Basic Video Player |
Simple |
Endpoint |
10.2.3. Conditions
This device type SHALL support the following conformance conditions as defined below.
| Feature | Description |
|---|---|
|
PhysicalInputs |
The device has physical inputs for media. |
Please see the Base Device Type definition for additional conformance tags.
10.2.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| Identifier | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0006 |
OnOff |
Server |
M |
|
|
0x0503 |
WakeOnLAN |
Server |
O |
|
|
0x0504 |
Channel |
Server |
O |
|
|
0x0505 |
Target Navigator |
Server |
O |
|
|
0x0506 |
Media Playback |
Server |
M |
|
|
0x0507 |
Media Input |
Server |
PhysicalInputs |
|
|
0x0508 |
Low Power |
Server |
O |
|
|
0x0509 |
Keypad Input |
Server |
M |
|
|
0x050B |
Audio Output |
Server |
O |
10.3. Casting Video Player
This defines conformance to the Casting Video Player device type.
A Video Player (either Basic or Casting) represents a device that is able to play media to a physical output or to a display screen which is part of the device.
A Casting Video Player has basic controls for playback (play, pause, etc.) and keypad input (up, down, number input), and is able to launch content.
For example, a Casting Video Player can be a smart TV device, a TV Set Top Box, or a content streaming device that provides input to another device like a TV or computer monitor.
Please see Video Player Architecture for additional Casting Video Player requirements relating to Video Player device endpoint composition, commissioning, feature representation in clusters, and UI context.
10.3.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.3.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0023 |
Casting Video Player |
Simple |
Endpoint |
10.3.3. Conditions
This device type SHALL support the following conformance conditions as defined below.
| Feature | Description |
|---|---|
|
ContentAppPlatform |
The device includes a Content App Platform. A Content App is usually an application built by a Content Provider. A Casting Video Player with a Content App Platform is able to launch Content Apps and represent these apps as separate endpoints. |
|
PhysicalInputs |
The device has physical inputs for media. |
Please see the Base Device Type definition for additional conformance tags.
10.3.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| Identifier | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0006 |
OnOff |
Server |
M |
|
|
0x0503 |
WakeOnLAN |
Server |
O |
|
|
0x0504 |
Channel |
Server |
O |
|
|
0x0505 |
Target Navigator |
Server |
O |
|
|
0x0506 |
Media Playback |
Server |
M |
|
|
0x0507 |
Media Input |
Server |
PhysicalInputs |
|
|
0x0508 |
Low Power |
Server |
O |
|
|
0x0509 |
Keypad Input |
Server |
M |
|
|
0x050A |
Content Launcher |
Server |
M |
|
|
0x050B |
Audio Output |
Server |
O |
|
|
0x050C |
Application Launcher |
Server |
ContentAppPlatform |
|
|
0x050E |
Account Login |
Server |
O |
10.4. Speaker
This defines conformance to the Speaker device type.
This feature controls the speaker volume of the device.
To control unmute/mute, the On/Off cluster SHALL be used. A value of TRUE for the OnOff attribute SHALL represent the volume on (not muted) state, while a value of FALSE SHALL represent the volume off (muted) state. For volume level control, the Level cluster SHALL be used.
A dedicated endpoint is needed because the On/Off cluster can also be used for other purposes, such as for power control.
The decision to use Level and On/Off clusters for volume (rather than defining a new audio control cluster) was made in order to treat volume in a fashion consistent with lighting which also uses these clusters and has matching functional requirements.
10.4.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.5. Content App
This defines conformance to the Content App device type.
A Content App is usually an application built by a Content Provider. A Casting Video Player with a Content App Platform is able to launch Content Apps and represent these apps as separate endpoints.
10.5.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.5.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| Identifier | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0504 |
Channel |
Server |
O |
|
|
0x0505 |
Target Navigator |
Server |
O |
|
|
0x0506 |
Media Playback |
Server |
O |
|
|
0x0509 |
Keypad Input |
Server |
M |
|
|
0x050A |
Content Launcher |
Server |
O |
|
|
0x050C |
Application Launcher |
Server |
M |
|
|
0x050D |
Application Basic |
Server |
M |
|
|
0x050E |
Account Login |
Server |
O |
10.6. Casting Video Client
This defines conformance to the Casting Video Client device type.
A Casting Video Client is a client that can launch content on a Casting Video Player, for example, a Smart Speaker or a Content Provider phone app.
10.6.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.6.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x0029 |
Casting Video Client |
Simple |
Endpoint |
10.6.3. Conditions
This device type SHALL support the following conformance conditions as defined below.
| Feature | Description |
|---|
Please see the Base Device Type definition for additional conformance tags.
10.6.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| Identifier | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0006 |
OnOff |
Client |
M |
|
|
0x0008 |
Level |
Client |
O |
|
|
0x0503 |
WakeOnLAN |
Client |
O |
|
|
0x0504 |
Channel |
Client |
O |
|
|
0x0505 |
Target Navigator |
Client |
O |
|
|
0x0506 |
Media Playback |
Client |
O |
|
|
0x0507 |
Media Input |
Client |
O |
|
|
0x0508 |
Low Power |
Client |
O |
|
|
0x0509 |
Keypad Input |
Client |
M |
|
|
0x050A |
Content Launcher |
Client |
M |
|
|
0x050B |
Audio Output |
Client |
O |
|
|
0x050C |
Application Launcher |
Client |
O |
|
|
0x050D |
Application Basic |
Client |
M |
|
|
0x050E |
Account Login |
Client |
O |
10.7. Video Remote Control
This defines conformance to the Video Remote Control device type.
A Video Remote Control is a client that can control a Video Player, for example, a traditional universal remote control.
10.7.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |
10.7.2. Classification
| ID | Device Name | Superset | Class | Scope |
|---|---|---|---|---|
|
0x002a |
Video Remote Control |
Simple |
Endpoint |
10.7.3. Conditions
This device type SHALL support the following conformance conditions as defined below.
| Feature | Description |
|---|
Please see the Base Device Type definition for additional conformance tags.
10.7.4. Cluster Requirements
Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.
| Identifier | ClusterName | Client/Server | Quality | Conformance |
|---|---|---|---|---|
|
0x0006 |
OnOff |
Client |
M |
|
|
0x0008 |
Level |
Client |
O |
|
|
0x0503 |
WakeOnLAN |
Client |
O |
|
|
0x0504 |
Channel |
Client |
O |
|
|
0x0505 |
Target Navigator |
Client |
O |
|
|
0x0506 |
Media Playback |
Client |
M |
|
|
0x0507 |
Media Input |
Client |
O |
|
|
0x0508 |
Low Power |
Client |
O |
|
|
0x0509 |
Keypad Input |
Client |
M |
|
|
0x050A |
Content Launcher |
Client |
O |
|
|
0x050B |
Audio Output |
Client |
O |
|
|
0x050C |
Application Launcher |
Client |
O |
|
|
0x050E |
Account Login |
Client |
O |
11. Generic Device Types
11.1. Mode Select
This defines conformance to the Mode device type.
11.1.1. Revision History
This
is
the
revision
history
for
this
document.
device
type.
The
highest
revision
number
in
the
table
below
is
the
revision
for
this
device
type.
| Revision | Description |
|---|---|
|
0 |
Represents device definitions prior to device type revision numbers |
|
1 |
Initial release of this document |