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

[MatterCore]

https://github.com/CHIP-Specifications/connectedhomeip-spec/raw/build-sample/pdf/main.pdf

Matter Core Specification - Under development

[CSA-PNP]

https://groups.csa-iot.org/wg/members/document/21624

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.

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.2. Protocol Conditions
Protocol Tag

Ethernet

Wi-Fi

Thread

TCP

UDP

IP

IPv4

IPv6

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 specification)>) specification)

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

Root Node

0x0011

Power Source

0x0012

OTA Requestor

0x0014

OTA Provider

0x000e

Aggregator

0x0013

Bridged Node

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.2. Classification

ID Device Name Superset Class Scope

0x0016

Root Node

Node

Node

2.1.3. Overview 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. Other non-Node device types and Application clusters SHALL NOT be supported on the same endpoint as this device type. Other Node device types MAY be supported on the same endpoint as this device type.

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 NetworkCommissioning cluster).

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.1.5. Endpoint Composition

A Root Node endpoint’s Descriptor cluster PartsList attribute SHALL be a flat list of all other endpoints on the node.

2.2. Power Source

2.2.1. Classification

ID Device Name Superset Class Scope

0x0011

Power Source

Utility

Node

2.2.2. Revision History

Revision Description

1

Initial Release

2.2.3. Cluster Requirements

This device SHALL support the clusters listed in the following table.

ID ClusterName Client/Server Quality Conformance

0x002F

Power Source

Server

M

2.3. OTA Requestor

An OTA Requestor is a device that is capable of receiving an OTA software update.

2.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

2.3.2. Classification

ID Device Name Superset Class Scope

0x0012

OTA Requestor

Utility

Node

2.3.3. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

ClusterName Client/Server Quality Conformance

OTA Software Update Requestor

Server

M

OTA Software Update Provider

Client

M

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.2. Classification

ID Device Name Superset Class Scope

0x0014

OTA Provider

Utility

Node

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.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.

Each Bridged Device device type SHALL have one Bridged Node root endpoint on the endpoint representing the bridged device. If multiple endpoints are used for the bridged device, their endpoint numbers SHALL be listed in the PartsList attribute of the Descriptor cluster on this Bridged Node root endpoint.

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.2. Classification

ID Device Name Superset Class Scope

0x0013

Bridged Node

Simple

Endpoint

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

On/Off Light

0x0101

Dimmable Light

0x010C

Color Temperature Light

0x010D

Extended Color Light

smart plugs/outlets and other actuators

0x010A

On/Off Plug-in Unit

0x010B

Dimmable Plug-In Unit

0x0303

Pump

switches and controls

0x0103

On/Off Light Switch

0x0104

Dimmer Switch

0x0105

Color Dimmer Switch

0x0840

Control Bridge

0x0304

Pump Controller

0x000F

Generic Switch

sensors

0x0015

Contact Sensor

0x0106

Light Sensor

0x0107

Occupancy Sensor

0x0302

Temperature Sensor

0x0305

Pressure Sensor

0x0306

Flow Sensor

0x0307

Humidity Sensor

0x0850

On/Off Sensor

closures

0x000A

Door Lock

0x000B

Door Lock Controller

0x0202

Window Covering

0x0203

Window Covering Controller

HVAC

0x0300

Heating/Cooling Unit

0x0301

Thermostat

0x002B

Fan

media

0x0028

Basic Video Player

0x0023

Casting Video Player

0x0022

Speaker

0x0024

Content App

0x0029

Casting Video Client

0x002A

Video Remote Control

generic

0x0027

Mode Select

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.2. Classification

ID Device Name Superset Class Scope

0x0100

On/Off Light

Simple

Endpoint

4.1.3. Conditions

Please see the Base Device Type definition for conformance tags.

4.1.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 1. On/Off Light Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

4.2.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 2. Dimmable Light Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

4.3.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 3. Color Temperature Light Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

4.4.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 4. Extended Color Light Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

5.1.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 5. On/Off Plug-in Unit Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

5.2.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 6. Dimmable Plug-In Unit Cluster Requirements
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.2. Classification

ID Device name Superset Class Scope

0x0303

Pump

Simple

Endpoint

5.3.3. Conditions

Please see the Base Device Type definition for conformance tags.

5.3.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 7. Pump Cluster Requirements
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.

Table 8. Pump Actions on Receipt for On/Off Commands
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.

Table 9. Relationship between Level and Setpoint
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

6.1.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 10. On/Off Light Switch Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

6.2.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 11. Dimmer Switch Cluster Requirements
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.3. Conditions

Please see the Base Device Type definition for conformance tags.

6.3.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 12. Color Dimmer Switch Cluster Requirements
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.2. Classification

ID Device Name Superset Class Scope

0x0840

Control Bridge

Simple

Endpoint

6.4.3. Conditions

Please see the Base Device Type definition for conformance tags.

6.4.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 13. Control Bridge Cluster Requirements
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.2. Classification

ID Device name Superset Class Scope

0x0304

Pump Controller

Simple

Endpoint

6.5.3. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 14. Pump Controller Cluster Requirements
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.2. Classification

ID Device Name Superset Class Scope

0x000F

Generic Switch

Simple

Endpoint

6.6.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.2. Classification

ID Device Name Superset Class Scope

0x0015

Contact Sensor

Simple

Endpoint

7.1.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.2. Classification

ID Device Name Superset Class Scope

0x0106

Light Sensor

Simple

Endpoint

7.2.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.2.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 15. Light Sensor Cluster Requirements
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.2. Classification

ID Device Name Superset Class Scope

0x0107

Occupancy Sensor

Simple

Endpoint

7.3.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.3.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 16. Occupancy Sensor Cluster Requirements
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.4.2. Classification

ID Device Name Superset Class Scope

0x0302

Temperature Sensor

Simple

Endpoint

7.4.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.4.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

0x0402

Temperature Measurement

Server

M

0x0003

Identify

Server

M

0x0004

Groups

Client

[Zigbee]

7.4.5. Element Requirements

This device type does not override any cluster specification requirements.

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.2. Classification

ID Device name Superset Class Scope

0x0305

Pressure Sensor

Simple

Endpoint

7.5.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.5.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 17. Pressure Sensor Cluster Requirements
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.2. Classification

ID Device name Superset Class Scope

0x0306

Flow Sensor

Simple

Endpoint

7.6.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.6.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 18. Flow Sensor Cluster Requirements
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.2. Classification

ID Device Name Superset Class Scope

0x0307

Humidity Sensor

Simple

Endpoint

7.7.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.2. Classification

ID Device Name Superset Class Scope

0x0850

On/Off Sensor

Simple

Endpoint

7.8.3. Conditions

Please see the Base Device Type definition for conformance tags.

7.8.4. Cluster Requirements

Each endpoint supporting this device type SHALL include these clusters based on the conformance defined below.

Table 19. On/Off Sensor Cluster Requirements
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.2. Classification

ID Device Name Superset Class Scope

0x000A

Door Lock

Simple

Endpoint

8.1.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.

Table 20. Door Lock Controller 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.2. Classification

ID Device Name Superset Class Scope

0x0202

Window Covering

Simple

Endpoint

8.3.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.2. Classification

ID Device Name Superset Class Scope

0x0301

Thermostat

Simple

Endpoint

9.2.3. Conditions

Please see the Base Device Type definition for conformance tags.

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

9.3.2. Classification

ID Device Name Superset Class Scope

0x002B

Fan

Simple

Endpoint

9.3.3. Conditions

Please see the Base Device Type definition for conformance tags.

9.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

0x0003

Identify

server

M

0x0004

Groups

server

M

0x0202

Fan Control

server

M

9.3.5. Element Requirements

Below list qualities and conformance that override the cluster specification requirements. A blank entry means no change.

ID Cluster Element Name Quality Constraint Access Conformance

0

Identify

Feature

Query

!Matter

1

FanControl

attribute

FanModeSequence

F

R VO

Matter

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.

VideoPlayerDeviceTypes
Figure 1. Video Player Device Types

10.1.2. Clients of a Casting Video Player

The clients for a Video Player device can be categorized into 2 high-level groups.

  1. Clients controlling the Video Player endpoint such as a remote control (eg : Video Remote device type)

  2. 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:

MediaPlayerEndpointComposition
Figure 2. Endpoint Composition for Video Player Device

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.

  1. 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.

  2. 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.

  3. 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:

  1. Media Input cluster (when CurrentInput does NOT have type INTERNAL, then Video Player is displaying content from a physical input)

  2. Application Launcher cluster (CurrentApp indicates the current application endpoint - which may be the Video Player endpoint when no Content App is in the foreground).

  3. 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.6.9. Keypad Navigation

This feature controls on-screen navigation, commonly referred to as D-Pad navigation, and includes navigation commands such as UP, DOWN, LEFT, RIGHT, SELECT, BACK, EXIT, MENU.

The Keypad Input cluster SHALL be used for this functionality.

10.1.6.10. Account Login

This cluster provides commands that facilitate user account login on an application or a node.

The Account Login cluster SHALL be used for this functionality.

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.3.5. Element Requirements

Below list qualities and conformance that override the cluster specification requirements. A blank entry means no change.

Cluster Element Name Quality Access Conformance

Application Launcher

Feature

Application Platform (AP)

M

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.4.2. Classification

ID Device Name Superset Class Scope

0x0022

Speaker

Simple

Endpoint

10.4.3. Conditions

Please see the Base Device Type definition for conformance tags.

10.4.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

0x0008

Level

Server

M

10.4.5. Element Requirements

This device type does not override any cluster specification requirements.

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.2. Classification

ID Device Name Superset Class Scope

0x0024

Content App

Simple

Endpoint

10.5.3. Conditions

Please see the Base Device Type definition for conformance tags.

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.5.5. Element Requirements

Below list qualities and conformance that override the cluster specification requirements. A blank entry means no change.

Cluster Element Name Quality Access Conformance

Application Launcher

Feature

Application Platform (AP)

Shall NOT implement AP feature.

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

11.1.2. Classification

ID Device Name Superset Class Scope

0x0027

Mode Select

Simple

Endpoint

11.1.3. Conditions

Please see the Base Device Type definition for conformance tags.

11.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

0x0050

Mode Select

Server

M

11.1.5. Element Requirements

This device type does not override any cluster specification requirements.