A ZigBee 3.0 logo certifies that a device speaks the common application language. It does not certify that the device will expose every function to every hub, nor that automations written on one vendor's gateway will survive a move to another. Buyers who read "3.0" as "universal" usually discover the gap after the first mixed-brand order arrives.
What the certification actually covers
ZigBee 3.0 unified the application layer that earlier profiles split apart. Before 3.0, a lamp spoke ZLL, a switch spoke ZHA, and the two could not reliably share one network. The 3.0 specification merged those into a single set of clusters and device types, so a certified switch can send an on/off command to a certified lamp and the lamp will obey it. That is a real achievement, and it is the honest meaning of the logo.
What it covers is the mandatory baseline: identify the device, describe its endpoints, read and write standard attributes, bind, report, and join or leave a network under the trust center's rules. It does not cover optional clusters, manufacturer-specific attributes, firmware update behaviour, scene storage, or where automation logic lives. Those are exactly the places where a mixed-brand installation stops behaving like a single system.
For the change from older ZigBee profiles to 3.0, and what stayed identical, see what ZigBee 3.0 actually changed.
Standard clusters are the floor, not the ceiling
A wall switch needs on/off and level control. Both are standard clusters. But the same physical product may also offer a configurable indicator LED, a relay power-on state, a touch sensitivity setting, a child lock, and a calibrated energy report. There is no standard cluster for "make the indicator breathe slowly when the light is off". Vendors implement these as manufacturer-specific attributes on a private cluster, keyed by their own manufacturer code.
A third-party hub can still pair the device. It will show an on/off switch, because that part is standard. The private settings will be invisible to it, or reachable only by replaying undocumented commands that the hub cannot generate. Nothing in the 3.0 logo obliges a vendor to publish those. From an integration standpoint the device is two products: a standards-compliant switch and a proprietary control surface that only the vendor's own app can drive.
Joining is a security decision made by the hub
Network entry is handled by the trust center, usually the gateway. It decides whether to accept a device, which link key to use, and whether to allow a particular install code. A certified device follows the procedure; it does not get to decide the policy. In practice this means a hub can refuse a device for reasons that have nothing to do with radio compatibility: an unrecognised manufacturer code, a device type the hub's interface has no tile for, or a firmware version the hub has not been tested against.
This is also why "can I add it" and "will it work" are different questions. Joining succeeds more often than full function does. When you audit a mixed installation, separate the two: count devices that joined, then count devices whose full feature set is reachable outside the vendor app.
Where automation actually lives
Most consumer ZigBee systems store scenes, schedules, and rules in the gateway or in the vendor cloud, not in the switches. The device reports an event; the gateway decides what to do. Move a switch to a different gateway and the switch still works locally, but every rule that referenced it has to be rebuilt. A binding, meaning a direct device-to-device link written into the switch, is the exception, and it is one of the few genuinely portable pieces of configuration.
Ask specifically which rules survive a gateway replacement. If the answer is "none, you re-create them in the app", budget that as installation labour, not as a software quirk. On a project with dozens of switches, that labour is the difference between a one-day commissioning and a week of callbacks.
Firmware and device identity are not part of the logo
Over-the-air updates are optional and vendor-defined. A hub may be able to update devices from its own brand and quietly ignore every other manufacturer's image. Device identity in the app, meaning the name, icon, room, and model string, often comes from a cloud-side product catalogue keyed by manufacturer and model ID, not from anything the device reports. A device that pairs but appears as an unknown model is a catalogue gap, not a radio fault.
For OEM and ODM projects this is the part that should be settled before tooling: who owns the cloud product entry, whether the model ID will be recognised by third-party gateways, and what happens to that entry when the commercial relationship ends. The OEM/ODM factory page describes the customisation tiers; the firmware identity question is separate from the mechanical ones and is usually discovered last.
What to put in the RFQ
Four questions separate a compatible device from a merely joinable one:
- Which standard clusters and attributes does the device expose, and which functions sit on manufacturer-specific clusters? Get the list in writing.
- Can a third-party gateway read the full state, including energy reports and configuration, or only on/off?
- Are scenes and schedules stored in the device, the gateway, or the cloud, and which of those survive a gateway swap?
- Who maintains the cloud product entry and the OTA image, and for how many years after the last shipment?
None of these are answered by a 3.0 logo. A multi-protocol gateway that the vendor has actually tested against is a more useful compatibility statement than a certification mark, because it names the specific pairing that was validated.
The broader comparison of how Tuya WiFi, Tuya ZigBee and Tuya Bluetooth divide these responsibilities is worth reading alongside this, since protocol choice and ecosystem choice are separate decisions that are often made as one.
If you are sourcing rather than installing, XingLiao Tech documents the manufacturing side of the same product families.
Top comments (0)