Support for Enhanced Scenes (transition times in tenth of a second)

[snozzlebert]

My experience is that transition times below 10 (1 second) don't work in scenes.
In this example I use a Philips Extended color light LCT001.
In my setup this light has id 2 and is the only light in group 1.

First I turn the light on:

PUT /lights/2/state
{
	"bri": 144,
	"ct": 447,
	"id": "2",
	"on": true,
	"transitiontime": 9
}

This results as expected in a fade in of 900ms.
When I verify the state:

GET /lights/2
{
    "hascolor": true,
    "manufacturer": "Philips",
    "modelid": "LCT001",
    "name": "Light 2",
    "state": {
        "alert": "none",
        "bri": 144,
        "colormode": "ct",
        "ct": 443,
        "effect": "none",
        "hue": 13416,
        "on": true,
        "reachable": true,
        "sat": 200,
        "xy": [
            0.503577,
            0.416872
        ]
    },
    "swversion": "5.23.1.13452",
    "type": "Extended color light",
    "uniqueid": "00:17:88:01:##:##:##:##-##"
}

I see ct 443 (after a while), while I expect 447, this is maybe the same as @ebaauw mentions in #53.
Then I create a scene:

POST /groups/1/scenes
{"name": "Group 1 - Scene 1 - Light 2"}

GET /groups/1
{
...
"scenes": [
    {
        "id": "1",
        "name": "Group 1 - Scene 1 - Light 2",
        "transitiontime": 10
    }
]
...
}

GET /groups/1/scenes/1
{
    "lights": [
        {
            "bri": 144,
            "colormode": "ct",
            "ct": 443,
            "id": "2",
            "on": true,
            "transitiontime": 10
        }
    ],
    "name": "Group 1 - Scene 1 - Light 2",
    "state": 0
}

The scene has the default transitiontime of 10.

When I turn off the light and recall the scene using
PUT /groups/1/scenes/1/recall
the light is turned on using a transition of 1 second.
I would like to change the transition time to 4 (400ms) which is also the default in the Hue bridge.

When the light is still on I do:

PUT /groups/1/scenes/1/store
{"transitiontime": 4}

I verified that GET /groups/1/scenes/1 and /groups/1 both show "transitiontime": 4

When I turn off the light and recall this scene again the light turns on again, however it is 'instant' (no fade of 400ms)
I tried this also with transitiontime 5,6,7,8 and 9 and never saw the transition. When I store 10 again, I can see the transtition again.
When I manipulate the state of the light directly using PUT /lights/2/state and a transitiontime of 4 I do see the transition of 400ms.
Why can't transitiontimes below 10 be used in scenes?

In the examples in #53, @ebaauw also stores "transitiontime": 4 without noticing this, so maybe I'm doing something wrong. Or is this related to this specific Philips bulb?

[ebaauw]

I think my problem in #53 is specific to the OSRAM lights, but both scenes and transitiontime have a tendency to behave unexpectedly. Combine them, and you never know what you get into.

I don't think the Hue bridge stores transitiontime with a scene, but it's specified when recalling a scene (through a PUT of /groups/xx/action with a body of {"scene": "yyy", "transitiontime": n}). I think you can recall a scene in deCONZ specifying a transition time as well: POST to /groups/xx/scene/yy/recall with a body of {"transitiontime": n}.

Note that the actual scene is stored on each light - the "scene" on the gateway (or bridge) is just a representation of what the gateway thinks the scene looks like. I've seen many instances where the scene stored in the light differs from the representation on the Hue bridge, or deCONZ gateway, especially when setting the light state with a transition time and then storing a scene. I don't think ZigBee provides a means to see the scene as it's stored in the light (other than recalling it and observing the resulting light state).

It would seem every manufacturer uses different transitiontime defaults for lights as well as for the gateway/bridge, resulting in a myriad of different behaviours when combining lights from multiple vendors.

I think I need to do some serious ZigBee sniffing before I fully understand this. However, this is low on my prio list - I need to get my home automation as it ran on the Hue bridge running on deCONZ first.

[manup]

My experience is that transition times below 10 (1 second) don't work in scenes.

That's because every transition time below 1 second is raised to 1 second before add scene command is send to the lights. There is also an alternative enhanced add scene command which supports 1/10 s transition time. But there needs to be more testing if this is supported by all lights or if they must be treated separately.

I think you can recall a scene in deCONZ specifying a transition time as well.

No, the transition time is stored on the lights with the scene, so they can recall the scene with proper fading after receiving the command. Which is quite nice since scene supporting light switches like the ones from Busch-Jaeger, JUNG and GIRA just send the recall scene xy commands.

[snozzlebert]

I don't think the Hue bridge stores transitiontime with a scene, but it's specified when recalling a scene (through a PUT of /groups/xx/action with a body of {"scene": "yyy", "transitiontime": n}).

The Hue bridge does store the transitiontime in the bridge with a scene and it is not possible to specify it when recalling the scene. A (version 2) scene with details from my Hue bridge:

"kFQmblgdmyIln3l": {
    "name": "Watching a movie",
    "lights": [
        "3",
        "5"
    ],
    "owner": "********",
    "recycle": true,
    "locked": true,
    "appdata": {},
    "picture": "",
    "lastupdated": "2017-01-11T11:49:57",
    "version": 2,
    "lightstates": {
        "3": {
            "on": true,
            "bri": 90,
            "ct": 443,
            "transitiontime": 20
        },
        "5": {
            "on": false,
            "transitiontime": 20
        }
    }
}

And according to https://developers.meethue.com/documentation/groups-api#253_body_example recalling a scene only uses the scene id on the group action.

PUT /groups/<group_id>/action
{
	"scene": "kFQmblgdmyIln3l"
}

I think you can recall a scene in deCONZ specifying a transition time as well: POST to /groups/xx/scene/yy/recall with a body of {"transitiontime": n}.

deCONZ does not support this. Recall is a PUT action and the body is ignored. Specifying transitiontime has no effect.

It would seem every manufacturer uses different transitiontime defaults for lights as well as for the gateway/bridge, resulting in a myriad of different behaviours when combining lights from multiple vendors.

I don't think this have something to do with the defaults of the lights. The transition time is related to the scene.
I think I've found something in zcl_tasks.cpp that confirms my observation. If you are using transitiontime of 4 in scenes, it will result in a transitiontime of 0 seconds when recalling the scene, because it is stored as 0.

The addTaskAddScene function shows on line 946:

uint16_t tt = floor(l->transitionTime() / 10); //deci-seconds -> seconds

So 4 becomes 0, 10 becomes 1, 19 becomes 1, etc.

Other tasks like addTaskSetBrightness, addTaskIncColorTemperature, addTaskSetXyColor, etc
do use the deci-deconds value for transitiontime without modifying it (e.g. line 170):
stream << task.transitionTime;

Storing a scene with transitiontime below 10 will always result in a transition time of 0 seconds, no matter what type of light is used.

In deCONZ GUI using "Move to level" on the "Level control" cluster you can specify transtition time in deci-seconds. I think this command is also used by addTaskSetBrightness.
When I use the "View a scene" command on the "Scenes" cluster for my scene group 0x0001 scene 0x01 I see the transition time of 0x0001, which is in seconds.
However, there is also a "Enhanced view scene" command which returns "Transition time 10" (no hex notation) for the same group (0x0001) and scene (0x01), which is deci-seconds.

So I found out that there are two types/version of scenes: "scenes" and "enhanced scenes". It looks like that only viewing of the "enhanced scenes" is supported in deCONZ. Adding "enhanced scenes" is missing. I saw in some ZLL documents that this is command 0x40 for add enhanced scenes instead of 0x00 for adding a "normal scene".

I'm pretty sure that the Hue bridge uses the "enhanced scenes", which gives a more fine-grained control of transition time in scenes. I would be nice if enhanced scenes are also supported by deCONZ.

[manup]

Cooking something up which can be testest with < 1 s transition time..

[snozzlebert]

Thanks for the explanation @manup.
I didn't saw your reply when I was submitting my comment.
It is nice to have the initial support for "enhanced scenes" for transition times below 1 second.

But there needs to be more testing if this is supported by all lights or if they must be treated separately.

I understand. I only have Philips lights at the moment, so I can't help with that.
I have changed the title of this issue to "Support for Enhanced Scenes".

[manup]

Hi, could you test it with version 2.04.65? The 1/10th second transition times should work there (at least with hue lights).

[snozzlebert]

1/10th second transition times work for transition times below 10 (1 seconds) now (in 2.04.65) when used in scenes (with Hue lights).
Based on 6c6e703 is assume that 15 still results in a transition time of 1 second? I haven't tested that yet. It is also less important to me.

[manup]

Based on 6c6e703 is assume that 15 still results in a transition time of 1 second? I haven't tested that yet. It is also less important to me.

That's right for now I'd like to keep it this way in order to support both methods, when more testing with various lights verify that all support the sub second times, the code can be changed to always use it.

[stale]

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.

[ErnstEeldert]

@manup What is the status on this one? I can provide testing of the various IKEA lights, if that helps.

[stale]

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.