The ZigBee Cluster Library (ZCL) is a repository for cluster functionality created by the ZigBee Alliance. Any developer building a new device application should use the ZCL to find relevant cluster functionality that can be reused and extended if necessary.

The ZCL Specification consists of the ZCL Foundation, a set of elements that apply across the entire library (such as frame structures, attribute access commands and data types), and a number of sets of clusters.

Clusters that are generally useful across many application domains are included in the General set. Clusters that are intended for use mainly in specific application domains are grouped together in domain-oriented sets.

For more information, pelase refer to the the ZigBee Cluster Library Specification available from the ZigBee Alliance.

Definitions:

• Cluster - a set of attributes and commands, which are related and together define a communication interface between two devices.
• Client** - in general case this is an output interface of the cluster, which sends commands manipulating attributes of the corresponding server side of the cluster.
• Server** - in general case this is an input interface of the cluster holding all or the most of the cluster attributes.
• Profile - a contract between devices in agreement to operate together in a ZigBee network. This may include security restrictions, commissioning rules, or functional requirements.
• Functional Domains - clusters are divided into a number of functional domains, each domain addressing clusters to a specific functionality.

** In some cases however these roles are swapped (e.g. Smart Energy - Load Control, Home Automation - Power Profile), the most common scenario is when the server-side of a cluster sends output notifications to the client about changes of its attributes.

Constrains and Rules

There are a few constraints and rules according to the ZigBee ZCL Specifications which must be kept in mind when describing ZCL clusters and profiles with ZCL Metadata:

• Each cluster has an ID and a revision. For public clusters the ID is unique in the scope of the ZCL Specification. The revision is the specification version of the cluster.
• A cluster can be provided (defined) by the ZigBee Cluster Library (ZCL) or by a manufacturer.
• Manufacturer extensions include: brand new clusters, added attributes or commands to an existing cluster.
• A cluster extension provided by a particular manufacturer is denoted with its manufacturer-ID.
• A cluster is uniquely identified by its ID, revision, and optionally the manufacturer-ID.
• Each profile has a unique ID. Both public and proprietary profiles are assigned IDs by the Zigbee Alliance to avoid overlapping.

Supported Profiles and Clusters

The ZigBee Module provides extensions to the built-in ZCL metadata for the following sets of clusters and profiles:

• Clusters of the Home Automation (HA) 1.2 profile.
• Clusters of the Smart Energy (SE) 1.x profile.
• Clusters of the Light Link (LL) 1.0 profile.
• Clusters of the functional domains from the ZCL specification, i.e. of the "HVAC", "Closure", "Lighting", "Security and Safety", and "Sensing & Measurement" domains. To add metadata for one of the domains install the relevant bundle (see "ZCL Metadata Bundles").

Cluster Inheritance

Before Zigbee 3.0 and Bosch Gateway Software SDK 9.2 it was possible to have only one version of cluster description obtainable by its ID. In Zigbee 3.0, ZCL R6 Cluster revisions were introduced. Each cluster description is assigned a revision - the one of the specification that it is defined in.

Another form of cluster variation is by deriving one cluster from another. An example is the Level Control cluster. There is a base Level Control Cluster with id 0x0008, Level Control for Lighting - a derived cluster with the same ID but with changes in the specification and Pulse Width Modulation with id 0x001c derived from base 0x0008.

In both cases - introducing a new cluster revision or derived cluster, the changes can vary: this might be adding a new attribute or command, changed description, removed functionality. Overall a great part of the cluster definition of the parent stays the same in the new revision or derived version.

The XML representation aligns with this idea. In the case of a new revision the parent cluster can be pointed by specifying its revision. In the case of a base-derived relationship the base cluster ID and its revision can be specified.