Zigbee, Thread & Matter · Study deck

Zigbee Application Profiles

Imagine a wall switch from one firm must control a lamp from another firm through a shared hub.

Radio Remi is your guide for this deck.

zigbeeprofilesclusters

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Separate Zigbee network join evidence from application-profile compatibility evidence.
Review device types, endpoints, clusters, commands, and attributes as interoperability claims.
Identify when a gateway translation path is part of the release claim.
Evaluate mixed legacy and Zigbee 3.0-style deployments without overclaiming universal compatibility.

Major section

A Clear First Route

The team must decide whether both devices give the same meaning to the same action.

Zigbee is a low-power wireless system for nearby devices.
A gateway is a device or service that links one network or system to another.
This page starts with one job.
This first route is a guide to the main choice.

Major section

A Clear First Route (continued)

Last, choose accept the match, add a known bridge, or reject the claim.

A route can move a message even when the two ends do not agree on what it means.
The Practitioner sections add profile records, end points, clusters, binding, and mixed-device cases.
They do not reverse its main claim.

Major section

A Clear First Route (continued)

Under the Hood adds unified behaviour, old profile limits, bridge loss, and version drift.

If two sources differ, keep that fact in the record.
A late result may be true about the past and still be unsafe now.
A missing result is also useful news when the system shows it at once.

Major section

In 60 Seconds

Zigbee application profiles and the Zigbee Cluster Library define what a device means after it has joined the network.

A routing path proves that packets can move.
Application-profile review asks whether the device type, endpoint, cluster, command, attribute, binding, and gateway behavior all support the release claim.
A mixed legacy deployment can work when a coordinator or gateway translates behavior, but that translation must be reviewed as evidence, not assumed.

Major section

Profiles, Clusters, and Endpoints

Application profile names the application domain and compatibility rules being used for the device behavior.

Endpoint is the addressable application surface on a device.
One physical product may expose more than one endpoint.
Binding records a persistent relationship between a source cluster and a destination endpoint or group.
Attributes hold state; commands request actions.

Zigbee Alliance standardized public application profiles, each pairing a profile ID with an application domain such as Home Automation (0x0104).

Major section

Profiles, Clusters, and Endpoints (continued)

The review should connect all of these pieces to the release claim.

A device can be joined, reachable, and secure while still failing the application profile contract.
At the application layer, the nesting is endpoint, cluster, then attribute or command.
An endpoint, typically numbered from 1 to 240, is an addressable application surface on a device.

Major section

Legacy Profile Evidence

Legacy profiles are not automatically wrong.

The review needs to know whether the command works directly, through binding, through a group, through a scene, or through a gateway rule.

Zigbee legacy public profiles flow through clusters and endpoints toward Zigbee 3.0 unification, beside a separate WirelessHART industrial boundary.

Major section

Zigbee 3.0 and Unified Behavior Evidence

Zigbee 3.0-style interoperability review should still be evidence-based.

Certification labels and version names are useful starting points.
The main interoperability change is that Zigbee 3.0 unified what earlier deployments split across profile ecosystems.
Legacy Home Automation and Zigbee Light Link devices shared the radio and network stack, but commissioning, security, and application assumptions could still diverge enough to require a translating hub.

Major section

Binding and Gateway Evidence

Many interoperability failures are not cluster-definition failures.

Clusters have client and server sides.
The server side holds attributes and executes commands: a light's On/Off server holds the on/off state.
The client side sends commands: a switch's On/Off client sends On, Off, or Toggle.

Major section

Binding and Gateway Evidence (continued)

Binding connects a source client cluster on one endpoint to a matching server cluster on another endpoint or group, so a shared cluster ID is not enough if the roles are wrong.

Cross-vendor portability depends on standard clusters as well as matching roles.
A product can work in its vendor app by using manufacturer-specific clusters or non-standard attributes, then fail when a generic hub tries to bind it through standard On/Off, Level Control, or measurement behavior.
The review should separate "works through vendor logic" from "works through the standard cluster path.".

Major section

Concept Relationships

Zigbee protocol-stack evidence explains where application profiles sit above the APS and network layers.

Network-formation evidence proves joining and commissioning before application behavior is reviewed.
Zigbee security evidence explains how trust-center and key evidence interacts with profile behavior.
Common-mistakes review shows how profile assumptions become field failures.

Deck summary

Key takeaways

The team must decide whether both devices give the same meaning to the same action.

Last, choose accept the match, add a known bridge, or reject the claim.
Under the Hood adds unified behaviour, old profile limits, bridge loss, and version drift.
Zigbee application profiles and the Zigbee Cluster Library define what a device means after it has joined the network.
Application profile names the application domain and compatibility rules being used for the device behavior.

Retrieval practice

Recall check 1 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q1A Zigbee device has joined the network and its packets route correctly. What has that NOT yet proven?

AThat it shares the same application profile and cluster contract as the controller

BThat the radio can carry packets between the device and coordinator

CThat the device has been assigned a working network address

DThat the coordinator can currently see the device on the mesh

Show answer

Answer: A A working route proves packets move, not that the device shares the same application profile and cluster contract.

Retrieval practice

Recall check 2 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q2In the Zigbee application model, what is the relationship between endpoints, clusters, and attributes?

AAn endpoint hosts clusters, and each cluster contains attributes and commands.

BA cluster hosts endpoints, and each endpoint contains exactly one attribute.

CAn attribute hosts clusters, and clusters assign endpoints after joining.

DEndpoints and clusters are interchangeable names for the same application object.

Show answer

Answer: A Zigbee application evidence is endpoint, cluster, then attribute or command.

Retrieval practice

Recall check 3 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q3Why do Zigbee 3.0 certified devices generally interoperate more reliably than mixed legacy profile devices?

AZigbee 3.0 unified legacy profile behavior under a common application and security model.

BZigbee 3.0 added 802.15.4 radios, while legacy Light Link and Home Automation devices lacked radios.

CZigbee 3.0 removed clusters and endpoints, replacing them with one flat command list.

DZigbee 3.0 requires every device to support every possible command in the cluster library.

Show answer

Answer: A Zigbee 3.0 reduced legacy profile fragmentation, but compatibility still requires endpoint and cluster evidence.

Retrieval practice

Recall check 4 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q4A third-party switch and light both expose the On/Off cluster but direct binding fails. What role evidence should be checked first?

AThe switch has the On/Off client side and the light has the On/Off server side.

BBoth devices expose the On/Off server side because binding joins two state holders.

CThe devices share the same IEEE address because binding requires one common address.

DThe light exposes Level Control instead of On/Off because cluster IDs must differ.

Show answer

Answer: A Binding requires a source client cluster and matching destination server cluster; standard clusters support portable cross-vendor evidence.

Retrieval practice

Recall check 5 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q5A Zigbee switch and a Zigbee light are both joined to the same network. The switch can be seen by the coordinator, but direct control of the light fails unless the gateway rule is running. What is the strongest review conclusion?

AApprove direct device compatibility because both devices joined the same Zigbee network.

BApprove only a gateway-mediated claim and keep direct binding compatibility open.

CReject the network join result because the gateway rule may hide a weak radio link.

DReplace the light first because the switch is visible and its commands work through the gateway.

Show answer

Answer: B The observed behavior depends on the gateway translation path, so the approval scope must say that.

Retrieval practice

Recall check 6 of 6

Radio Remi says: answer from memory, then check your reasoning.

Q6A multi-endpoint Zigbee device reports one endpoint for a light and another endpoint for a power measurement feature. A controller command reaches the device but changes the wrong behavior. What should the review focus on first?

ARadio range, because the command reached the wrong feature only after crossing the network.

BEndpoint, device type, and cluster mapping for the command being approved.

CBattery replacement, because multi-endpoint behavior is caused by low power.

DCloud account permissions, because the controller may expose the device through a cloud integration.

Show answer

Answer: B Multi-endpoint devices require evidence that the controller targets the intended application surface.

Print reference

Answers 1 of 2

Answer key.

A · A working route proves packets move, not that the device shares the same application profile and cluster contract.
A · Zigbee application evidence is endpoint, cluster, then attribute or command.
A · Zigbee 3.0 reduced legacy profile fragmentation, but compatibility still requires endpoint and cluster evidence.
A · Binding requires a source client cluster and matching destination server cluster; standard clusters support portable cross-vendor evidence.
B · The observed behavior depends on the gateway translation path, so the approval scope must say that.

Print reference

Answers 2 of 2

Answer key.

B · Multi-endpoint devices require evidence that the controller targets the intended application surface.