Scene Support

[sti0]

As mentioned in #764 it would be nice if zigbee2mqtt supports scenes like the Hue bridge.

Scene support should solve the problem that bulbs in a room won't turn on together if they are not in a group (you have to call them one-by-one). When they are in a group it's only possible to set one color for all bulbs. Scene support allows to set different colors to different bulbs and they turn on immediately together if the scene is called.

There are different ways to achieve a solution.

Some points to discuss:

• How to define a scene?

1. Define a scene within a JSON payload and call it (store the scene information outside of zigbee2mqtt)
2. Define a scene in a scenes.yaml in the config folder. (store scene information inside zigbee2mqtt and call it just by a name or id)

• Must scenes belong to a group?

• Will scenes affect lights only?

• How to change a scene?

There are many other points to clarify. This is only a starting point. Other thoughts und ideas are welcome.

[sti0]

Some proposals:

Defining a scene

Setting a scene via MQTT could be done by a JSON payload inspired by the z2m color setting

{
    "sceneName": "Some Scene",
    "devices": {
        "friendly_name1": {
            "brightness": 255,
            "color_temp": 155,
            "color": {
              "x": 0.123,
              "y": 0.123
            }
        },
        "friendly_name2": {
            "brightness": 255,
            "color_temp": 155,
            "color": {
                "r": 46,
                "g": 102,
                "b": 193
            }
        },
        "friendly_name3": {
            "brightness": 255,
            "color_temp": 155,
            "color": {
                "hex": "#547CFF"
            }
        },
        "friendly_name4": {
            "brightness": 255,
            "color_temp": 155,
            "color": {
                "hue": 360,
                "saturation": 100
            }
        }
    },
    "transition": 2
}

Storing a scene

This would be stored in a scenes.yaml

sceneName: Some Scene
devices:
  friendly_name1:
    brightness: 255
    color_temp: 155
    color:
      x: 0.123
      y: 0.123
  friendly_name2:
    brightness: 255
    color_temp: 155
    color:
      r: 46
      g: 102
      b: 193
  friendly_name3:
    brightness: 255
    color_temp: 155
    color:
      hex: "#547CFF"
  friendly_name4:
    brightness: 255
    color_temp: 155
    color:
      hue: 360
      saturation: 100
transition: 2

Topics:

• Add a Scene zigbee2mqtt/bridge/config/add_scene
• Remove a Scene zigbee2mqtt/bridge/config/remove_scene
• Activating a Scene zigbee2mqtt/bridge/scene/[Scene_Name]/set

Others

• Scenes can be overwritten. If an existing scene is added again, it will be remove first and added again
• Scenes don't belong to a group (see next point)
• Scenes could can be expanded for other devices like switches later
• Maybe a STATE attribute makes sense to turn off specific lights (or later turn on/off switches). This should be discussed. On my above proposal a state setting to "ON" is implicit.

[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.

[ndfred]

I would appreciate this feature as well, a few of my rooms are a mix of:

• hue color bulbs, which only accept color: {rgb:} commands to set their temperature (setting color_temp: does nothing)
• hue color ambiance bulbs, which only accept color_temp commands to set their temperature (setting color_temp: does nothing)
• hue power plugs, which obviously cannot change their brightness or color

When I dim the room, I adjust the color temperature as well as brightness. When I go below a certain brightness I cut power to the plugs. Currently I need to define two groups (dimmable and non dimmable) to cut the power to the plugs and reduce the brightness on the remaining bulbs. For the bulbs, I need to send the temperature and RGB values in addition to brightness which then get split into 3 different Zigbee commands. That means the bulbs will visibly perform these instructions in sequence (reduce brightness, adjust temperature, adjust RGB values). Supporting scenes would presumably perform this transition in one step.

Are there any challenges for scenes not to have been implemented so far (maybe support across devices from different vendors is a challenge, not sure how much of a standard scenes are or how they even work), or is it lack of demand that meant other features are prioritized? I am not saying "I need this now", just curious how hard this is to implement.

Edit: my Ikea bulbs on the latest firmware do not obey the transition parameter if I send multiple commands to them, they just switch to that state right away (Hue bulbs will execute the commands in sequence, with animation). I would assume that scenes support would help with that, and allow a group of bulbs from different vendors to behave in the same way.

[kiall]

If my reading of the ZigBee specs is correct, we could probably allow for "manual scene management" pretty easily. I.e. set all the devices the way you want them with a bunch of MQTT messages, then send the store scene command to the group. This would be a lot simpler to implement, and probably more flexible too given a data structure for every possible element of a scene doesn't have to be defined.

[ndfred]

Wouldn't scenes be more suitable for the configuration file, since these are supposed to be stored in the lights very much like groups (correct me if I am wrong, I didn't read the ZigBee spec)?

Digging a bit more into this, I might get away with tracking the state of the bulbs and only calling a set command with the attributes that changed, which most of the time is only brightness really, and which would result in a smooth transition and fewer commands on the network. The only case where I would need to send two commands is when I go from dimmed (2800K and 77 brightness) to nightlight (2200K and 2 brightness), and these would still be a little janky, but I don't use these super often that it wouldn't bother me too much (I mostly switch from off to bright and across bright and dimmed which keep the same color temperature and only really change brightness).

Going that route would mean keeping track of the state of the various groups, which the API doesn't allow: there is no GET command, even though ZigBee2MQTT keeps group states in its cache, presumably because ZigBee disallows fetching group states.

Is there a way to pull the ZigBee2MQTT cached state (what is in state.js) from MQTT? That would allow me to set an initial state when I start my automation script (which interacts with ZigBee2MQTT over MQTT). Pulling group configurations would be useful too so I could detect that individual light state changes affect the group's state (or I could look at implementing change propagation from light to group in ZigBee2MQTT itself, maybe that is already what optimistic does for a group?).

Looking at the documentation, I can call zigbee2mqtt/bridge/config/devices/get but that only retrieves the list of devices and not their cached state, and groups are not listed there. Both could be made public, but I would like to understand why they are not yet: again, my assumption is that groups are stored in the bulbs and ZigBee2MQTT only allows you to query accurate state from ZigBee commands rather than publish what is in its state cache, which might be wrong.

Makes me wonder why there is a state cache at all, I would assume so that ZigBee2MQTT can augment the state information of a bulb if it only broadcast one state update (say a motion sensor only sends its lux settings, ZigBee2MQTT will throw its cached temperature value in the JSON payload)?

[kiall]

Wouldn't scenes be more suitable for the configuration file, since these are supposed to be stored in the lights very much like groups (correct me if I am wrong, I didn't read the ZigBee spec)?

It's been a month or two since I read it, but what what I gather, there is no method to say "scene 1 is bulb A @ 100%+bulb 2 @ 50%".

Rather, you must turn bulb 1 on at 100% and turn bulb 2 on at 50%, then issue a store scene command. For Z2M to treat this like groups, it would have to be turning everything on, storing, turning on to the next scene values, storing, etc. With groups, Z2M does this compare + update at startup, and it's pretty harmless as it doesn't actually turn anything on. For scenes, I'll bet this is a big issue.

Again, it's been a few months, maybe there was a way to do this without actually turning things on - but I don't think there was.

[ndfred]

This is actually a bit less of an issue than I initially thought: after tweaking my script I am now able to animate the Ikea lights on and off (I now specify a transition value, I assumed Zigbee2MQTT set a default one but it doesn't). I am still seeing step-by-step rather than blended animations when I am trying to modify multiple parameters (commonly brightness + color temperature + RGB) but that is not as frequent as animating on and off. I would still appreciate scene support, and might look at it in the future, but am content with my current setup for now.

[jd1900]

I may be wrong, but scenes are stored in the devices, using the genScenes cluster (0x0005), and don't require groups, despite being more powerful using groups. It even allows to copy scenes.

According to this definition (https://www.nxp.com/docs/en/user-guide/JN-UG-3115.pdf):

A scene is a set of stored attribute values for one or more cluster instances, where
these cluster instances may exist on endpoints on one or more devices.

The Scenes cluster allows standard values for these attributes to be set and retrieved.
Thus, the cluster can be used to put the network or part of the network into a predefined mode (e.g. Night or Day mode for a lighting network). 

 A Scenes cluster instance **must be created on each endpoint** which contains a cluster that is part of a scene. 

A scene is often associated with a group (which collects together a set of endpoints over one or more devices) - groups are described in Chapter 12. A scene may, however, be used without a group

That's why in the Ikea Trådfri (see this issue https://github.com/Koenkk/zigbee2mqtt/issues/1232), using a remote can select different scenes and mimics changing temperature, but it is actually just changing scenes that are stored in the bulb.

However, if the bulb "looses" the scenes, you loose of that functionality.

DeCONZ has scenes support (https://dresden-elektronik.github.io/deconz-rest-doc/scenes/), so it could be a start. I'm not sure whether DeCONZ uses actual ZigBee scenes or if it stores it locally in the app (like HA scenes).

But scenes support along with binding can be very powerful to have a resilient smart home as well as less traffic to be sent in the network.

[willu]

Hi all. I'm looking to take a crack at this (in my spare time - don't hold your breath).

I'm looking at the Jan 2016 cluster library spec: 07-5123-06-zigbee-cluster-library-specification.pdf

I plan to try to make these work with groups - if you implement scenes then the zigbee spec requires you also have groups.

The set of scene cluster commands from the zigbee cluster spec that look useful is:

• Add Scene (+ Enhanced version),
• View Scene (+ Enhanced version),
• Remove Scene,
• Remove All Scenes,
• Store Scene

Add Scene allows you to specify:

• Group ID
• Scene ID within the group
• Transition time (The enhanced add scene command allows this to be specified with more resolution)
• Name (up to 16 chars)
• Various attributes (I think this allows you to actually specify the scene details - the attributes you specify depend upon the other clusters supported by the device). These attributes are optional.

View, Store and Remove Scene commands require a group ID and a scene ID. The Remove All Scenes command only requires a group ID. The Enhanced View Scene command looks the same as the View scene command, but you use it if you used the Enhanced Add Scene command to create the scene.

Design preferences:

• It should match the design of the rest of zigbee2mqtt, particularly groups.
• It should use the zigbee scenes cluster (if you want to do scenes yourself, you already can).

So, how can we map this onto MQTT config and topics?

Config: Inside the 'group' configuration, add a new section 'scenes'. This contains a new subsection 'scenes' that contains a list of scene IDs and configuration for that scene.

groups:
  # ID, each group should have a different numerical ID
  '1':
    # Required: Name which will be used to control the group
    friendly_name: group_1
    # Required: Retain messages (true/false) (default: false)
    retain: false
    # Optional: Default transition to be used when e.g. changing brightness (in seconds) (default: 0)
    transition: 2
    # Optional: Change group state when one of the devices in it changes state, see 'State changes' below (default: true)
    optimistic: true
    # Optional: Devices of this group,
    # Note: this has to be the ieeeAddr of the device, not the friendly_name! (default: empty)
    devices:
      - '0x00158d00018255df'
    scenes:
     '1':
      # Required: Name which will be used to control the group (less than 16 characters)
      friendly_name: scene_1
      # Optional: Default transition to be used when e.g. changing brightness (in seconds) (default: 0)
      transition: 2

If a controller is started, then it checks that the appropriate scenes exist on each device in the group (using the Get Scene Membership zigbee command sent to the group). If anything is missing, the appropriate scenes are added to the appropriate endpoints, but not configured.

In the same way there is an add_group MQTT command, we'd add add_scene, remove_scene and remove_all_scenes commands within each group: e.g.

zigbee2mqtt/bridge/group/[GROUP_FRIENDLY_NAME]/add_scene with payload [SCENE_FRIENDLY_NAME].

These commands alter the configuration file appropriately.

Finally there are MQTT commands for controlling the scene.

zigbee2mqtt/bridge/group/[GROUP_FRIENDLY_NAME]/scene/[SCENE_FRIENDLY_NAME]/store with a device name from the group as the payload sends a message to that device to "Store Scene".

zigbee2mqtt/bridge/group/[GROUP_FRIENDLY_NAME]/scene/[SCENE_FRIENDLY_NAME]/store_all sends a message to all the devices in the group to store the scene.

zigbee2mqtt/[GROUP_FRIENDLY_NAME]/scene/[SCENE_FRIENDLY_NAME]/set ignores the payload and sends the Recall Scene command to the group.

One could also imagine commands that act on the scenes in group 0 (the "no group" group), but I'm not sure I'd bother, particularly not for a first pass.

Does this seem like a reasonable design?

If so, I assume the fist step is adding an API to zigbee-herdsman? I assume it would be within the groups object and would mirror that one (for managing the scene configuration). I'm not very familiar with this code, so pointers would be welcome. Am I also going to have to add something to zigbee-herdsman-converters, and then for every device that supports scenes?

[Koenkk]

@willu I would propose to start simple here. It is already possible to send all the required commands to the devices. Here you can find the commands + parameters (https://github.com/Koenkk/zigbee-herdsman/blob/master/src/zcl/definition/cluster.ts#L253), this will match the ZCL spec.

Now for each command you have to define a toZigbee converter. E.g. for the recall command:

scene_recall: {
        key: ['scene_recall'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'recall', {groupid: 1, sceneid: 1}, getOptions(meta.mapped));
        },
    },

Next add this toZigbee converter to the toZigbee array of the device you want to test with (in devices.js).

Now start zigbee2mqtt and send the following command zigbee2mqtt/MY_DEVICE/set with payload {"scene_recall": ""}. This will trigger the toZigbee scene recall converter.

[willu]

Thanks for that pointer Koen! Working on it now. Rather than hard coding the group ID, I'm pulling that from the group you're sending to (if the entity is a group, then use its group ID, otherwise group 0). Rather than hard coding the scene ID, I'm using the value in the json, so:

zigbee2mqtt/MY_GROUP/set with payload {"scene_recall": "1"} should recall scene 1 on the group.

One quick question: For the 'view' command, I want to respond with some data. I could switch to a 'fromZigbee' converter, but then I lose access to the json value in the converter (can I parse that myself from somewhere? meta?). Or I could try to generate a message in the set converter? Thoughts?

[Koenkk]

@willu that is possible, in the convertSet return e.g. return {state: {scene: "some_scene_stuff"}};

[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.

[K-r-i-s-t-i-a-n]

Got scene storing and recalling working with a Hue bulb. Moving forward, I would need some support/direction on how to integrate it with the rest of the framework.

Added toZigbee converters:

    scene_add: {
        key: ['scene_add'],
        convertSet: async (entity, key, value, meta) => {
        await entity.command('genScenes', 'add',
                 {'groupid': value.groupid,
                  'sceneid': value.sceneid,
                  'scenename': value.scenename,
                  'transtime': value.transtime,
                  'extensionfieldsets': value.extensionfieldsets,
                 },
                 getOptions(meta.mapped)
                );
    },
    },
    scene_view: {
        key: ['scene_view'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'view', {'groupid': value.groupid,
                               'sceneid': value.sceneid,
                              },
                 getOptions(meta.mapped)
                );
        },
    },
    scene_remove: {
        key: ['scene_remove'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'remove', {'groupid': value.groupid,
                             'sceneid': value.sceneid
                            },
                 getOptions(meta.mapped)
                );
        },
    },
    scene_remove_all: {
        key: ['scene_remove_all'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'removeAll', {'groupid': value.groupid}, getOptions(meta.mapped));
        },
    },
    scene_store: {
        key: ['scene_store'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'store', {'groupid': value.groupid,
                            'sceneid': value.sceneid},
                 getOptions(meta.mapped)
                );
        },
    },
    scene_recall: {
        key: ['scene_recall'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'recall', {'groupid': value.groupid,
                             'sceneid': value.sceneid},
                 getOptions(meta.mapped)
                );
        },
    },
    scene_get_scene_membership: {
        key: ['scene_get_scene_membership'],
        convertSet: async (entity, key, value, meta) => {
            await entity.command('genScenes', 'getSceneMembership', {'groupid': value.groupid}, getOptions(meta.mapped));
        },
    },

And the corresponding fromZigbee converters:

    scene_add: {
        cluster: 'genScenes',
        type: 'commandSceneAddRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandSceneAddRsp',
            status: msg.data['status'],
            groupId: msg.data['groupId'],
            sceneId: msg.data['sceneId'],
           };
        },
    },
    scene_view: {
        cluster: 'genScenes',
        type: 'commandSceneViewRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandSceneViewRsp',
            status: msg.data['status'],
            groupId: msg.data['groupid'],
            sceneId: msg.data['sceneid'],
            transtime: msg.data['transtime'],
            scenename: msg.data['scenename'],
            extensionfieldsets: msg.data['extensionfieldsets']
           };
        },
    },
    scene_remove: {
        cluster: 'genScenes',
        type: 'commandSceneRemoveRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandSceneRemoveRsp',
            status: msg.data['status'],
            groupId: msg.data['groupid'],
            sceneId: msg.data['sceneid'],
           };
        },
    },
    scene_remove_all: {
        cluster: 'genScenes',
        type: 'commandSceneRemoveAllRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandSceneRemoveAllRsp',
            status: msg.data['status'],
            groupId: msg.data['groupid'],
           };
        },
    },
    scene_store: {
        cluster: 'genScenes',
        type: 'commandSceneStoreRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandSceneStoreRsp',
            status: msg.data['status'],
            groupId: msg.data['groupid'],
            sceneId: msg.data['sceneid'],
           };
        },
    },
    scene_get_scene_membership: {
        cluster: 'genScenes',
        type: 'commandScenegetSceneMembershipRsp',
        convert: (model, msg, publish, options, meta) => {
            return {event:'commandScenegetSceneMembershipRsp',
            status: msg.data['status'],
            capacity: msg.data['capacity'],
            groupId: msg.data['groupid'],
            sceneCount: msg.data['scenecount'],
            sceneList: msg.data['scenelist'],
           };
        },
    },

And add to events.js:

    'addRsp': 'commandSceneAddRsp',
    'viewRsp': 'commandSceneViewRsp',
    'removeRsp': 'commandSceneRemoveRsp',
    'removeAllRsp': 'commandSceneRemoveAllRsp',
    'storeRsp': 'commandSceneStoreRsp',
    'getSceneMembershipRsp': 'commandScenegetSceneMembershipRsp',

Now I can create a scene by e.g.: mosquitto_pub -t "zigbee2mqtt/lamp/set" -m "{"scene_add":{"sceneid":84, "groupid":83, "transtime":2, "scenename":"someName", "extensionfieldsets":[{"clstId":6, "len":1, "extField":[0]}, {"clstId":768, "len":2, "extField":[3, 4]},{"clstId":8, "len":1, "extField":[0]}]}}"

Recall with: mosquitto_pub -t "zigbee2mqtt/lamp/set" -m "{"scene_recall":{"sceneid":84, "groupid":83}}"

Next step for me is to see if I can recall the scene directly with a Ubisys wall switch.

Update: Recalling scenes with a Ubisys C4 wall switch works :-) Update 2: Confirmed working with Hue, Osram, and Innr lights.

[ndfred]

Awesome @K-r-i-s-t-i-a-n! If I want to play with this, do you mind explaining why we’d need to set a group ID here since we are already targeting the bulb? Just so we can recall the scene on a whole group? And do you mind explaining what the different clusters and values you are setting? (I could look it up but am on my phone right now).

Thanks for taking the time to work on this, super encouraging 💯. Would be good to un-stale the issue too as it is obviously being worked on.

[K-r-i-s-t-i-a-n]

According to the specs, scenes are typically associated with groups, but can also be used without. In this case use 0 as group ID.

For the example scenes created above, I include following clusters:

• 0x0006 onOff -> attribute OnOff
• 0x0008 level -> attribute CurrentLevel
• 0x0300 (768) ColorControl -> attribute CurrentX & CurrentY

[K-r-i-s-t-i-a-n]

My use-case includes groups, so a possible way to use scenes could be to publish the scenes commands (add, store, etc.) to groups and distribute the request to all its children. Not sure if a configuration via yaml file is necessary at this point.

@Koenkk: from your perspective, is this a valid path forward?

[Koenkk]

Thanks! Looks good, can you open a PR so I can provide further feedback/questions?

[ndfred]

@K-r-i-s-t-i-a-n: how is defining scenes on groups different from just sending the values directly to a group? If you want to set brightness and color / temperature for instance, would storing and then recalling a scene show up as one Zigbee command vs two if we were sending brightness and color?

In my case I thought scenes would be a good way to send commands to a heterogeneous group of lights. My living room for instance has a mix of Hue power plugs that drive bright bulbs, white ambiance bulbs and old colour bulbs that I really use as white ambiance. I thought scenes would allow me to do:

• Bright: all power plugs on, all smart bulbs at 255 brightness, white ambiance bulbs at 366 colour temperature, colour bulbs set to R 255, G 205, B 120
• Dimmed: all power plugs off, all smart bulbs at 77 brightness, white ambiance bulbs at 366 colour temperature, colour bulbs set to R 255, G 205, B 120
• Nightlight: all power plugs off, all smart bulbs at 2 brightness, white ambiance bulbs at 443 colour temperature, colour bulbs set to R 255, G 161, B 40

The way I thought this would work is by storing each scene with different parameters on the various bulbs and power plugs, then group them all together, and the recalling the scene I want from the group. Do you know if the spec supports such a scenarios?

If it does, then this scenario (which is probably the most complicated there could be) would need some definition in the YAML file, like:

scenes:
  bright:
    - living_room_couch_left_light:
      # Color bulb
      state: ON
      brightness: 255
      color: 255,205,120
    - living_room_ceiling_light:
      # Power plug
      state: ON
    - living_room_bookshelf_light:
      # White ambiance bulb
      state: ON
      brightness: 255
      color_temp: 366
  nightlight:
    - living_room_couch_left_light:
      # Color bulb
      state: ON
      brightness: 2
      color: 255,161,40
    - living_room_ceiling_light:
      # Power plug
      state: OFF
    - living_room_bookshelf_light:
      # White ambiance bulb
      state: ON
      brightness: 2
      color_temp: 443

And you would then be able to recall these scenes either on a group or on a bulb itself through something like an MQTT zigbee2mqtt/living_room_bookshelf_light/set command with a {scene: "nightlight"} payload.

We could also then have these settings available through MQTT, like adding a bulb to a group works.

I'd be more than happy to contribute code, just wanted to know what is possible here as you have read the spec and played with this and I have not :)

[K-r-i-s-t-i-a-n]

@ndfred: Yes, sending the same state/brightness/color/... to all devices from the coordinator can also be accomplished with a group. However

• if the values differ between the devices, we need to send one message per device. With scenes this is one message for all devices (scene_recall), the details are stored in the device itself.
• I use a wall-switch that directly sends the scene recall command, therefore no need for the central coordinator and automation system (thus decreasing latency and increasing availability).

[willu]

It looks like the "events.js" additions from #issuecomment-683421170 are really in zigbee-herdsman/src/controller/events.ts.

I'm putting together pull requests as Koen requested, but it looks like I'll have to split it in two because zigbee-herdsman is separate from zigbee-herdsman-converters. There might also be some minor edits required. I'm going to split those out from the original changes in my branch.

[K-r-i-s-t-i-a-n]

The work on this topic has advanced and is currently under discussion in PR1531.

[Koenkk]

Supported in the dev branch now with big thanks to @K-r-i-s-t-i-a-n .

Docs: https://github.com/Koenkk/zigbee2mqtt.io/blob/develop/docs/information/scenes.md

[sjorge]

I've been poking the scene stuff recently, looks like we do not support view, remove and remove_all... I wonder if we add those we should move scene support to like how we do bindings currently, I think that locations makes more sense?

[jd1900]

I'm looking at the scene support documentation (https://www.zigbee2mqtt.io/information/scenes.html), however I don't see any way to read current scenes.

Is there no way to read/retrieve them?

[sjorge]

Not possible yet, It's on my TODO list.

But the current way the scene_add/remove/recall are hooked up is a bit difficult to do a view as well... so something more akin to binding would probably be needed to do it properly, but I've been kind of putting looking into it off for a while now.

[ndfred]

@K-r-i-s-t-i-a-n: I finally tried out your scene support implementation and it is the best. Lights are much more responsive, transitions are super smooth, and I can easily use scene_store if I want to capture the more advanced scenarios I described above. I particularly like that you can now send a different scene command, and have the bulbs transition to that halfway through a prior transition. Thank you so much for taking the time to build in support!

[RickRiet]

He guys,

i have been fiddling around with this scene inside zigbee while i can easily recall scenes using the coordinator(using node red as logic) i cant seem to figure out how to use the function and scenes without those. I see you used a wall switch can you point me to a way to use scenes when pressing the on button on a hue remote like 1/2/3 times with different scenes behind them? I had a simular setup with the hue bridge where i use the same remote for 2 rooms.

Thanks.

Rick

[jgudtmann]

He guys,

i have been fiddling around with this scene inside zigbee while i can easily recall scenes using the coordinator(using node red as logic) i cant seem to figure out how to use the function and scenes without those. I see you used a wall switch can you point me to a way to use scenes when pressing the on button on a hue remote like 1/2/3 times with different scenes behind them? I had a simular setup with the hue bridge where i use the same remote for 2 rooms.

Thanks.

Rick

Did you ever find a solution for this?

[RickRiet]

He jgudtmann,

no i have not been able to solve this. I moved my coördinator to a spot closer to the switch so that i can do the logic inside node red and still have acceptable latency.

Rick

[sjorge]

I think you need to sniff the traffic to find the scene ID the remote uses.

Then just add that scene

~ sjorge

On 20 Jan 2021, at 19:36, RickRiet notifications@github.com wrote:

 He jgudtmann,

no i have not been able to solve this. I moved my coördinator to a spot closer to the switch so that i can do the logic inside node red and still have acceptable latency.

Rick

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[uncle-fed]

This issue is now closed but there is still no full functionality for reading current scene info. This would be super useful now that we have a frontend available. This potentially gives possibilty to implement a user friendly web interface to act as a scene editor. But we must have "read scene information" feature implemented to allow that. I am not so familiar with low level Zigbee stuff to be able to help, but maybe some pointers, where to start?