ZigBee Device Compatibility, Application Profiles, Clusters, Endpoints, Bindings

    The main purpose of ZigBee networks is communication between devices in automated systems. Applications for ZigBee networks are diverse. The types and purpose of devices to be connected are also very diverse. Communication can be established between the switch and the lamp in the "smart home", metering devices and the server of the network service company, a motion sensor and a security panel. Perhaps, looking at this topic, you yourself, without suspecting it, use the ZigBee network - many wireless mice with a 2.4 GHz USB adapter comply with the ZigBee RF4CE specification.

    In this topic, we will focus on mechanisms regulated by the ZigBee specification that ensure the compatibility and interaction of automation devices (applications) through the ZigBee network.
    I wrote about the construction and operation of ZigBee networks in previous topics (you can also see here ).

    Very briefly about the hardware

    ZigBee compatible automation devices are usually delivered to the "builders" in the finished form. In the form of “smart” sockets and fixtures, various sensors, drives, measuring instruments, IP (Wi-Fi, USB, etc.) gateways, control panels, controllers and so on. However, fans working with a soldering iron can easily find ZigBee chips, and even special kits, to connect them to their own devices, thereby making these ZigBee devices compatible.
    From such products equipped with ZigBee devices, any automated system with wireless data transmission over the ZigBee network is built. How it is built depends on the tasks. To build a ZigBee network between the mouse and the system unit, just insert the adapter into the USB port and “feed” the mouse with a battery. Building an automation system for an intelligent building will require the efforts of a design organization.

    ZigBee Cluster Library (ZCL)

    When the hardware is designed, the moment of programming comes. And here the built-in mechanisms embedded in the ZigBee specification become a good help.

    One of the main goals of developing the ZigBee specification was to ensure compatibility between devices from different manufacturers. And this compatibility is ensured at the application level by using the ZigBee Cluster Library - ZigBee Cluster Library (ZCL).
    The cluster is similar to a class in object-oriented programming and includes:
    • a description of a standard device (lamp, dimmer, counter);
    • a description of the standard attributes of this device (on / off, brightness control, counter readings);
    • description of standard device commands (turn on / off, set brightness level, read readings).
    Each cluster consists of two elements connected through a network - a client and a server. The connection between cluster elements is established by the binding, which will be discussed below.

    The ZigBee server stores attribute values, and the ZigBee client remotely reads or writes the value of this attribute. For example, the standard “bulb” and “switch” devices can function as a standard “on / off” cluster. In this case, the “bulb” will be the server part of the cluster storing the value of the “on / off” attribute. And the “switch” (client) will remotely set the attribute value.
    A ZigBee device can simultaneously support several client parts of one cluster and server parts of others. For example, the “switch” may also contain the server part of the “configuration” cluster, with the help of which it will receive information about operating modes from the configuration device.

    ZigBee Cluster
    Library The ZCL library contains a rich set of standard clusters, which is constantly updated. For ease of use, clusters in the library are grouped by functional feature:
    • general purpose,
    • working with sensors,
    • lighting control,
    • ventilation control,
    • security management
    • etc.
    According to the ZigBee PRO Feature Set specification, messages are sent on ZigBee networks only using standard clusters.


    An application is, in fact, just what the ZigBee specification was created for. Applications implement communication channels between devices of automation systems and provide guaranteed and safe packet delivery. Each application is determined by its profile.

    An application profile is a set of settings for network nodes (ZigBee devices) that ensures their joint operation. The profile specification defines methods for setting identification parameters, network formation modes, data protection methods, a list of used clusters, endpoints, bindings, etc. A profile may include clusters from different functional groups of the library.
    To uniquely identify applications, each application is assigned a profile identifier.

    End pointdetermines through which application object from the available ZigBee device this application is implemented.
    For example, in the remote control, you can select the endpoint 10 for controlling the lighting in the hallway, the endpoint 25 for controlling multimedia, and the endpoint 50 for controlling the heating. As a result, the remote control will be able to establish independent communication with the relevant devices and distinguish between packages designed for each application and each device.
    Each ZigBee device has 240 application objects, which allows you to create up to 240 endpoints - from the first to the 240th. Zero object - a ZigBee device object (ZD0) that provides control of the device itself.

    The binding programs the connection between endpoints — it contains device addresses and endpoints of the client and server of a specific cluster. Each binding supports a corresponding application profile, and each message type is determined by the cluster in that profile.
    Bindings are created both between individual endpoints, and between their groups, which have the same cluster identifier, for example, between lights and switches.
    The binding can be direct (“source binding”). At the same time, device addresses and endpoint identifiers of all applications with which interaction is programmed are stored in the source device.
    With indirect binding, this information can be stored in a device dedicated to these purposes, which supports a lookup table that correlates all the endpoints of sources and recipients.

    Also popular now: