Yes, I believe so - thank you, Bruce!
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.
1 Like
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?
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.
Ummmm, yeah... what about making it optional?
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?
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.
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.
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.
I will look into adding this feature.
Thank you, sir. 
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.
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.
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:
- On if any on
- On only if all are on
- Off if any off
- 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.
So this isn't really true or possible. You either get any-on/all-off or all-on/any-off.
Agreed. Thanks for considering to add the other option.
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.
1 Like
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
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.
Tested this with my groups and dashboards and it is working perfectly. Thank You!
