Color_temp value in scenes not correct #4926
Comments
|
I don't understand the issue, can you provide a list of steps to reproduce this and clear indicate what the problem is? |
@Koenkk, this happens if I send a normal GROUP command as payload:
The info shows a color value of See Log: This happens when I add a Scene with the same values and recall it: Log: As you can see in the log when the scene is recalled, the X and Y colors are suddenly As a work around I use the color attribute instead of the color_temp when adding a Scene. Why is the value of color attribute, when recallling a Scene, set to {"x":0,"y":0} ? |
|
Can you check if it works via |
Hi @Koenkk, With scene_store the recall is working correct, color values are equal to the normal set state command: Other thing I notice in the log is that:
|
|
The incorrect brightness occurs because the spots report this brightness themselves: If the actual brightness is not 8 at this moment, this seems to be a bug inside the firmwares of the bulbs. |
|
I started to notice this brightness bug until I was testing the scene functionality, never before. I can’t test it with other bulbs, because these are the only 3 with color temp I have. I will continue to use the color attribute then instead of color_temp. |
|
I can confirm that scene_add with color_temp is not working with Ikea trådfri GU10 WS and FLOAT panels. I retested 'color' on a Trådfri CWS bulb and that does seem to work fine though. Doing a read for color_temp afterwards also returns the wrong value, I wonder if tradfri specific as they also return a color_mode indicating xy for the WS bulbs... @Anjerlaan what bulbs are you using? |
|
Some more testing... (with a Tradfri LED1537R6/LED1739R5 I had to spare) This doesn't seem to work at all, while doing this using 'color' and a RGB value for a tradfri CWS bulb works fine... {
"scenes": {
"22_0": {
"state": {
"state": "OFF",
"color_temp": "250"
}
},
"23_0": {
"state": {
"state": "OFF",
"color_temp": "455"
}
}
}
}This looks fine to be, I also tried with state ON, but that makes no difference. Lets try with scene_store! {
"scenes": {
"22_0": {
"state": {
"state": "ON",
"color_temp": "250"
}
},
"23_0": {
"state": {
"state": "ON",
"color_temp": "455"
}
},
"30_0": {
"state": {
"state": "OFF",
"brightness": 254,
"color_temp": 250,
"color": {
"x": 0,
"y": 0
}
}
},
"31_0": {
"state": {
"state": "OFF",
"brightness": 254,
"color_temp": 455,
"color": {
"x": 0,
"y": 0
}
}
}
}
}
}Same results with as above when recalling (same done with state left to ON). |
|
I manually tested setting color_temp first to verify the bulbs is supporting it, then I repeated the test above... with the exact same results :( Recall does not work at all for color_temp, I tried with both state=ON and state=OFF in the scene_add payload, this allowed me to verify the bulb does respond to the scene_recall as it goes on or off depending on what was in the scene_add payload. Repeated the tests with the following brands/bulbs...
So it doesn't work for any of the bulbs I currently have available for testing, not a super wide selection, but I think we can probably say it's a generic issue. |
@sjorge Same as yours, i have the exact same findings |
|
IKEA is adding scenes with X and Y for their WS bulbs as shown from sniffing the GW: And after it reading it for verifying the setting is made: PS: The scenes is special initiated with manufacturer commands so only the color is changed then getting command from the 5 button remote and skipping the on/off, light level and blinds positions. |
|
Sending color seems to work for Trådfri and my CWS bulbs, I sadly don't have WS only bulbs from Hue or other brands to try with. I still think something is broken, because the ZCL says we can set color_temp via scenes... i can take say Trådfri botching there firmware so there remotes can just send xy... but it would seem odd all brands would do this. I'll try to setup my sniffer tomorrow and see what z2m is sending out for the scene_add, perhaps we're encoding something wrong. |
|
I think the IKEA WS scenes must being setted up / added with xy and not CT that its little of standard. The IKEA Zigbee 3 lights scenes is pretty good and standard then not using their GW and is certified, some things is added that is out of standard (true manufacture cluster) but that is OK in zigbee but the setting of colour is odd. PS: Dont forgetting go to Lidl then there "Home Smart Home" is coming for getting little more zigbee toys like zigbee christmas tree lights and short RGBWW LED stripes ;-) |
|
Some annoying side effects, the IKEA WS bulbs don't seem to update color_temp when they change color via a scene with color_xy... Also looks like they only take a very specific set of colors, I figured them out by using the remote... then recording both color_temp and color_xy The remotes are definitely doing odd stuff when they set the scene as the bulb seems to report color_temp afterwards. |
|
If you is adding groupe 0xff09 to the bulb and then adding new scenes to it you can using the remote for your scenes. If the remote dont get any groupe thru touchlink the pairing its sending the scene next and previous to groupe 0xff09. IKEA WS dont have so wide range as is possible in the zigbee standard was seeing that then testing scenes in deCONZ. |
|
I got a pcap here for the scene_add/recall with color_temp included: https://pkg.blackdot.be/cores/zigbee/scene_add_recall.pcapng @Koenkk same netkey as usual. |
|
I think we're not correctly adding the color_temp, as it is not present in the scene add payload, it does however list a blank x, y, hue, and saturation |
|
I wonder if scenes have slightly modified clusters spec? As Color Loop * is not listed for cluster 0x0300 (color control) in the ZCL doc I have? Given the reference to color loop... could we be writing a ZLL variant instead? If so, I don't think that has a color_temp field and we're probably writing junk. |
|
Tyre save one scene and then veuve the scene and you can see how is stored. |
|
Is the scene stored / added with power off state off ?? |
|
There is no scene view support though (in z2m), I also tried with scene_store and it doesn't recall color_temperature either. This one was indeed with state off, but as mentioned above, on or off makes no difference. It works fine (state off) with color for CWS bulbs though (so you can change the color while they are off!, tested on trådfri, hue, innr, muller, and osram!) |
|
The extension for lights in zigbee 3: docs-15-0014-05-0plo-Lighting-OccupancyDevice-Specification-V1.0.pdf Missing command 0x01 View scene is mandatory so it cant being moddes in the light. |
|
Yeah, It's z2m currently that does not implete the view/delete/delete_all |
|
Then you must doing some nice calculatings and sending the command raw and hoping its being right ;-)) |
|
Nope, no gateways for testing. z2m is handling the scene_add here, https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/toZigbee.js#L3699, but... currently i'm working under the assumption that:
Still not sure which. |
|
IKEA GW / remote adding one scene to one WS bulb: Then setting it with XY instead. |
|
Yeah, setting XY works fine via scene_add. I sadly have no non IKEA WS bulbs, all the others I own are RGB. But if scenes with color_temp are not supported, we need to update scene_add to complain when passing color_temp. If they are supported, we need to look into fixing the payload. Edit: I wonder if writing 0 to the fields insteads of just not providing them is tripping up the bulbs, looks like Ikea is not writing 0 to other fields... |
|
@Koenkk how is the order of the extFields set determined? the listed order doesn't seem to match whats in " |
|
Its gets one thread with much dumps of setting up scenes on ikes CWS its like somthing "2 tyre getting the 5 button remote to work with scenes" |
|
@sjorge the order should match the one in the ZCL spec (so probably that is why it's not working) |
Right, so the color_temp payload we pack is probably wrong... I tried poking around with it but the slot where 'val' is doesn't even show up in the wireshark capture. If I shift it a slot forward it comes in the other listed attributes, but some give a malformed payload, probably because the value is out of range. Also not sure we should set the other fields to |
|
So I found out what is happening here. Started with wireshark and it looks that we include the color temperature values correctly as they can be seen in the payload , its a 2 byte number, see red circles, however they indeed do not show up in the "friendly name" list.
Then I found out that the colorTemperatureMireds extension field is something new in ZCL V7: (left V6, right V7):
This is (very likely) the reason why wireshark does not show it, it simply has not been updated with V7. Therefore many bulbs probably also don't support this. So in case your bulb doesn't you can do the following:
|
|
Way not setting the CT with XY and not the Mireds is stored in the scene table and dont need to knowing if the light is ZCL v7 compatible or not ? |
|
So far from testing, I looks like none of:
- Hue
- Trådfri
- Mueller
- OSRAM
- Innr
Support it, that’s all I had for testing.
For trådfri there is a set of colors they take for there own scenes... I think I posted them above too.
~ sjorge
… On 30 Nov 2020, at 19:48, MattWestb ***@***.***> wrote:
8657 Since there is a direct relation between ColorTemperatureMireds and XY, color temperature, if supported, is stored as XY in the scenes table.
Way not setting the CT with XY and not the Mireds is stored in the scene table and dont need to knowing if the light is ZCL v7 compatible or not ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
IKEA GW can adding more then scene 0 to 2 with X Y. It was called moods then i was doing the sniff but for some days its changed to scenes. In deCONZ i have saved (not added) 6 scenes but its not the same. |
|
With the IKEA WS have smaller range then the maximum in ZCL but the range you is having in the warm and cold scenes. If I remember right its possible reading the attribute wat capacity one device is having. If trying going outside its range its not saving the scene. |
|
@Koenkk we have code somewhere that maps Mirad to XY in z2m right? I'm not sure how there is an easy way to do the fallback, but I guess we could always do it until we find bulbs that actually support it? |
|
@sjorge I also wondered about that, but I don't know if that is the correct way as this might not work when the user has reporting being setup (bulb will report x/y color and not color temperature). If you want to experiment, do the inverse of https://github.com/Koenkk/zigbee-herdsman-converters/blob/e2662cb2d677fea2cb13f2ee6770ab9c0129c14e/converters/utils.js#L118 and use https://github.com/Koenkk/zigbee-herdsman-converters/blob/e2662cb2d677fea2cb13f2ee6770ab9c0129c14e/converters/utils.js#L122 |
|
A quick dirty test shows,... that the lights (IKEA Trådfri) do seem to report colorTemperature correctly. |
|
Looks good, can you make a PR? We can work further from there. |
|
Sure, not sure I will have time before next week. But I should be able to writing something up.
I’d love to do more testing but all test bulbs from other brands are CWS.
~ sjorge
… On 1 Dec 2020, at 22:30, Koen Kanters ***@***.***> wrote:
Looks good, can you make a PR? We can work further from there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Should be fixed. Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html) |
|
Some interesting side effects after using this for a few days.
In all cases the bulb did change to the right color temp
It I have a bit more time I’ll see what these return with a get. I’d assume the same as the report but you never know. (Only my FLOALT planets are still on a 1.x firmware as they lack updates) |
|
The GU10 WS 2.0 have those min and max attributes for color temperature: Its reporting Color_temperature (0x0007), Current_X (0x0003) and Current_Y (0x0004). My old E27 CWS (ZLL) is reporting the same for colour temperature min and max. Cluster attributes is red thru ZHA. |
|
I don't think currently the min/max range are even used without scene either, maybe they should though... that might prevent out of range values being set. cc @Koenkk ? I've not had time to do more testing with /get |
|
I think its better taking it in the calculating then its possible getting it from the device. |
|
The min/max color temperature is not used yet indeed. |
Should I file a feature request for that against zhc? |
|
Been playing around with colorMode and xy vs hs a bit today, looks like for scenes we only write xy for now? https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/toZigbee.js#L3542
All my bulbs are Innr and a Tint bulb, so I believe I should be able to test the effect on both kind of bulbs. Edit: Off to bed I go now, but oddly enough both the Innr and Tint report 31 for the ColorCapabilities property! Edit2: Ok the RB 185 C does support enhancedHue, the RB 250 C does not... why innr, why?!?!? |
|
Its looks that all manufactures is doing little home "cooking" in there devices and need little attention for working well. The latest is the new LIDL WS / CT that is reporting that they is doing TC + color but is only color (perhaps the zigbee module is doing both but dont have the RGB LEDs implanted for saving time and money in development and production). Goooood digging done !! Edit: IKEA GW / devices is setting up scenes with xy is verified by sniffing but "our deCONZ friends" have disabling storing scenes with XY for IKEA lights then its not working OK. I think it can being good storing the abnormal config in the system together with the base config for the devices (device.jar i think its named in Z2M) so all lights is getting it then joining the system if its possible implantation. Edit 2: Some TC lights (IKEA and more) dont have the maximal color range (that is possible in Zigbee standard) in there devices but can being red from the attribute if i have understanding it right. That is also good to pulling from the device and being passed to HA so its TC slide is working OK and also for saving scenes so not sending out of range parameters to the device that can making things working bad. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
What happened
I have been testing with Scenes, this is a nice option.
But there is a huge difference in color_temp if I sent to a GROUP:
{ "state": "ON", "brightness": 120, "color_temp": 350 }Or add a Scene with the same values and recall it:
When I use the
"color": {"x":0.447991567541816,"y":0.407559831563923}attribute instead, this value represents the correct color_tempDebug info
Zigbee2MQTT version: v.1.15.0
Adapter hardware: CC26X2R1
Adapter firmware version: (zStack3x0 20200925)
The text was updated successfully, but these errors were encountered: