ZigBee applications - Part 6: Profiles

Every endpoint includes a profile identifier and a device identifier. Think of a device as a physical thing: a light, temperature sensor, thermostat, or the like. One physical widget might contain multiple devices. For example, a ZigBee thermostat sold at Home Depot may contain a temperature sensor, a thermostat, and a heating/cooling unit controller. From ZigBee's standpoint, these are separate devices. From a packaging standpoint, they are all in one SKU (Shelf-Keeping Unit).

ZigBee Device IDs range from 0x0000 to 0xffff. A short list of device IDs available in the Home Automation Profile are shown in Table 4.11.

Device IDs serve two purposes:

• To allow human-readable displays (your PC, the TV, etc.) to show a proper icon for the device in question.
• To allow ZigBee commissioning tools to be more intelligent.

For example, consider an On/Off Light and a Mains Power Outlet (or switchable outlet, as they are called in some homes). Both devices are identical in the way they are controlled and monitored over-the-air. They both use cluster 0x0006, the OnOff Cluster. But users expect to see an outlet in a commissioning tool when they are connecting a switch to that outlet, and they expect to see a light when they are connecting a switch to that light.

Keep in mind that ZigBee does not specify the human interface to devices. A switch might be a push button, a rocker switch, an e-field sensor plate, accelerometer, or anything else the manufacturer can imagine.

Each ZigBee Public Profile contains a specific list of devices. Manufacturers are welcome to extend that list with their own devices, provided that they use the "Manufacturer Specific Extension" field provided as part of the ZigBee Cluster Library interface. Or they can make a device on another (MSP) profile that can interact with specific public profile devices, by using the existing device IDs and clusters.

4.6.4 The Simple Descriptor
The simple descriptor ties everything together on an endpoint, and an endpoint defines an application. Why the simple descriptor is not simply called an endpoint descriptor, I don't know.

The simple descriptor contains many of the fields I've been describing: an endpoint ID, a profile ID, cluster IDs, and a device ID. Its format is as follows:

typedef struct zbSimpleDescriptor_tag
{
    zbEndPoint_t endPoint;
    zbProfileId_t aAppProfId;
    zbDeviceId_t aAppDeviceId;
    uint8_t appDevVerAndFlag;
    zbCounter_t appNumInClusters;
    uint8_t *pAppInClusterList;
    zbCounter_t appNumOutClusters;
    uint8_t *pAppOutClusterList;
} zbSimpleDescriptor_t;

The simple descriptor of any endpoint can be retrieved over-the-air with the ZDP command Simple_Desc_req, and is used when performing service discovery (which I'll describe in detail in the next chapter).

The simple descriptor does not list the commands and/or attributes available on any given cluster. It is expected that a device "just knows" the capabilities of the cluster, if, say, the OnOff Cluster is supported on this endpoint. As a protocol for 8-bit devices (at least at the low end), ZigBee attempts to balance flexibility with implementation size.

Within any given device, some clusters are mandatory, and some may be optional. By asking for the simple descriptor, any device in the network can determine which clusters are supported by any other device, and can then make an informed decision about optional functionality. The response to a Simple_Desc_req is mandatory in all devices.

You'll notice there is both an input and output cluster list in the simple descriptor. This is how ZigBee determines which devices match. If one side has an output cluster (say a dimmer switch) and the other side has the same cluster as an input cluster (say, a dimming light), then they match. Any overlap indicates a match, so if an application is looking for a particular cluster, it can send a "simplified" simple descriptor to match just that one cluster.

Coming up in part 7: ZigBee security and the Application Support Sublayer.

Printed with permission from Newnes, a division of Elsevier. Copyright 2008. "ZigBee Wireless Networking" by Drew Gislason. For more information about this title and other similar books, please visit www.elsevierdirect.com.

Related links:
ZigBee applications - Part 1: Sending and receiving data | Part 2: No common C API | Part 3: ZigBee PANs | Part 4: ZigBee addressing | Part 5: Addressing within the node
Picking the right technologies for your home network design
ZigBee RF4CE coexistence with common 2.4-GHz ISM-band consumer electronics
Optimization of battery power for ZigBee wireless nodes
Ad hoc networking: ready when you are
Practical Embedded Security - Part 3: Wireless technologies