Scene API about deconz-rest-plugin HOT 18 CLOSED

Yes there is a planned adaption of the scenes API without groups. But it's more complicated when it seems in first place.

On ZigBee level every scene belongs to a group, this is why deCONZ uses the /group/<id>/scene/<id> scheme. A scene is stored in the lights nvram (scenes cluster) and can be recalled with a simple group command for a given scene id. For example a battery powered light switch doesn't need to know the scene details for 50 lights, it just needs to send one command, like recall scene 1 and can go back to sleep afterwards, all lights will tune in the scene at the same time.

This has the benefit that the gateway doesn't need to be involved at all since the light switch can directly control the lights.

The adaption will either use a special group, the so called global group 0x0000 or a random internal group to keep the benefits of ZigBee scenes. However ZigBee scenes implementation is quite sophisticated:

• scenes must be installed on the lights
• changes or removal of scenes must be maintained in lights
• the gateway shall verify periodically that scenes on the lights are correct
• lights might be not reachable or busy with updates, so implementation must be robust to not assume everything works on first try
• scenes might be installed, removed or changed by other devices like a remote or light switch

There was the idea of handling all scenes just by the gateway, so when a scene is called the gateway sends the needed commands to the lights. I think this is how hue bridge handles scenes (or at least did in the past). That's fairly simple to implement but doesn't scale at all. For example we have projects with > 150 lights, sending out 400 commands just to tune in a scene would be overkill. And it looks terrible too since not all lights would react instantly but sequentially.

from deconz-rest-plugin.

For v1 scenes, the Hue bridge stores scene light states solely in the lights. When recalling a v1 scene, the lights are updated immediately, but it takes the Hue bridge several minutes (in my case; 38 lights) before it reports the changed light states. The Hue API documentation suggests that group commands are broadcast on the ZigBee network and the lights seem to update simultaneously.

For v2 scenes, the Hue bridge stores the scene light states in the lights and in the bridge. When recalling a v2 scene, the lights are updated immediately, and the bridge immediately reflects this. However, I've seen some very funny behaviour, when the scene light states on the lights differ from the scene light states on the bridge. This typically happens when updating a scene's light states while the lights are still changing (e.g. with a longer transitiontime), or when the bridge cache hasn't yet been updated with the actual light states. It would seem like the bridge sends a scene recall broadcast as well as individual commands to update each light state from scene light states stored on the bridge.

Another funny bit: the Hue api allows a scene to be recalled from any group. Only the lights that are in the scene and in the group are updated. I've defined my scenes with lights from multiple rooms, and recall them per room, using the room group. Looking how the Hue scenes were discovered by deCONZ, the scenes are linked to the /groups/0 group on the bridge. Note that deCONZ has discovered this group as a regular group, with a a different group ID than 0x0000.

from deconz-rest-plugin.

The "random internal group" might be the way to go. Would there be enough groups to create a group for each scene?

from deconz-rest-plugin.

Yes groups should be no problem, ZigBee groups use a 16-bit address space which is roughly 64k groups. The available Raspberry Pi memory is more than capable. The only limit is set by lights, some only support being in at most 8 groups. But a group may contain up to 255 scenes, which due light memory limit is often about 16 scenes max (which is ok in most cases).

from deconz-rest-plugin.

The only limit is set by lights, some only support being in at most 8 groups.

Philips: 24, OSRAM: 8, innr: 16, if I read the deCONZ GUI correctly.

But a group may contain up to 255 scenes, which due light memory limit is often about 16 scenes max (which is ok in most cases).

Philips: 50, OSRAM: 16, innr: 24, again if I read the deCONZ GUI correctly. I think this is the overall scene capacity on the light, not per group?

Another funny bit: the Hue api allows a scene to be recalled from any group. Only the lights that are in the scene and in the group are updated.

When I recall a scene using a room group on the Hue bridge, the Wireless Light Control updates the lights immediately as if the scene were applied to all lights (apparently, it listens in on the broadcast?). It then takes quite some time to show the correct state light by light (apparently when polling each light?).

from deconz-rest-plugin.

The limits match to what I observed, the OSRAM limits seem to be low but should suit most real world needs.

When I recall a scene using a room group on the Hue bridge, the Wireless Light Control updates the lights immediately as if the scene were applied to all lights (apparently, it listens in on the broadcast?). It then takes quite some time to show the correct state light by light (apparently when polling each light?).

Yes deCONZ listens for incoming broad- and group-casts and tries to be clever to update light state. Not perfect but works well for switches. The poll handling of lights will be improved a lot in the next releases. Hopefully in the midterm future attribute reporting of lights will improve the overall responsiveness.

from deconz-rest-plugin.

the OSRAM limits seem to be low but should suit most real world needs.

Yes. And they do offer the functionality to set the light power-on state. I'd gladly trade half the of groups and scenes on the Philips lights for that feature.

Hopefully in the midterm future attribute reporting of lights will improve the overall responsiveness.

I did ask Philips on the Hue developer forum if they could implement this with a firmware update of the lights, but they gracefully ignored my question...

from deconz-rest-plugin.

The "random internal group" might be the way to go. Would there be enough groups to create a group for each scene?

This is actually how the Hue bridge works internally (as observed through sniffing). /groups/0 isn't group 0x0000, but a random (?) group that's added to each light upon joining the network. All scenes are attached to this group.

This also explains how they can do a scene recall in combination with a group, so that only the lights that are both in the scene as well as in the group are affected: they just use different groups in the groupcast address (the one specified in the API) vs the recall scene command (the internal group for /groups/0).

from deconz-rest-plugin.

I really think we want to support the Hue bridge scene API, o.a. to enable gateway cascade to the Hue bridge (see #287). We would probably need to continue to support the current scene API, not to break existing applications. This is quite a change:

1. Create a hidden group (with a random number?) for /groups/0. For new installations, do this on initialisation; for existing on database load;
2. Assign each light to this hidden /groups/0. For new lights do this on pairing; for existing lights on database load;
3. Change groups.cpp to use groupcasts to this hidden group for /groups/0 instead of broadcasts - I suppose/hope this won't break anything?
4. Create a new rest_scenes2.cpp to handle the /api/username/scenes REST calls. Probably can re-use the logic from scene.cpp;
5. Enhance gateway.cpp to distinguish scenes from old vs new scene APIs and issue the appropriate API to the cascade gateway / bridge.

@manup, what's your vision on this? As a quick fix, we could just hack gateway.cpp and issue the Hue API command when the bridgeid of the cascade gateway has a vendor prefix of Philips.

from deconz-rest-plugin.

As a quick fix, we could just hack gateway.cpp and issue the Hue API command when the bridgeid of the cascade gateway has a vendor prefix of Philips.

Hm, we would need a way to map the deCONZ group/scene to the Hue bridge scene name. As the scene name is generated by the bridge when creating a scene), we'd need a cascadescene. Still doable, but not quick...

EDIT: While deprecated, v1 scenes can still be created on the Hue bridge (using PUT of /scenes/id), so we can use a naming convention to map the deCONZ gateway scenes to Hue bridge scenes. I'll be mapping /groups/12/scenes/1 to /scenes/g12s1. See PR #338.

from deconz-rest-plugin.

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.

from deconz-rest-plugin.

I think we need to keep this on the list:

• Hue bridge uses resource numbers for /groups instead of the ZigBee group ID;
• Hue bridge creates a regular group, exposed as /groups/0 and assigns all lights to that group on pairing;
• Hue bridge creates scenes for this group, enabling the /scenes resources and enabled recalling a scene to another group (by sending the recall scene command for the /groups/0 scene to the other group's multicast address).

from deconz-rest-plugin.

I think we need to keep this on the list:

Definitely :)

from deconz-rest-plugin.

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.

from deconz-rest-plugin.

Bump

from deconz-rest-plugin.

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.

from deconz-rest-plugin.

Bloody bot...

from deconz-rest-plugin.

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.

from deconz-rest-plugin.