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 18.104.22.1680, 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:
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.
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:
I send an off command to the Office group device:
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.
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:
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 --
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 --
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!
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.
I send a set level 50 command to the Office group:
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.
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:
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).
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.