Enhancement Proposal - Group Device - Add Pushed, DoublePushed

📢 Feedback Feature Requests
1

This is a suggested enhancement for the Group Device app.

The proposal is to use button pushed and doublePushed attributes to indicate changes to sub-items in a group, as well as for "all on" and "all off" states.

I'd put this in a "very nice to have", but not "critical to have" category.

Reason for Suggestion:

  • There are time when I want to use a group as a trigger when all the sub-items turn on, other times when I want to use it as a trigger when all the devices turn off, and still other times when any device in the group changes.
    As the group function currently, works I can "set indicator if any member is on" or "set indicator if any member is off" but not both (and the fact that you must choose one or the other makes complete sense)

This is all extremely useful and works as one would expect, but I think there is also an easy way for a group to support both "all on" and "all off" indications from the same group setup, as well as "any device in group changes" triggers . . .

Proposed Solution
It occurs to me one can think of a Group kind of like a Zwave switch with central scene. If a Zwave switch is already on, but you tap the paddle up, it remains on, but still generates a button #1 push.
*Similarly, if it is already off, but you tap down, it still generates a button #2 push,

So, what I am proposing is to add central-scene like button "pushed" and "doublePushed" attributes to the group device.

Here's how it would work . . .

  • If the group is On due to some of the members being on (say 5 of 10 members), and another sub-member turns on, it would generate a "pushed button #1" when member 6 turns on. This is, effectively, an "any device in group turns on" trigger
  • Similarly, if you go from 5 sub-members on, to 4, it would generate a "Pushed #2". This is, effectively, an "any device in group turns off" trigger
  • The "doublePushed" event could trigger when the group reaches "all on" (DoublePushed #1) or "all off" (DoublePushed #2) states.

Thus, this proposal adds functionality allowing groups to be used in triggers as a "any device in the group turns on" or "any device in group turns Off" and to allow both "All On" or "All Off" events from the same group.
Using button pushes maps pretty well to what happens with "real" physical devices (at least in the single-push case) and it should be possible to add this without breaking existing rules.

2

Would it be enough for the activator devices to just throw events? Or do these need to be testable attributes as well?

3

I think the answer is "throw events" but I don't think I've given that enough thought or have the depth to really understand the difference. I just wanted to be able to select the "group device" and look for the button state changes as triggers.

So I'll just throw this out as a "what could be done with it" with reasonable effort / not a big distraction from other priorities kind of idea.

4

This is pretty much a hack. So if we're going to do something here, it should not be a hack.

So, one question is, where do you want to be able to use these events, in RM? Elsewhere?

5

I was thinking of being able to select the group as a "Button Device" in RM so I could have simple triggers to give functions like "if any device in the outdoor group turns on", then set dimmer level of entire group.

As I'm thinking about this now - I'm not sure how the logic would work if what happens is a dimmer level changes rather than goes on or off. Maybe this is too much of a hack?

1 Like
6

If RM is where you're going to use it, then Custom Attribute could work. There could be an attribute 'groupState', that is an enum: "allOn", "allOff", "someOn". Group member events would push that through transitions from "allOff" to "someOn" to "allOn", and vice versa.

If the group state is someOn, why would you need to know about another device turning on/off unless the group state became allOn or allOff? Seems like a lot of noise. One would infer from the state having been allOn, that the event 'someOn' implies that a member(s) turned off.

I don't see why changing level has anything to do with it. This isn't a Scene where each device is expected to be in a particular state. A group device is either on or off. ??

2 Likes
7

I like this groupState idea. Its simple and allows both the "allOn" and "allOff" to trigger. Those were the primary states of interest. The changes of sub-components might sometimes be useful, but less so (and maybe even that would be better represented by a customAttribute like a count of the devices that were on and off).

8

You can always subscribe to those events from the devices, the Group members.

1 Like
9

I wonder how useful this will really be. Suppose you have a Group with 4 members, and you want to know when the Group is activated. You subscribe to allOn. The Group is turned on with its activator, and you get the allOn event. Great. Now, someone turns off one of the 4 members. The attribute goes to someOn. Then they turn the member back on and you get the allOn event again -- but the Group was not actually activated that time, it just achieved the same state as if it was activated. How is that useful?