Searched around a bit, but couldn't find anything...
Simple question. Does it make any difference if I have a single action, say turning on or off a switch, with multiple devices selected vs. individual actions with one device per action?
It depends on the devices that are being used. WiFi, Zigbee, and Zwave all act slightly differently.
The outcome would be more or less the same, but it's more work for both you and RM to split them out, so I'd just do it in a single action unless you think it may help you in the future for some reason. Examples include being able to disable a single line/action (so just a single device) without affecting the other actions or the ability to put a delay or other action in between if needed.
Zigbee
That's pretty much what I figured. Was wondering if one device/action might be a way to introduce some metering, but the difference in execution time is probably insignificant.
Not a predictable amount, if any difference (though I'd guess there'd be maybe a few ms?). If you do want metering, use "Custom Action" and turn this option on there, where it's available--and you can use all devices in the same action.
Thank you! Didn't realize the metering option was available with Custom Action. Would be nice if it was available with all actions, but this is fine.
If these are blubs, switches and or dimmers have look at creating a zigbee group with group messaging enabled, then use that group device in your rule.
3 Likes
I tried that and didn't have much success and ended up resetting some switches to factory default to clear out any incorrect bindings.
All of the switches are Inovelli 2-1 Blue series. In a few cases, two or three switches are grouped so as to function as 3- or 4-way switches. In other cases, a single switch is configured to operate on a group of hue lights. In one case two switches and three hue downlights are in the same group.
All of this works as expected, and in my rules I only activate the switches, never the groups directly. This ensures that the leds on the switches reflect the correct state of the lights (since the Hue lights don't bind back to the switches) and also keeps the 3 and 4-way switches all in sync.
What I thought might also work is to create an arbitrary group of switches that I wanted to control all at the same time. I may very well have done something wrong, but it didn't work as expected. I could in fact turn all of the switches on and off with a single command to the group, but operating any switch manually also turned on/off every other switch in the group. Obviously not useful.
Can a zigbee device be configured to respond to a group command without issuing a group command on its own? Or is that device-dependent?
I don't know that the Blues are doing here, but all zigbee devices I've worked with in the past do not issue group commands when physically activated, this must be an Inovelli thing, and if so should be configurable on the inovelli side
It doesn't make sense that sending a group command from the hub to the device would cause the device to issue another group command if that's what's going on here.
Well, that's necessary in order for multiple switches in a 3 or x-way configuration. Regardless of how any one switch is manipulated either physically or via zigbee, you want the others in the multi-way configuration to mirror the switch being manipulated.
Or am I missing something here? Or maybe the Blues are unique in their ability to be configured in a multi-way configuration without the use of special aux switches for all but the primary switch.
Edit: perhaps I'm conflating binding with grouping.... Definitely not an expert at either of those topics.
Not to derail this topic too much, but elements of this discussion sound eerily similar to the unsolicited binding discussed in thread below...
At the end of that thread, Maycock alludes that the behavior may actually be intentional, and I'm hoping @mark.amber can shed additional light on all that sometime soon...
The unsolicited binding is super annoying, to say the least!
Not sure I've seen this, but possibly related.
I think when I tried this, I went into Groups and Scenes and created a group containing all of the switches I want to control as a single unit. Didn't touch the config of the individual devices. The group worked as expected, but later to my dismay (it was late and I really wanted to go to bed) I discovered that physically turning off any one of the switches in my newly-created group turned every other switch in the group off as well. Fortunately my better half was already asleep so the WAF wasn't adversely affected.
Yeah, i get that, but it seems to be interfering with using the hubs group commands.
I would actually try disabling the devices internal groups and using mirror, or another rule to keep these in sync.
This is a bit like zwave direct association, as it can make debugging things interesting in you're not sure who's doing what...
This is something the switch itself is doing, not the hubitat group
Anecdotes here - I have a single group defined "All Lights" (I'm so neat, I know). I don't experience any odd behavior around "All On" when I toggle a single light (and I wouldn't expect to) either physically or from a UI (HomeKit, or Hubitat App/Browser).
As @mike.maxwell said, this likely is a "group" bound device or switch specific thing, and nothing to do with Hubitat groups.
Ok, I tried this again. In Groups & Scenes, I created a group with two Blue 2-1 switches. Enabled Zigbee group messaging, set the group activation device as switch, enabled Show group state in group device, enabled on/off optimization. This created a group id #257.
Now, if I go into the device page for those two switches, the Group Bind #1 property has been set to 257, and the lastCommandSent state variable contains bindGroup(bind, 257)) .
As expected, the group on/off turns both switches on/off. And sure enough, if I physically turn either one of those switches on or off, the other one follows suit.
Now here's the kicker... If I go into each device and blank out the Group Bind #1 property, each device shows lastCommandSent to be bindGroup(unbind, 257)). However, invoking on/off on the group still turns the switches on/off. How can this be? But physically turning one on/off no longer affects the other.
@mike.maxwell I don't have any zigbee switches other than the Blues to test. Does this seem right? How can these switches respond to a group command if they're not bound to the group? I would think an error like this in either the fw or driver would have been discovered by now. Or is the "group" created by G&S not really sending a zigbee group message? Without a zigbee sniffer, how could I tell?
@mark.amber -- head's-up on similarities here to our discussion in this thread.
Interesting, but I'm not sure how the Blue driver is involved in my scenario, unless creating the group in G&S calls into the driver for each device in the group, and the driver is doing something wrong.
I still don't understand how these two switches can continue to respond to the group 257 message if they're not bound to the group, unless G&S really isn't sending a zigbee group message, or the unbind message really didn't unbind the device, regardless of what its config is reporting.
Zigbee binding and group membership are different things. Binding is just a way for devices to directly control each other (without hub involvement). Removing the binding explains why part of your behavior changed. Groups are probably self-explanatory, ultimately allowing control of multiple devices with a single broadcast using the group ID. I don't see where you actually removed the device from the group.
As long as the device is a member of the group, it will respond to commands. In your case, it is likely still literally a member of the Zigbee group. But even if it isn't, I think the Group app on Hubitat is smart enough to see if that is (or isn't) the case and just send a regular command if it's not in the Zigbee group (it certainly is for other protocols -- you can mix them into the same group and it will work fine with or without Zigbee group broadcasting enabled -- but I don't think it's that specific).
