Zigbee is a wireless communication standard that extends the IEEE 802.15.4 standard, it uses 2 different frequencies (2.4GHz, 869-915MHz), and is very similar to Z-Wave.
Introduction to Zigbee
Endpoints and Clusters
A Zigbee device is made up of one or more endpoints, these are collections of clusters. A cluster is essentially a capability of a Zigbee device.
A cluster can be implemented in two ways:
- As server
- As client
From the Zigbee Cluster Specification "Typically, the entity that stores the attributes of a cluster is referred to as the server of that cluster and an entity that affects or manipulates those attributes is referred to as the client of that cluster." More information on this can be found in the Zigbee Cluster Specification section 2.2.2.
Commands and Attributes
Every cluster supports a set of commands and attributes. Attributes are properties of the cluster which can be read, written to and reported to any other bound node. An example would be the "current level" attribute implemented by the "level control" cluster, it represents the value of the current level of the device. The cluster may also support commands which are used to perform actions. An example would be the "move to level" command implemented by the "level control" cluster which makes the cluster change its current level to the level set by the command.
Commands can be sent in two directions:
- from client to server
- from server to client
The first is probably the most common direction, for example when sending a command from Homey (the client) to a bulb (the server) using the "onOff" cluster and the "toggle" command. The second is when a node (the server) sends a command to Homey (the client), for example a remote which sends the "toggle" command from the "onOff" cluster to Homey to indicate that the toggle button was pressed.
A cluster can report attributes, this means it will send a message to any bound node whenever the value of the attribute changes. Not all attributes are reportable, check the Zigbee Cluster Specification for the specifics of each attribute. In order to make a cluster report an attribute, a binding must be created between the reporting and receiving node.
Bindings and Bound Clusters
The difference between server and client clusters is important for the following reason. Nodes can be receivers of commands (i.e. servers), or senders of commands (i.e. clients), and sometimes both. Receiving commands from a node most often requires a binding to be made from the controller (in this case Homey) to the cluster on the node, as well as an implementation of
BoundCluster to receive and handle the incoming commands in your app. For more information on implementing a
BoundCluster read Interacting with Zigbee devices.
Zigbee allows another way of inter-node communication which is called groups. This concept can be compared to association groups in Z-Wave. It allows nodes to listen to broadcast messages from other nodes. For example, a remote control which broadcasts its commands to a set of light bulbs. The light bulbs would need to be in the same group as the remote is broadcasting on in order to be controlled with the remote. In order to group devices together the Find and Bind procedure can be used, often this means holding the controlling device close to the receiving device and initiating a commissioning process (how to initiate this process differs from device to device, check the device's manual for these instructions).
By default, Homey listens to all group broadcast communication on its network. Therefore, it does not have to be added to a node's group using Find and Bind in order to receive its commands. This makes it very easy to implement functionality based on group communication in your app.
Example structure of a Zigbee Node
Routers, End Devices and SEDs
There are a couple of different types of Zigbee devices:
- Routers: these are nodes on the network that are capable of routing messages between devices. Usually these are the non-battery powered devices. They extend the range of the Zigbee mesh network.
- End Devices: these are nodes on the network that are not capable of routing messages between devices. Usually these are battery powered devices. They do not extend the range of the Zigbee mesh network.
An important concept in Zigbee is Sleepy End Device (SED). SEDs are End Devices which are asleep most of the time, they only wake up to poll their parent (the Router they are paired to) for new messages every once in a while. A Router can keep track of a couple of messages targeted at the SED while it is asleep, so that the SED can retrieve these messages from the Router when it awakens.
When communicating with SEDs it is important to consider the possibility that it may not respond any time soon, or not at all. Most devices remain awake for a short amount of time directly after pairing, this is therefore the only time you can reliably communicate with the node. Additionally, since the Router has to store the messages for the SED, and the SED wakes up on a variable interval and fetches a single message every time, it is advised to only perform one request at a time for the most reliable communication.
Zigbee Cluster Specification
The full Zigbee Cluster Specification can be found at Zigbee Cluster Specification (PDF). This contains all information on clusters, commands and attributes you would need to create a driver for a Zigbee device.
- Continue reading on how to create a driver for a Zigbee device in Creating a Zigbee Driver.
- Dive into Homey's Zigbee API, and the various libraries we have created in Interacting with Zigbee devices.