Cannot set hue/sat/ct values when modifying a scene

[Thomas-Vos]

A PUT request to the following URL:

http://<ipaddress>/api/<apikey>/groups/<group_id>/scenes/<scene_id>/lights/<light_id>/state

ignores the color attributes hue, sat, and ct. The xy attribute does work, as well as on, bri, and transitiontime. Because of this, it is impossible to set the ct value for a scene. (you can use the /store command instead, but that would require switching on the light. For my use case this is not really possible as I need to create a lot of scenes).

Looking at the code it appears that these attributes are just ignored, and you can only use xy: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_groups.cpp#L3099-L3129

Is there a reason why these were never implemented, or is this just something that still needs to be added?

[Thomas-Vos]

Just noticed that there's another issue very related (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/348), you cannot set the xy if the color mode was not set to xy previously. Steps to reproduce:

• Set the color mode of a light to ct. (just a normal light state command with a ct value)
• Create a scene (> a scene is created with colormode set to ct)
• Modify the scene. PUT to /groups/..scenes/../lights/../state with body: {"xy":[0.5,0.5]}
• The scene was not modified to xy. The colormode is still set to ct.

[manup]

Is there a reason why these were never implemented, or is this just something that still needs to be added?

The main reason is the very mixed quality in implementation of the add scene command in lights of various vendors. Philips hue as usual works perfectly. But we had some trouble using this feature in OSRAM lights (IKEA maybe too but I'm not sure).

The last check is quite a while ago (2015/2016), perhaps meanwhile some firmware issues were addressed and we should consider implementing this feature again. But it needs a lot of testing with various brands and firmware versions.

What works most reliable is the store scene command where the firmware handles the state internally, but as you've noticed the lights need to be switched on at the time.

An alternative might be adding scenes just in the gateway and when recalled the gateway sends the related commands to lights. But this doesn't scale well, there are more and more networks with ~100 devices and up.

[Thomas-Vos]

Thanks for your detailed response. As a workaround I will switch on the lights temporarily before creating a scene. For creating lots of scenes this doesn't look like the best way, but at least this is reliable.

Why was this partially implemented in the API if this has some issues with colors? I don't understand why support for xy was added if you can't set the colormode. Isn't it better to just not support this instead of something which won't work as expected?

A minor issue with using /store instead of /state, is that it won't be possible to create a scene which only switches on the lights without changing colors, the colors are always changed when the scene is activated. (on a Hue bridge it is possible to create a scene using only on/bri commands without color)

Another small point which is a bit related to this issue; when reading the light states of a scene, the xy attributes is not an array but two separate values. This isn't a problem for me, but maybe it's an idea to change this to an array to keep it similar to the rest of the API. See: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_groups.cpp#L2311-L2312

An alternative might be adding scenes just in the gateway and when recalled the gateway sends the related commands to lights. But this doesn't scale well, there are more and more networks with ~100 devices and up.

Do you mean stop using the Zigbee scenes and just send normal light state commands? I don't think that's a good solution because then lights won't switch on at (exactly) the same time. Maybe another solution would be to save the scenes to the gateway, and when they are activated for the first time, send lights commands and create a real scene (like in the API: /store). Then if the scene is activated again, it can just use the previously created scene. (but this won't solve the color issue I mentioned above)

[Thomas-Vos]

In addition to the points mentioned above, I really would like to be able to create scenes which do not change the current brightness (only change color, do not change brightness or switch on light). Is this possible in any way?

I am currently working on making the effects in Hue Essentials compatible with deCONZ. These "effects" are created on the bridge by using lots of scenes and ddx rules. To allow the user to change the brightness of the lights when an effect is "running", the scenes must not send on/brightness commands, but only color commands. This is so the scene does not "override" the brightness set by the user.

[manup]

Why was this partially implemented in the API if this has some issues with colors? I don't understand why support for xy was added if you can't set the colormode. Isn't it better to just not support this instead of something which won't work as expected?

To be honest it was a lack of time, when I remember correctly at the time I've tested with xy values which worked okayish for a mixed set of lights. The scenes API needs to get a refactor to get the most out of todays lights and firmware capabilities.

Another small point which is a bit related to this issue; when reading the light states of a scene, the xy attributes is not an array but two separate values. This isn't a problem for me, but maybe it's an idea to change this to an array to keep it similar to the rest of the API. See: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/rest_groups.cpp#L2311-L2312

Good catch this can be fixed easily to provide the proper xy attribute.

Maybe another solution would be to save the scenes to the gateway, and when they are activated for the first time, send lights commands and create a real scene (like in the API: /store). Then if the scene is activated again, it can just use the previously created scene. (but this won't solve the color issue I mentioned above)

That's a very interesting idea, such a approach could also decide which lights support proper Add Scene commands (like Hue) and fallback to unicast Store Scene commands for lights which don't.

This needs a lot of testing but really might be worth it for the refactor.

I am currently working on making the effects in Hue Essentials compatible with deCONZ. These "effects" are created on the bridge by using lots of scenes and ddx rules. To allow the user to change the brightness of the lights when an effect is "running", the scenes must not send on/brightness commands, but only color commands. This is so the scene does not "override" the brightness set by the user.

Be aware that lights only support a limited number of scenes, some only 8–16 in total. Depending on how fast the effect should "cycle" and how many lights are effected you might also just use rules and some helpers like CLIPGenericStatus to move forward a "frame" in the sequence. With the actions array you can only set the values needed, like color. There is no real limit for rules other than memory which huge.

[Thomas-Vos]

Be aware that lights only support a limited number of scenes, some only 8–16 in total.

This is interesting, I haven't had any issues with a scenes limit on a Hue bridge. Why does deCONZ have this limit but the Hue bridge doesn't?

Let's say the user has a scene called "Tropical twilight". The user wants to activate that scene (using a schedule) with a transition time of 30 minutes. On a Hue bridge, I create a copy of the Tropical twilight scene with the only difference being the 30 min transition time. Then this "copy" scene is used in the schedule instead of the original. This is so the user can still use the original Tropical twilight scene without the large transition time. If deCONZ has a limit for 8 scenes on some lights, then I guess creating copies of scenes just to be able to set a transition time would not be an ideal solution? How could this be done differently to work around this limit? As mentioned above, I haven't experienced any limits on a Hue bridge with lots of scenes.

Depending on how fast the effect should "cycle" and how many lights are effected you might also just use rules and some helpers like CLIPGenericStatus to move forward a "frame" in the sequence.

The effects in Hue Essentials on a Hue bridge are implemented similar to what you are describing. They have a ClipGenericStatus sensor which changes when the user starts the effect. Then there are multiple rules with ddx operators for state/lastupdated for that sensor with values like PT00:00:05, PT00:00:10, etc. These rules move forward in the "frames". Each of those rules have a scene as action.

With the actions array you can only set the values needed, like color. There is no real limit for rules other than memory which huge.

This could be a solution but if I understand this correctly, then it won't be possible to change the colors for all lights at exactly the same time. This is why I used scenes so all lights change colors simultaneously. If someone has 10 lights in an effect, then 10 light commands would need to be sent instead of just a single scene command.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Thomas-Vos]

Is there any chance things have changed making it possible to implement this? We still have users in Hue Essentials asking for allowing to save "Hue Essentials light effects" on the deCONZ. This is blocked by this issue.

[HeinderB]

Anything new on this? From a user point of view this problem is quite annoying as it keeps me from having a nice wake up light. Hue Essentials is a great app that comes with better functions than the original Hue app. Automated changes in light color and intensity is for me one main advantage of smart RGB lights. If deCONZ is not able to save effects like these I will have to switch to an other zigbee hub - which I do not want either. Please find a solution for this!

[boldiebold]

I would love to have the possibility to save "effects" in deCONZ, too. Otherwise I can´t use them in switches, sensors etc. Would be a pitty if I have to relay for that on a hue bridge. Would be great if you can increase the score of the feature request and make it happen I believe Thomas from Hue Essential will support, too. The only one zigbee bridge recomendation would be yours than.

[mgrn0]

Any updates in this feature request? This would be so useful and would help me put the hue bridge to rest and just live with phoscon/deconz.

[HeinderB]

One year later and still no response? Please give a definite answer if this will be implemented or not

[Netfreak25]

This feature is still needed!