This page will help you become familiar with basic Zigbee concepts and serve as reference material if you would like take a more in-depth look into a specific topic.

What is Zigbee?

Zigbee is a standards-based wireless protocol designed to address the unique needs of low-cost, low-power wireless sensor and control networks. Zigbee also connects the widest variety of devices into easy-to-use networks, giving you unprecedented control of the devices you use everyday at home, work or even play. For more information please visit the Zigbee Alliance website at Zigbee.org.

Zigbee devices communicate with distant nodes by routing data through a mesh network of intermediaries. Zigbee is typically used in low-data rate applications (e.g. not exceeding 250kbps) that require long battery life and secure networking.

Zigbee Stacks

The Zigbee stack is the native code operating on any Zigbee silicon. The stack includes the MAC and PHY hardware control layer, as well facilities for Network Security and the Application Framework.

The Zigbee stack does not include the Application Layer, which implements support for a given Zigbee Application Profile like Smart Energy or Home Automation; that is, the functional logic of a Zigbee device.

Adopters are expected to leverage the complex interface to the Zigbee stack (i.e. the Application Framework) to create their own Application Layer and to independently integrate network and device functionality.

Zigbee provides several separate stacks. This has been a point of confusion so the summary is as follows:

Zigbee 2004 – was released in 2004 and supported a home control lighting profile. This stack was never extensively de- ployed with customers and is no longer supported.
Zigbee 2006 – was released in 2006 and supports a single stack known as the Zigbee stack (explained below)

Zigbee 2007 – was released in Q4 2007. It has two feature sets, Zigbee and Zigbee PRO.

The Zigbee PRO stack is formed around a central coordinator but uses a stochastic addressing scheme to avoid limitations with the tree.

It has additional features such as:

Network level multicasts
Many-to-one and source routing
Frequency agility
Asymmetric link handling
PAN ID Conflict
Fragmentation
Standard or high security.

Architecture

On This Page

In This Space

Related Content

Filter by label

There are no items with the selected labels at this time.

Zigbee Profiles

Many of the MMB products use pre-Zigbee 3.0 specifications,as such application profiles, or simply profiles, sat on top of the basic Zigbee stack. These were developed to specify the OTA messages required for device interoperability. A given application profile could be certified on either the Zigbee or Zigbee PRO stack. MMB is in the process of adapting the Zigbee 3.0 standard which introduced an all-encompassing application layer specification for defining OTA behavior for all Zigbee applications.

The following application profile groups exist:

Home Automation (HA) – Devices for typical residential and small commercial installations.
Smart Energy (SE) – For utility meter reading and interaction with household devices.
Commercial Building Automation (CBA) – Devices for large commercial buildings and networks.
Telecom Application (TA) – Wireless applications within the telecom area.
Health Care (HC) – Monitoring of personal health in the home or hospital environment.
Retail – Monitoring and information delivery in a retail environment.
Zigbee Light Link – Wireless control of LED lighting systems.

MMB offers RapidHA, RapidSE and RapidConnect which are fully-featured, configurable Zigbee applications with support for HA 1.2, SE and similar profiles, designed for Rapid Integration into existing devices.

The Zigbee Cluster Library (ZCL) forms a generic basis for the Zigbee common application layer. This library defines common elements that are shared such as data types and allows reuse of simple devices such as on/off switch protocols between different profiles.

Application Profiles

Application Profiles are an agreement - a set of rules - that define how devices belonging to a profile should behave. Profiles are designed to ensure a certain level of interoperability between devices belonging to a profile, even if those devices are made by different manufacturers. An example of an Application Profile is the Home Automation (HA) profile. Imagine a light switch made by manufacturer A and a light made by manufacturer B. If they both implement the HA profile, then they are guaranteed to have a certain level of interoperability between them (i.e. the switch can turn the light on/off, etc.).

Application Profiles implement their functionality by defining devices and the data that each device can produce or consume. Devices are defined by device descriptors. For example, in the HA profile there are device descriptors for switches, dimmers, occupancy sensors, light sensors, etc. Each descriptor has a corresponding Device ID, which is used to identify devices on the network. A full list of HA Profile device descriptors can be found here.

There are profiles for smart energy, building automation, health care, industrial control, security, as well as custom profiles made by manufacturers for their own product lines.

Clusters and Attributes

The individual pieces of data that devices can produce/consume are called attributes. Attributes, and their possible values and types (i.e. integer, time, etc.) are defined as part of the device descriptors. Attributes are grouped into Clusters.

An example of an attribute is the OnOff attribute, whose values represent the action to be performed (i.e. On, Off, Toggle). Attributes are grouped into Clusters, with each cluster having its own unique identifier. Clusters can contain many attributes, that for example, can each represent information like the state of the device (on or off), the total length of time a device has been on, the total power consumed, the voltage applied to the load, and much more.

A More Detailed description of Clusters an dAttributes can be found below.

Relation to Application Profiles

The Application Profile defines which clusters are mandatory and which clusters are optional for the device. The clusters supported by a device determine the other devices with which it can communicate. For example, for two devices to operate together in temperature monitoring and control, the two devices must support compatible clusters concerned with temperature. The sensor device must have an output cluster containing the monitored temperature, and the controller must support an input cluster which can use a temperature to make control decisions.

Endpoints

Each device on the network can run applications. A single node on the network may run many applications. For example, an environmental sensor may run separate applications to measure temperature, humidity, and atmospheric pressure. Applications essentially convert digital data into output, and/or convert input into digital data. These applications instances on the network node are called Endpoints, and all messages (messages contain data from attributes) either originate or terminate at endpoints. Endpoints communicate with each other through the exchange of clusters and attributes. Endpoints on a single network node are uniquely identified by a number between 1 and 240. Therefore, to identify a particular application instance (endpoint) on a Zigbee network, you need the network address of the node and the endpoint address (1-240) of the application on that node.

Note: Zigbee Device Objects (ZDO) is a special endpoint with address 0. Every node has one ZDO at address 0. The ZDO is responsible for defining the type of the node on the network (Coordinator, Router, End Device), and the network management of the node (forming/joining/leaving, etc).

Summary

To summarize, Application Profiles define a set of devices, along with their clusters and attributes, which define the mandatory pieces of data that each device must be able to produce or consume. Application profiles are designed to guarantee a level of interoperability between devices that implement the profile.

Devices can run many different applications, such as applications for measuring temperature, humidity, or light. Application instances are called Endpoints. Endpoints contain clusters, which contain attributes. Attributes define the data types and values that the endpoint can produce or consume. Endpoints are the source and destination for messages containing attribute data.

Zigbee Cluster Library

A cluster is a set of messages used to send and receive related commands and data over Zigbee. For example a temperature cluster would contain all the necessary OTA messages required to send and receive information about temperature. Another way of seeing a Cluster is a way to define an interface to specific functionality.

The Zigbee common application layer then references which clusters are used within certain applications, and specifies which clusters are supported by different devices–some clusters are mandatory, others optional. In this way, the ZCL simplifies the documentation of a particular application and allows the developer to understand quickly which behaviors devices support.

The ZCL employs the Client / Server model throughout.

Each cluster is divided into two ends, a client end and a server end. The client end of a cluster sends messages that may be received by the server end. The client end may also receive messages that are sent by the server end. In this sense, the client and server ends of a cluster are always complementary. Typically the server a cluster stores the attributes of the cluster while the client of a cluster affects/manipulates those attributes.

Attributes

An attribute is data that is associated with a cluster end and the server / client ends of a cluster may each possess multiple attributes.

Each attribute declares the following:

16-bit identifier
A data type
A read-only or read/write designator
A default value
An indicator on whether it's supported by any implementation

The attribute identifier is unique only within the specific cluster end: this means that the attribute 0x0002 within the cluster server does not need to be the same as the attribute 0x0002 within the cluster client, even within the same cluster.

NOTE: These attributes can be accessed over the air by using Attribute Commands.

There is also the notion of global attributes that are defined in every cluster instance on a device and function as normal ZCL attributes, for example Cluster Revision(attribute ID 0xFFFD).

An example of an attribute is the OnOff attribute, whose values represent the action to be performed (i.e. On, Off, Toggle). Attributes are grouped into Clusters, with each cluster having its own unique identifier. Clusters can contain many attributes, that for example, can each represent information like the state of the device (on or off), the total length of time a device has been on, the total power consumed, the voltage applied to the load, and much more.

The Application Profile defines which clusters are mandatory and which clusters are optional for the device. The clusters supported by a device determine the other devices with which it can communicate. For example, for two devices to operate together in temperature monitoring and control, the two devices must support compatible clusters concerned with temperature. The sensor device must have an output cluster containing the monitored temperature, and the controller must support an input cluster which can use a temperature to make control decisions.

Commands

Commands are composed of an 8-bit commands identifier and a payload format. Similar to Attributes, the identifier is unique only within the specific cluster end. Commands are used to interact with attributes such as read, write, discover attributes and report attributes. For example we could send a message from one cluster end containing a command for Read Attribute to another cluster end which will respond with a Read Attribute response. Commands that allow devices to affect values are typically send from a client device and are received by a server device. This is a similar principle to a client facing webpage taking user input and manipulating/retrieving data on the server side. The exception to this is the the attribute reporting command, which is typically send from the server device to the client device.

Since attributes are always tied to a cluster, the commands affecting attributes specify which cluster and which attributes are to be accessed or modified. Additionally, each cluster defines which attributes support which commands – for example, an attributes may be declared READ ONLY, in which case it will not support the Write Attributes command.

Next Section

You can now move on to Zigbee Network Concepts.

Browser not supported