deconz-rest-plugin
deconz-rest-plugin copied to clipboard
dresden-elektronik
Hue gradient lightstrip
Device
- Product name: Hue gradient lightstrip
- Manufacturer: Signify Netherlands B.V.
- Model identifier: LCX004
- Device type : Extended Color Light
deCONZ already supports this light strip as a regular single-colour lightstrip. The request is, of course, for support of the gradients. In the Hue app, the light strip shows three linked colour points, allowing for three areas with different colours, smoothly transitioning into each other. These gradients are supported only through the Hue API v2.
Screenshots
Basic
Very similar to the Hue outdoor light strip and to the modules in the Hue Ensis, except for the 0xFC03 cluster.
Identify
Same as other Hue lights.
Groups
Same as other Hue lights.
Scenes
Same as other Hue lights.
On/Off
Same as other Hue lights.
Level Control
Same as other Hue lights.
Color Control
Same as other Hue lights: colour temperature between 153 and 500; colours from gamut-C.
OTAU
Image type 0x0118; I managed to capture the location of the firmaware file and updated https://github.com/dresden-elektronik/deconz-ota-plugin/blob/master/README.md.
FC01
This cluster is present on all Hue colour lights. I don't know what it's for exactly; might be related to Hue Entertainment.
FC03
The Hue bridge uses this cluster to set the gradient colours. It polls attribute 0x0002, which is an octec string, and it sends command 0x00 when changing the gradient from the Hue app. The gradients are supported only by the Hue API v2.
This cluster is also present on the gamut-C E27 bulb, but not on the gamut-A and gamut-B bulbs and spots, and not on the regular light strips.
The Hue app shows special animated scenes, Candle and Fireplace. Looks like the animation is handled by the light strip firmware. When selecting Candle, the bridge sends command 0x00 to 0xFC03 with payload 0x200001. For Fireplace, it sends 0x200002. When stopping the animation from the app, payload 0x200000 is sent.
| payload | meaning |
|---|---|
| 0x200000 | stop animation |
| 0x200001 | Candle animation |
| 0x200001 | Fireplace animation |
Attribute 0x0002 seems to encode the light state, where the first two bytes indicate the mode, the next byte OnOff, the next byte Current Level, and the following bytes the mode-specific state. For example:
0b:00:01:fe:05:b1:ec:4e
| | | | + Current Y: 0x4eec = 0.3083
| | | + Current X: 0xb105 = 0.6915
| | + Level: 254
| + OnOff: on
+ mode 0x000b:`xy`
This is the red-most colour in gamut-C. The attribute reflects this after setting {"xy": [1, 0.0001]} through the APIv1, as well as after setting {"hue": 0, "sat": 254}.
After setting {"ct": 254}, 0x0002 reports:
0f:00:01:fe:fe:00:4c:62:84:61
| | | | | + Current Y: 0x6184 = 0.3809
| | | | + Current X: 0x624c = 0.384
| | | + CT: 254
| | + Level: 254
| + OnOff: on
+ mode 0x000b = `ct`
The Current X and Current Y values match what APIv1 reports for xy while in colormode ct.
After setting Candle:
ab:00:01:54:1c:7a:e8:69:01:80
| | | | | + Scene 0x8001 = Candle
| | | | + Current y: 0x69e8 = 0.4137
| | | + Current X: 0x7a1c = 0.477
| | + Level: 0x54 = 33%
| + OnOff: on
+ mode 0x00ab = Scene
And after setting Fireplace:
ab:00:01:fe:98:8c:7f:68:02:80
| | | | | + Scene 0x8002 = Fireplace
| | | | + Current y: 0x687f = 0.4082
| | | + Current X: 0x8c98 = 0.5492
| | + Level: 0xfe = 100%
| + OnOff: on
+ mode 0x00ab = Scene
After setting {"effect": "colorloop"}, 0x0002 reports the current colour in mode 0x000b.
Setting the gradient seems straightforward enough. It's command 0x00 with a payload:
-
50 01 04 00 - 1 byte is length of variable part = 4 + 3 * #entries
- Next byte has #entries << 4
- 3 bytes
00 00 00; - Next is 3 bytes per entry with x, y values normalised to 000..ffff. Bytes need to be read backwards (as u24) and then split in high byte for x and low byte for y. So [0, 1] is ff0f00 => 0x000fff => [0x000, 0xfff]
- Next byte seems related to #entries shifted
10= 2;18= 3;20= 4;28= 5 - Next byte
00.
Attribute 0x0002 seems to follow a similar pattern:
-
4b01for mode - 1 byte for OnOff
- 1 byte for Current Level
- 2 bytes for Current X
- 2 bytes for Current Y
- 1 byte length
- 1 byte #entries << 4
- 3 bytes
00 00 00 - 3 bytes per entry
- 1 byte #entries << 3
However, I have no clue yet how the entries are encoded. 000000 corresponds to 57730e; ffffff to 11ea91
While the Hue app only visualises 3 points, it actually sends 5. I suppose the lines connecting the points are significant as well, relating to the intermediary points.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Small update, the Hue gradient lightstrip is ordered so should be ready for integration soon.
Do you have something new to the hue gradient integration with more than one light?
Would love to see support for Hue Gradient Signe as well. I guess it's based on the same function. If someone need details from that lamp, please ping me :)
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Would love to see support for Hue Gradient Signe as well. I guess it's based on the same function. If someone need details from that lamp, please ping me :)
I too have the Gradient Signe, so I'm guessing each zone is not available for control via deconz yet correct? If you need anything from me to help get it working happy to help!
It would help to see how the Hue bridge exposes the Signe over API v2. Also, please attach GUI screenshots of the node with endpoints and clusters, and of the Basic (see my initial comment), and check what the Image Type of its firmware is (in the OTAU panel).
Sorry for the delay on this.
It would help to see how the Hue bridge exposes the Signe over API v2.
Sure things, but how can I do this?
Also, please attach GUI screenshots of the node with endpoints and clusters
and of the Basic (see my initial comment),
and check what the Image Type of its firmware is (in the OTAU panel).
Hope this helps, please let me know anything else I can provide!
Please read the attributes before taking the screenshot, so the attribute values are populated. I think there’s a bug in the GUI, that the attribute values of the OTAU cluster aren’t updated, until you select another cluster and then re-select the OTAU cluster. Alternatively, check the OTAU panel instead.
Apologies but I can't seem to get the attributes to populate to anything different than what I posted above.
I've tried pressing the 'read' button that is above cluster info attributes:
but as you can see nothing seems to happen even when selecting a different cluster.
The OTAU panel is showing this:
The OTAU panel is showing this:
Cool.
What about the Basic cluster? We would need at least the Model Identifier.
Maybe this could help to fully integrate the hue gradient lightstrip: https://github.com/Koenkk/zigbee2mqtt/issues/10674
From what I read, they failed to reverse engineer the encoding of the gradient colour points just as badly?
Yes, I think so, too. However, they captured few scenes. Maybe this could give a hint in the right direction…
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.