[Solved] Groups App - inconsistent master/slave behavior for dimmer groups?

[veeceeoh]

I am trying to create a rule / rules in RM that uses a motion detector to turn my office lights on/off, but with a dimmer group as a switch restriction that disables the rule, as sometimes my sitting at my computer isn't enough motion to be detected.

But I'm finding what seems to be an inconsistent master/slave relationship in dimmer groups which is preventing me from using the group as a switch restriction. And in my testing, I've identified some other apparent quirks.

For everything I explain below, I am running Hub version 1.0.7.710, and the dimmer devices I am using with groups are all Sengled E11-G13 Zigbee bulbs using the Hubitat's Generic Zigbee Bulb device driver.

I have created several dimmer groups of my Sengled bulbs, and in my testing, on/off/set level commands sent from the device details page for the group work as expected. Of note, 1) if the group is currently off, setting any level other than 0 will turn the group on and set the requested level, and 2) Any set level is persistent in subsequent off/on commands until the level is set to a different value.

As far as I can tell, when a dimmer group is created, the first member of the group alphabetically acts as a "master", but only to change its associated group's on or level state, but not for a change to off, and although the group's state is changed, the other members of the group are unaffected.

I will use screenshots from a simple dashboard of a group device and its members to illustrate a sequence of actions and their results. Here is my starting point:

1. I send an on command to Office Light 1:
   
   As a result, the Office group's state is changed to on, but the other two Group members remain off. This behavior prevents me from using a motion detector rule that turns on/off the 3 members of the group, but uses the group as a switch restriction, because as soon as motion detection = true turns on Office Light 1, 2, & 3, the rule is immediately disabled by the Office group state changing to on, following Office Light 1's "master" state.

2. I send an off command to Office Light 1:
   
   As a result, Office Light 1 turns off, but the state of the Office group remains on. This is the inconsistency in behavior. I can't think of any logical reason why changing a master member of the group to on would cause the group itself to turn on, but turning off the master member would not cause the group to also turn off. This inconsistent behavior is the similar for set level - but only with regards to the off state, as we'll see:

3. I send an off command to the Office group device:
   

4. I send a set level 50 command to Office Light 1:
   
   Again, the Office group's state is changed to match the "master" device, Office Light 1, but the other members are unaffected.

5. I send a set level 0 command to Office Light 1:
   
   The Office group's level is set to 0, but unlike with Office Light 1, the group is not set to off. As a side note, I found that in Hubitat Dashboard, if I set any dimmer device to either 100% or 0%, nothing happens, i.e., the set level command is ignored, or doesn't happen. Now let's see if changing the state of other members of the group have any effect on their associated Group device:

6. I send a set level 25 command to Office Light 2, and a set level 75 command to Office Light 3:
   
   In both cases, the Office group's state remains unchanged. So the other members of the group do not act as masters to change their associated Group's state to on or affect its set level. The same is true if I turn them off --

7. I send an off command to Office Light 3 and Office Light 2:
   
   Again, changing the state of the other members has no effect on their associated group device. Now let's see how changing the group's on/off state affects things --

8. I send an off command to the Office group:
   
   No effect on the state of the group's members, but they were all already off, of course!

9. I send an on command to the Office group:
   
   This seems inconsistent to me. There was no change in level, so it seems the members should only have their state changed to on, to follow the behavior seen when the on/off state is changed on either a physical dimmer device or a dimmer group, i.e. the level is persistent - as mentioned above, and also seen in the previous test #8, where turning the group off left all member's levels intact.

10. I send a set level 50 command to the Office group:
    

11. I send a set level 25 command to Office Light 1:
    
    The other members remain unaffected, but the change is applied to the Office group.

12. I send an off command to Office Light 1:
    
    I'll stop here, because if the state of Group is meant to reflect the state of its members, it really seems it's not doing that consistently.

Based on all of this, I would suggest either:

1. Matching a change to off of the master member to its associated group - if the functionality of groups requires that it acts as a slave to the state of its master member, or

2. Remove the master/slave relationship between the first member of a dimmer group and the group itself, so that independent changes can be made to the individual members of a group without affecting the group's state.

Besides that, there is also addressing the inconsistency in terms of persistence of dimmer levels when a group is turned on (levels change) versus off (levels persist).

Also, regardless of what is or isn't changed, the limitations / behavior of Groups should be documented so that people can understand how they will or won't work in RM rules.

[bravenel]

@veeceeoh

Based on all of this, I would suggest either:

Matching a change to off of the master member to its associated group - if the functionality of groups requires that it acts as a slave to the state of its master member, or

Remove the master/slave relationship between the first member of a dimmer group and the group itself, so that independent changes can be made to the individual members of a group without affecting the group’s state.

Besides that, there is also addressing the inconsistency in terms of persistence of dimmer levels when a group is turned on (levels change) versus off (levels persist).

All of these are tied up in the same thing, the implicit master/slave of the first device. That is actually an unneeded artifact of a previous incarnation of this app, and will be removed. The resulting behavior is that levels persist from off, and on causes those levels to be set. Set level is independent, and causes a new group level to be set (which persists when turned off).

Will this change address your concerns?

[veeceeoh]

Yes, I believe so - thank you, Bruce!

[bravenel]

This bug has been fixed with Hub Update 1.0.8. There is no longer an implicit master/slave arrangement with the first selected device.

[guyeeba]

I think I should revive this topic, because IMHO dimmer groups are still behaving... oddly.

I have 8 bulbs in one room, they're grouped, I can control them using the group bulb dimmer, or individually. It's working fine, except one thing. The group bulb dimmer's on/off state doesn't follow the state of the physical devices (opposed to scenes that activate themselves when all the members are set to a predefined state).

I totally understand that the group device may have a third, indeterminate state, when there are bulbs with different states in the group. But I think the group device should follow the state of members at least when the state of all members in the group is the same (on/off). Or with any other logic, but I can't really imagine a scenario where it would cause problems...

In my case the bulbs are grouped because I want them to do the same all the time, I don't want to control them individually. So I put a tile on the dashboard (for the group dimmer), and it does what it should, except when I set the brighness of the group when it's turned off. Then is sets the bulbs' brightness, they turn on, report back their brighness and on state, but the group dimmer remains off. It's quite odd...

Here's a video of the phenomemon with a tile for the group dimmer and all the members, maybe it makes it easier to understand what's wrong with it (sorry for the quality, it's my first animgif, but the important parts can be seen I hope):

Is there a specific reason why it works this way?

[bravenel]

The Group device was not designed to reflect the state of the group member devices, or, put another way, the app wasn't designed to do that.

I will look into it, but first blush, it will introduce new overhead into the app, as it would have to subscribe to each member device's events, and upon each one check the overall condition of the group.

[guyeeba]

@bravenel

it will introduce new overhead into the app

Ummmm, yeah... what about making it optional?

[jon1]

it looks like the group set level is triggering the members to set level and turn on, not just set level, no? or is the issue that these devices are turning on by themselves when they get a set level command when they perhaps shouldn't be?

[guyeeba]

Probably the bulbs turn on automatically (which is fine for me, that's why I want to set their brightness: to have a certain level of light), but they send a report about it, so they do everything they can. As you can see in the video, their "bulb" tiles are updated, but the "group bulb" tile remains off, which is not exactly what you'd expect from the virtual appearance of the very same bulbs.

In some cases this unidirectional behavior is totally acceptable, but in certain cases (mine, for example) it should be two-way, the logical group should reflect the state of its physical members as close as possible.

[guyeeba]

Oh, by the way the zigbee standard defines two different "move to level" commands in level control cluster: one of them adjusts the OnOff attribute of on/off cluster (0x04), the other (0x00) does not.

So whatever the bulbs are doing, it's compliant to the standard.

[troywehrle]

I would agree with the sentiment mentioned here on the confusing behavior of group devices and members.

Groups have the optional ability to mark themselves as on, whenever a member goes on. But they are lacking the option to mark themselves as off, if any member goes off. Both options should be available for consistency, so that if groups are being used on dashboards, we can have consistent user experiences.

[bravenel]

@troywehrle

Both options should be available for consistency

I will look into adding this feature.

[troywehrle]

Thank you, sir.

[bravenel]

You realize, I presume, that the two choices are mutually exclusive. If you choose to show on if any group member is on, you can't also show off, if any group member is off -- and vice versa.

[troywehrle]

I would think that entirely depends on how the functionality is developed. If you offer the option(s) as two distinct choices per each group, then I would think a user could adjust them to be mutual exclusive/inclusive or disparate.

My use case is specifically for dashboard tiles, when you have tiles for discreet lights and also tiles for grouped lights on the same dashboard. From my perspective, I think the intuitive user experience for on events, is that when a single light tile is on, that it does not present the group as on. Only when all lights in the group are on, would I expect the group to present as on. Correspondingly, when a single light in the group is off, I would expect the group to present as off. From my experimentation, scenes appear to work this way, but groups do not.

[bravenel]

@troywehrle

I think the intuitive user experience for on events, is that when a single light tile is on, that it does not present the group as on.

The feature that exists now is "Use indicator device to indicate if any members are on". This came about because of a user request for this feature, so obviously their use case was different than yours, and their "intuitive user experience" different as well.

It sounds like what you want is the full laundry list of possible uses for the indicator:

1. On if any on
2. On only if all are on
3. Off if any off
4. Off only if all are off

Of those, 1 and 2 are mutually exclusive, 1 and 3 are mutually exclusive, 2 and 4 are mutually exclusive, and 3 and 4 are mutually exclusive. 1 and 4 are currently available and have the same meaning. If I add 3, then 2 and 3 would be available and have the same meaning.

So of the 4 possible combinations of setting the two selectors (On if any on, and Off if any off), there are only two possible different actual choices:

On if any on == Off only if all are off

and

Off if any off == On only if all are on

You can only have one of those be true for any given group. If both choices are off, then the indicator light simply reflects the last change made to it, and has nothing to do with the status of the group members.

@troywehrle

If you offer the option(s) as two distinct choices per each group, then I would think a user could adjust them to be mutual exclusive/inclusive or disparate.

So this isn't really true or possible. You either get any-on/all-off or all-on/any-off.

[troywehrle]

Agreed. Thanks for considering to add the other option.

[bravenel]

This option for the group device to be off if any of the group members are off has been added in the latest hot fix release.

Release 2.1.5 Available

Release 2.1.5.124 Available This hot fix release includes the following fixes and features: Fixed an issue with Rule Machine where Global Variable Connectors would break if you changed the Connector device label. Now, the Connector device label can be freely changed. DO NOT change the device name. Added a feature to Motion Lighting to allow a contact sensor to turn off the lights when closed. Added a feature to Group 2.0 to allow the group device to be Off if any of the lights in the group a…

[ardjanbarnas]

Instead of all this mutual exclusive stuff limited to a binary on/off state, you could have just had three states:

On
Off
Partial On

[mike.maxwell]

@ardjanbarnas

Partial On

Yes, unfortunatly partial on is a bit meaningless in the context of a single switch...
It makes sense for a group and scene schema, but currently those aren't defined in our capability set.