Scenes

[manup]

The current handling of scenes doesn't work very well for some devices and has some general issues. Here is a first draft how to approach a new scenes implementation. It's not complete but should provides a base for discussion and comments.

Observations

• Color temperature issue in IKEA lights, ct can only be set and recalled when the scene was created by store scene;
• At least IKEA GU10 don't support scenes where off = true, the albeit attributes are updated correctly the light doesn't turn off. Once in this state the lights can not be turned off with a normal Off command only Off With Effect works, or as alternative a prior On command needs to be sent;
• Add Scene command to initially create a empty scene with a transition time works.
• Store Scene command afterwards to set scene state but keeping transition time works.
• Add Scene command not supported correctly for IKEA and OSRAM/LEDVANCE to set scene state and perhaps others;
• View Scene command doesn't always return the actual scene attributes but at least a valid transition time;
• Get Scene Membership for a group works;
• There is currently no solutions for devices which don't support Zigbee scenes;
• There is no mechanism yet to fix broken Scenes.

The future implementation as part of the Device state machine needs to be able to do the following tasks. These are described in a coarse state machine.

Device scene specifics

• The device description files can indicate that a device supports Zigbee scenes and perhaps some details like if some attributes aren't supported in Zigbee scenes;
• Each Device has a non persistent property active scene which can be null, it is used to let the state machine react to scene changes or when a scene isn't active anymore due non scene state changes.

Create a scene

• A Scene is created or modified via REST-API;
• The scene state is either given in the REST-API request or the current device state when no state is provided in the request;
• If the current state is used an empty Add Scene with transition time followed by Store Scene broadcast is sent. This is only done to speed things up, it doesn't matter if the request fails or even when some devices of the group are powered off or don't support Zigbee scenes;
• The scene is saved in the database.

Recall a scene

• Depending on the REST-API request a scene can be recalled for a single device or the whole group;
• A Recall Scene unicast or group cast is sent to the device if it supports Zigbee scenes;
• After that move on to "Verify scene after recall".

Verify scene after recall

• If the device supports Zigbee scenes:
  • Wait till transition time is reached;
  • Read Scenes cluster attributes current scene (0x0001), current group (0x0002) and scene valid (0x0003);
  • If any of these don't reflect the should be state move on to "Set scene state";
  • If the Scenes cluster claims scene is valid move on to "Verify scene state";
• If Zigbee scenes aren't supported move on to "Set scene state".

Remarks: IKEA lights set scene valid attribute to false for On/Off and Brightness commands but not when changing only the color.

Verify scene state

• Verify transition time with View Scene command if the device supports Zigbee scenes;
• Verify other ZCL attributes via their respective clusters like on/off, level, color temperature, etc.;
• If any of those fail move on with "Set scene state".

Store scene state

• Send unicast Add Scene command with the transition time;
• Send unicast Store Scene command to save the state;
• The device might return scene table full or another error, this can be remembered and reported via API to the user.

Set scene state

• Send unicast commands like on/off, move to level, etc to bring the device in the correct state;
• If every device has the same state in the scene group casts can be used;
• If the device doesn't support Zigbee scenes or the scene table is full the transition time is used in the cluster commands;
• The state is verified as described in Fault Tolerance;
• If the device supports Zigbee scenes move on to "Store scene state".

Notes

• Scenes are always recalled correctly;
• If a device supports Zigbee scenes and is already configured properly the recall is fast via group casts;
• Broken or non existent Zigbee scenes are fixed automatically, also when a device is repaired;
• Devices which don't support Zigbee scenes are supported;
• If a Zigbee scene limit is reached on a device recalling a scene still works;

Related: https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3497

[ebaauw]

I think this will work, but to be honest, it looks a bit over complicated to me.

In addition to Recall Scene, I’d simply send unicast commands to the lights that:

• Aren’t whitelisted to support the Scenes cluster sufficiently;
• Lights whose Scenes table is full (so part of the “sufficient” support is reporting correctly the available entries).

You could loop over all lights sending a unicast Store Scene for confirmation that the (whitelisted) light has actually accepted the scene.

I think it’s more the responsibility of the API client to implement non-Zigbee scenes (and groups).

[manup]

Thanks for the review, I have to admit it has a certain complexity :) but within the state machine it's rather simple to implement with (hopefully) very little maintenance, surprisingly the actual code is relative small for what it can do. I'd really like to aim for a max. robust solution which just works, plus implicit goodies like auto repairing scenes and no scaling issues. Mainly because this can get rid of all issues users are currently facing and to bring related support cases down.

In addition to Recall Scene, I’d simply send unicast commands to the lights that:

• Aren’t whitelisted to support the Scenes cluster sufficiently;
• Lights whose Scenes table is full (so part of the “sufficient” support is reporting correctly the available entries).

I agree this should happen right after recalling a scene for such devices. Basically it's a fast forward to the "Set scene state" state.

You could loop over all lights sending a unicast Store Scene for confirmation that the (whitelisted) light has actually accepted the scene.

This is done in the "Store scene state" automatically after a scene state has been set, I think this should do the trick.

I think it’s more the responsibility of the API client to implement non-Zigbee scenes (and groups).

Here the problem is that this would bring the burden to understand and communicate that to the end user. Users usually don't understand nor care about this, they have their lights and want to use scenes. Since the "Set scene state" state is used for both kinds of devices there is little overhead to support devices which don't have Zigbee scenes, we only need move to that state and machine will do its thing. The related REST-API and end user interfaces has one unified solution which is hopefully simple to understand and use.