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;
Try an make the RaspBee join a ZigBee network created by an Osram Lightify gateway.
Double check that the Lightify Gateway has FC0F and 0B04 client clusters for Device Setup and Electrical Measurement.
Try and make the RaspBee join a ZigBee network created by an innr gateway.

Philips

Hue Bridge

Here's the configuration for a second-generation Hue bridge:

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
		0008	Level Control
		0006	On/Off
41	ZHA		Combined Interface
		000F	Binary Input (Basic)
		0406	Occupancy Sensing
		0402	Temperature Measurement
		0405	Humidify Measurement
		FC00	? Device Setup
		0400	Illuminance Measurement

Notes:

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. Not sure if that's supported by ZLL Commissioning or whether the 000F or FC00 is 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?

Hue Lights

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

Endpoint	Profile	Cluster	Name
02	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:00:xx:xx:xx-0b. I would expect an endpoint 0B (or a uniqueid of 00:17:88:01:00:xx:xx:xx-02).

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:02:7f:1a-02-0400, and a ZLLTemperature with 00:17:88:01:02:02:7f:1a-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:

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	Device Setup
		0019	OTAU

Notes:

The Scenes cluster is missing from one of my dimmers, which reports as a Non-Color Controler device. Not sure if this is due to a deCONZ communication error or different firmware?
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. I suspect one of these to be used for buttonevent. Functionally, I'd expect 000F (Binary Input), but the uniqueid seems to suggest FC00.
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

Notes:

The Hue tap doesn't show in the deCONZ gui.
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 ZHA endpoint on the Hue bridge and Hue lights.

Osram

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.

Lightify Plug

Here's the configuration for an Osram plug:

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.
I don't remember seeing some Electrical Measurement features in the OSRAM Lightly app.

innr

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. It does contain an unused header. Maybe innr uses the same board in their gateway?
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.