I would respectfully disagree that they are “crutches” while I would agree that you might not need them if you were willing to substitute a physical device each time. But that costs money, energy to run, and adds an additional point of possible failure.
I agree the virtual switches are often used to make up for deficiencies in the smartthings platform, but it’s better to have a way than not.
What virtual switches are most useful for, however, is as Communication methods with other non-SmartThings systems.
IFTTT is the most obvious example, although there are others. I can trigger anything at all that has an IFTTT Channel by using a virtual switch in SmartThings. That is a huge number of potential “man in the middle” integrations. And a very simple means of doing the integration. It costs virtually nothing in money, energy draw, and a minute or less to set up. There’s no pairing, no resets, no batteries to change, no plug to find.
Virtual switches used within SmartThings are often a way to make up for a SmartThings deficiency, even if it’s just a simple way to group devices.
But virtual switches used to communicate with external systems are an added strength of the SmartThings platform.
And even within SmartThings, virtual switches have a place, such as a virtual presence sensor which also has capability.switch.
So as always, “Your use case is not my use case.” Virtual switches are a feature available on the SmartThings platform. Different people will use them for different purposes. Since the feature exists, any advanced rules engine should be able to incorporate them into standard rules.
Yep, he’s right again. LOL
I believe that the “grouping” of several physical devices under a virtual device (i.e. turn all switches on when the virtual is turned on) is a bit outside the scope of the rule engine. Can be implemented as a rule, but I feel that an app that specializes on grouping devices together, providing a virtual device for each group, is a much better solution. I haven’t looked, but if such app does not exist, I am willing to build it AFTER we’ve launched the rule engine, whatever its name may be
I may be mistaken, but I think you already have the basic grouping for lights, as it’s really one of the simplest rules.
A list of lights
When a switch is turned on
Specify that switch
The only other thing we need that you might not have is a clause like the one in smart lighting:
Turn off as well. (this has to be optional because sometimes you won’t want them to turn off when the master turns off.)
That groups the lights. You can either pick one of the group as the master, or you can assign them to follow a virtual switch. The rule works the same.
But notice that this is super simple: the only thing it matches is on and off. Not set level or color or any other Device capability.
I think it’s likely that people will have existing groups that were created in other smart apps and are tied to a virtual switch.
But unless I misunderstood something, you’ve already given them the ability to create a simple group of the “follows master” type.
Of course he is. Leave it to @JDRoberts to pour wisdom into a topic…
But like he said, my case is not everyone’s case I still believe one can easily do away with VS and that actually VS add unnecessary points of possible failure more so than a physical device…
I guess my understanding of grouping is a bit different. I am talking about a multi-way sync, where if any of the devices turns something, all the others follow. Say, you have zwave dimmers in the wall, you turn the light on in the living room, all others turn on, but if you turn the hallway lights off, the others should follow. In this case, you don’t even need a virtual device, an app can “link” them together. Bind them, if you may. This can be done in a rule, especially with the local variables:
If any of [blah blah blah]'s switch changes, save the event value into variable @whatever, action Set [same list]'s switch to @whatever. A rate limit should be placed on this rule (when developed) to avoid unnecessary events while turning those lights on/off.
This is where an optimized app that only does that would make sure to not trigger further actions as a result of its own changing of lights. That’s why I said, a specialized app can make things easier for both the UI and the ST.
You may have already meant all this, but just for clarity, it’s important to note that If they all follow each other all the time, it’s really hard to put a device into two different groups.
Say I have a hallway light. It’s at the base of some stairs. I want to put it into two different groups.
First, it’s in the downstairs group which includes the entry area and two of four lights in the living room. This is the " entry" group.
Then I have a pathway of lights that I call “bedtime.” It includes the hallway light at the bottom of the stairs, the hallway light at the top of the stairs, and a Bedroom light.
And then I have yet a third group called “living room” that has all four of the living room lights in it but does not have the hallway light.
Three groups. Each can be independently scheduled, and independently triggered. I could have a Contact sensor on the front door turn on the Entry group.
I can have a motion sensor in the living room turn on the living room group.
I could have voice activation turn on the bedtime group.
What I don’t want is to have turning on the hallway light automatically turn on the two living room lights and the upstairs bedroom light.
Based on tons of work done by Apple, and practical if less comprehensive work done by most other home automation companies, humans tend to think of device groups in terms of what Apple now calls “service groups”–Devices which are grouped together for a specific purpose, but which may be in a different group for a different purpose.
This is why most home automation systems now distinguish between “rooms” (based on the physical location of a device) and other types of groups, which could be based on device class (“all lights”) or on A specific use case (“Good night.”)
Of course if you’re changing the settings of a specific device through physical manipulation at the switch, then you’re probably stuck with one group for that purpose, which is probably what you meant in your description.
But once you allow for Settings which are changed in other ways, even just by voice, then a device can be in multiple groups, so it’s better to have a virtual master concept even if that’s just presented in the UI as changing the characteristics of the group (in that case The group name is standing in for a virtual master).
So again, that’s probably exactly what you meant, which is you were referring to groups where The settings are physically changed at the switch. But of course there are many use cases where that’s not necessarily true.
Yeah, switch binding would not allow for multiple groups. It all depends on the needs. If I had 4 mood lights in four corners of a room, it may be practical to “bind” them together, switch, level, color and all, so you don’t have to keep changing all of them in all the rules. I am not going to impose any artificial limits on anything, so virtual devices or not, they should work just fine.
Yep, there is already a SA for Grouping Devices created by @Kriskit
Trend Setter - A SmartApp for grouping devices
[RELEASE] Trend Setter
Since SmartThings supports both Zwave and Zigbee, speaking just for myself I prefer not to see the terms “association” (a specific zwave term) or “binding” (a specific Zigbee term) used outside of those contexts, as it can get totally confusing for those of us with a network engineering background. Or anyone reviewing a feature list while trying to select devices for their home. (The obvious “does not support association” springs to mind.)
It is not possible to bind a zigbee switch to a Z wave switch from a zigbee point of view. And saying you can bind one zigbee switch to another zigbee switch has a very specific meaning for the manufacturers of those devices. So it can just lead to a lot of confusion.
“Synch” is a good general-purpose term for multiprotocol systems, as are “link,” “group,” and “follow.”
Ok, this is a great discussion. But isn’t the most basic use of CoRE really nothing more than an association (grouping) app?
If this (something does something)
Then that (something else does something else)
Also known as, Trigger and Action.
It really doesn’t matter how many triggers you have, whether they are real or virtual, or how many actions you have, also without concern to real or virtual.
The app is just a super fancy cause and effect machine.
No, because the Trigger isn’t limited to event activity on another device.
Still cause and effect.
Cause-and-effect, yes. “Just” Grouping, no.
As an example, One of the most popular basic rules is “turn light A on at sunset.”
One trigger, one action, absolutely. But I’m not “grouping” light A with sunset. I might be putting it into a “sunset group” but that’s a different data model. Sunset itself is a trigger which is a schedule. Not a device event.
It’s easy to see the difference when you think about what the network controller knows. What would be the “device ID” for sunset? It doesn’t have one because it’s not a controllable device. But in a device group, each device in the group does have a device ID.
There are certainly basic rules which are essentially just groupings. But they’re also basic rules which are just schedules.
Just as a side note to all this VS conversation. I use them quite a bit for groups of lights mainly because I have tablets on the walls running SmartTiles. I need one tile (VS) to control groups of lights in various areas. I don’t think I could reduce the number to 0 for this use case.
That’s true. But I still say I’m right and you’re wrong!
I want to see the nerdiest one! (I am sure you’ll come up with a more detailed one, cannot you )