ZigBee Devices

This page provides an overview per manufacturer of the ZCL configuration of the ZigBee Devices connected to my Hue bridge, as reported by deCONZ. It lists the endpoints and clusters per device type. Server clusters are in boldface.

I joined my RaspBee to the ZigBee network created by my Hue bridge and, after that, these devices where discovered automatically by deCONZ.

TODO:

• Try and touch link a second Hue bridge to a Hue bridge;
• Try and touch link a Hue bridge to a Hue dimmer switch;

Philips

Hue Bridge

Here's the configuration for a second-generation Hue bridge (firmware version 01038390):

Endpoint	Profile	Cluster	Name
F2	ZGP		0061 unknown
		0021	ZigBee Green Power Proxy
40	ZLL		Control Bridge
		1000	ZLL Commissioning
		0019	OTAU
		1000	ZLL Commissioning
		0004	Groups
		0005	Scenes
		0000	Basic
		0300	Color Control
		0003	Identify
		0008	Level Control
		0006	On/Off
41	ZHA		Combined Interface
		000F	Binary Input (Basic)
		0406	Occupancy Sensing
		0402	Temperature Measurement
		0405	Humidify Measurement
		FC00	Vendor Specific
		0400	Illuminance Measurement

Notes:

• A first-generation Hue bridge (firmware version 01036659) looks the same, except for the order of the endpoints: 40, 41, F2 instead of F2, 40, 41.
• The ZGG endpoint matches the Hue lights and, I suspect, the Hue tap.
• The ZLL endpoint matches the Hue lights, except for the ZLL Commissioning server cluster. As mentioned in the Hue developer forum, it was possible to (touch?) link two Hue bridges, but the procedure seems to be lost.
• So the Hue bridge does talk ZHA?!
• The Hue motion sensor has corresponding server clusters for the ZHA 0406, 0402, and 0040 clients.
• The Hue dimmer switch has a corresponding server clusters for the ZHA 000F and FC00 clients. I suspect one of these to be used for buttonevent.
• When connecting a previously standalone dimmer switch to a Hue bridge (using the Hue app), the bridge can "inherit" the lights from the dimmer switch. Since the Hue dimmer switch lacks a ZLL Commissioning cluster, I suspect the 000F or FC00 might be used for this.
• I cannot find a matching server cluster for the ZHA 0405 client. Apparently Philips considered a ZigBee version of the CLIPHumidity sensor? However, there doesn't seem to be a ZigBee version of the CLIPOpenClose sensor (or is that covered by 000F)?

Hue Lights

Here's the configuration for a Hue Extended Color Light:

Endpoint	Profile	Cluster	Name
0B	ZLL		Extended Color Light
		0000	Basic
		0003	Identify
		0004	Groups
		0005	Scenes
		0006	On/Off
		0008	Level Control
		0300	Color Control
		1000	ZLL Commissioning
		0019	OTAU
F2	ZGP		0061 unknown
		0021	ZigBee Green Power Sink
		0021	ZigBee Green Power Proxy

Notes:

• A Hue Color Light and a Hue Color Temperature Lights have the same configuration. So does a Hue Dimmable Light, except that, of course, it misses the Color Control cluster.
• On the Hue bridge, the uniqueid attribute for a Hue light is 00:17:88:01:0x:xx:xx:xx-0b, matching the ZLL endpoint.

Hue Motion Sensor

Here's the configuration for a Hue motion sensor:

Endpoint	Profile	Cluster	Name
02	ZHA		Occupancy Sensor
		0000	Basic
		0001	Power Configuration
		0003	Identify
		0406	Occupancy Sensing
		0400	Illuminance Measurement
		0402	Temperature Measurement
		0019	OTAU
01	ZLL		On/Off Sensor
		0000	Basic
		0000	Basic
		0003	Identify
		0004	Groups
		0006	On/Off
		0008	Level Control
		0300	Color Control
		0005	Scenes

Notes:

• So the Hue motion sensor does talk ZHA?!
• On the Hue bridge, a Hue motion sensor is exposed as three sensor resources: a ZLLPresence with a uniqueid of 00:17:88:01:02:xx:xx:xx-02-0406, a ZLLLightLevel with 00:17:88:01:02:xx:xx:xx-02-0400, and a ZLLTemperature with 00:17:88:01:02:xx:xx:xx-02-0402. These match the ZHA endpoint and cluster.
• The ZLL endpoint seems to suggest a Hue motion sensor could work standalone, without a Hue bridge, like the Hue dimmer switch?!

Hue Dimmer Switch

Here's the configuration for a Hue dimmer switch (firmware 5.45.1.17846):

Endpoint	Profile	Cluster	Name
01	ZLL		Non-Color-Scene Controller
		0000	Basic
		0000	Basic
		0003	Identify
		0004	Groups
		0006	On/Off
		0008	Level Control
		0005	Scenes
02	ZHA		000C unknown
		0000	Basic
		0001	Power Configuration
		0003	Identify
		000F	Binary Input (Basic)
		FC00	Vendor Specific
		0019	OTAU

Notes:

• The Scenes cluster is missing from two of my dimmers, which report as a Non-Color Controler device. These dimmers have a different label on the back and a different firmware version (5.45.1.16265).
• So the Hue dimmer switch does talk ZHA?!
• On the Hue bridge, a Hue dimmer switch is exposed as a ZLLSwitch sensor with a uniqueid of 00:17:88:01:10:xx:xx:xx-02-fc00. This matches the ZHA endpoint and the FC00 cluster.
• The Hue bridge has a corresponding clients for the 000F and FC00 clusters. The FC00 cluster is used for button events. It's unknown what the 000F cluster is used for.
• deCONZ seems to have troubles communicating with the dimmer switches. Of my six dimmer switches, only two are reporting in the web interface; two show grey, but trying to read attributes through Cluster Info does nothing; two show red and don't even list the discovered endpoints and clusters.

Hue tap

The Hue tap doesn't show in the deCONZ gui, but the REST API reports ep of 242 which is 0xF2.

Endpoint	Profile	Cluster	Name
F2	ZGP		?

Notes:

• On the Hue bridge, a Hue tap is exposed as a ZGPSwitch sensor with a uniqueid of 00:00:00:00:00:xx:xx:xx-f2, matching the ZGP endpoint on the Hue bridge and Hue lights.

Osram

Lightify Gateway

Here's the configuration for a Lightify Home Gateway (ZigBee firmware version 1.2.0.68):

Endpoint	Profile	Cluster	Name
40	ZLL		Control Bridge
		1000	ZLL Commissioning
		0019	OTAU
		1000	ZLL Commissioning
		0004	Groups
		0005	Scenes
		0000	Basic
		0300	Color Control
		0003	Identify
		0008	Level Control
		0006	On/Off
41	ZHA		Combined Interface
		000F	Binary Input (Basic)
		0406	Occupancy Sensing
		0402	Temperature Measurement
		0405	Humidify Measurement
		FC00	Vendor Specific
		0400	Illuminance Measurement
F2	ZGP		0061 unknown
		0021	ZigBee Green Power Proxy

Notes:

• This is exactly the same configuration as for a (first-generation) Hue bridge.

Lightify Light

Here's the configuration for an Osram E14 bulb:

Endpoint	Profile	Cluster	Name
03	ZLL		Color Temperature Light
		1000	ZLL Commissioning
		0000	Basic
		0003	Identify
		0004	Groups
		0005	Scenes
		0006	On/Off
		0008	Level Control
		0300	Color Control
		FC0F	? Device Setup
		0019	OTAU

Notes:

• On the Hue bridge, an OSRAM light has a uniqueid of 84:18:26:00:00:xx:xx:xx-03, matching the ZLL endpoint.
• I suspect OSRAM use the FC0F cluster for setting the power-on default. There's no corresponding client cluster in the Lightify Home Gateway, though.

Lightify Plug

Here's the configuration for an Osram plug (firmware 01020315):

Endpoint	Profile	Cluster	Name
03	ZLL		On/Off Plug-In Unit
		1000	ZLL Commissioning
		0000	Basic
		0003	Identify
		0004	Groups
		0005	Scenes
		0006	On/Off
		0B04	? Electrical Measurement
		0019	OTAU

Notes:

• On the Hue bridge, an OSRAM plug has a uniqueid of 84:18:26:00:00:xx:xx:xx-03, matching the ZLL endpoint.
• There doesn't seem to be any Electrical Measurement feature in the OSRAM Lightly app. There's no corresponding client cluster in the Lightify Home Gateway either.

innr

innr Gateway

I've not been able to join the RaspBee to a network created by the innr Gateway. innr seem to use a different commissioning scheme: their lights only join a network for a short period after they're powered on.

innr Bulbs

Here's the configuration for an innr RB 162 dimmable light:

Endpoint	Profile	Cluster	Name
01	ZLL		Dimmable Light
		0000	Basic
		0004	Groups
		0003	Identify
		0006	On/Off
		0008	Level Control
		0005	Scenes
02	ZLL		1000 unknown
		1000	ZLL Commissioning

Notes:

• On the Hue bridge, an innr bulb has a uniqueid of 00:15:8d:00:00:xx:xx:xx-01, matching the first ZLL endpoint.
• Indeed, no over-the-air update for the firmware as innr support had indicated.
• deCONZ seems to have problems communicating with these lights. They show red after a while in the deCONZ gui. When trying to send a command (from cluster info), deCONZ reports sending failed.

innr Control Board

Here's the configuration for an innr PL 110 or UC 110, which use the same control board:

Endpoint	Profile	Cluster	Name
01	ZLL		Dimmable Light
		0000	Basic
		0004	Groups
		0003	Identify
		0006	On/Off
		0008	Level Control
		0005	Scenes
		FFFF	?
		0019	OTAU
		0000	Basic
		0004	Groups
		0003	Identify
		0006	On/Off
		0008	Level Control
		0005	Scenes
		0019	OTAU

Notes:

• On the Hue bridge, an innr light has a uniqueid of 00:15:8d:00:00:xx:xx:xx-01, matching the ZLL endpoint.
• Huh, support for over-the-air update for the firmware?
• Huh, no ZLL Commissioning? Maybe that's why these aren't listed under certified devices on the ZigBee alliance website?
• I've no clue about the FFFF cluster. Maybe it's the ZLL Commissioning with a wrong cluster ID? The control board can be touch linked to the Hue bridge.
• The control board seems to be configurable as a ZigBee control device as well. Physically, it does contain an unused header. Maybe innr plan to use the same board in their sensors?
• deCONZ seems to have problems communicating with these control boards. They show red after a while in the deCONZ gui. When trying to send a command (from cluster info), deCONZ reports sending failed.

Ikea

Currently, the Ikea Trådfri lights are advertised as not compatible with the Hue bridge. Curious to find out why, I got myself an E27 980lm Color temperature light with a round, 5-button remote. The light and the remote work well together, out of the box.
I touchlinked the light to the Hue bridge, and it responded. As expected, the light no longer reacts to the remote. So the light joins the ZigBee network created by the Hue bridge without any problem.
As advertised, the Hue bridge doesn't find the light when searching for new lights, but it does appear in the deCONZ GUI. The deCONZ REST API picked it up as well:

{
  "etag": "162cd7e2cd4b29553fbe5deea036de83",
  "hascolor": true,
  "manufacturer": "IKEA of Sweden",
  "modelid": "TRADFRI bulb E27 WS�opal 980lm",
  "name": "Light 17",
  "pointsymbol": {},
  "state": {
    "alert": "none",
    "bri": 127,
    "colormode": "ct",
    "ct": 300,
    "effect": "none",
    "hue": 0,
    "on": true,
    "reachable": true,
    "sat": 0,
    "xy": [
      0.46168,
      0.412215
    ]
  },
  "swversion": "1.1.1.1-5.7.2.0",
  "type": "Color temperature light",
  "uniqueid": "00:0b:57:ff:fe:xx:xx:xx-01"
}

Likewise, I touch linked the remote to the Hue bridge. It appears in the deCONZ GUI, so the remote also joins the Hue bridge ZigBee network without any issue. Neither the Hue bridge, nor the deCONZ REST API finds the remote.

Trådfri E27 980lm

Here's the configuration for an Ikea Trådfri E27 980lm bulb:

Endpoint	Profile	Cluster	Name
01	ZHA		Color temperature light
		0000	Basic
		0003	Identify
		0004	Groups
		0005	Scenes
		0006	On/Off
		0008	Level Control
		0300	Color Control
		0B05	Diagnostics
		1000	ZLL commissioning
		0005	Scenes
		0019	OTAU
		0020	Poll Control
		1000	ZLL commissioning

Notes:

• So the light provides the usual clusters, like the other vendor's lights, but on a ZHA endpoint. This is consistent with the info on the Internet. No way the Hue bridge is going to accept that.
• The light supports ct values from 250 (4000K) to 454 (~2200K). The box seemed to suggest that it only had three colour temperature settings, but maybe that's a limitation of the switch.
• The light doesn't seem to support attribute reporting (like the Hue lights).

Trådfri remote control

Here's the configuration for an Ikea Trådfri remote control:

Endpoint	Profile	Cluster	Name
01	ZHA		Color scene controller
		0000	Basic
		1000	Power Configuration
		0003	Identify
		0009	Alarms
		0B05	Diagnostics
		1000	ZLL commissioning
		0003	Identify
		0004	Groups
		0005	Scenes
		0006	On/Off
		0008	Level Control
		0019	OTAU
		1000	ZLL commissioning

Notes:

• As with the Trådfri light, it exposes the usual cluster, but on a ZHA endpoint.