Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support changing per device scene states #3633

Merged
merged 1 commit into from
Jan 9, 2022

Conversation

RobertMe
Copy link
Contributor

@RobertMe RobertMe commented Jan 6, 2022

This is my first PR on Zigbee2mqtt to please bear with me :)

As per the discussion in the original ticket to add scenes support to Zigbee2mqtt scenes are stored in the lights based on a scene id and group id for which the group id defaults to 0 when setting the state on a light (using zigbee2mqtt/<light name>/set). This means one can currently only store a whole group of devices or add a whole group of devices with the same state. With this change one can call scene_add (or scene_store) on a light and by specifying the group_id the scene will be bound to that group.

So in short this allows:

  1. Create a group with 5 lamps
  2. scene_store or scene_add a scene for all lights in the group
  3. Call scene_add on zigbee2mqtt/<light name>/set to override the state of a single light

Up for discussion is whether the same change should be applied to scene_remove as well. My guess (but didn't test) is that this would thus prevent such light to change it's state when a (group) scene is applied.

Allow specifying a group_id when storing or adding a scene to a device.
This way one can first create a scene on a group, and afterwards change
the state for individual devices within the group. This is especially
usefull when one wants to use per device transitions.
@Koenkk
Copy link
Owner

Koenkk commented Jan 7, 2022

@RobertMe
Copy link
Contributor Author

RobertMe commented Jan 7, 2022

Sure, I will try to do so during the weekend

* Have you checked that the correct state is published to MQTT when restoring the state?

Nope, I didn't, but I just did :). The states as published for my Hue lights is correct and lights with a differing state also reflect this in the published messages.
One small sidenote though is that the state of the group is updated multiple times and reflects that of the light which was updated "last". So when having four lights in a group, 1, 2, 3 and 4, then when for example 2 has a different state then you might / will get the situation where the following messages are published:

  1. 1 updated to [common state]
  2. Group updated to [common state]
  3. 2 updated to [custom state]
  4. Group updated to [custom state]
  5. 3 updated to [common state]
  6. Group updated to [common state]
  7. 4 updated to [common state]

(There doesn't seem to be a group update after light 4 changed, I presume because the state didn't change since the last message).

BTW: Personally I don't think this is part of this PR. This as previously one could already set multiple lights in the same group to a different state, after which one could store the group as a scene. So using those steps one could already create a scene without all lights having the same state.

@RobertMe
Copy link
Contributor Author

RobertMe commented Jan 8, 2022

Done :) Koenkk/zigbee2mqtt.io#1127

@Koenkk
Copy link
Owner

Koenkk commented Jan 9, 2022

thanks!

@Koenkk Koenkk merged commit b1fd7eb into Koenkk:master Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants