Although I use shed loads of virtual devices, I can’t immediately think of any that aren’t really just being used as variables. So I don’t need a virtual device as such, I just need a container for capabilities. For example if I want to override motion I don’t want to use a virtual switch or anything that adds to the logic, I just want to make it look like there is an additional motion sensor that is active.
I hope Edge drivers can create child devices instead of child components.
Because of this problem, virtual switches, that were unnecessary in DTH era, should be created and device mirroring rules are needed to use the multi endpoint switches with Edge Driver.
I will be disappointed if virtual switches go away. Very sad I will be.
+1 on the need for virtual switches as a core capability. My big use cases:
Arming, disarming, and reflecting state of home security automation
Setting and getting guest modes (e.g., shutting off some automations for dog sitting)
HomeKit integration for Homebridge and Siri voice command
Agree Virtual Switches are a must have!!
I use virtual toggle switches for:
- visualization of presence status
- visualization of mode status
- restrict automations
- make actionable device groups
- link IFTTT devices
I use virtual contact/toggle switches (aka Simulated Alexa Switch) for:
- triggering Alexa routines
Strongly agree with others here - hard to imagine an easy route to dump virtual switches unless the rules engine adds some way to store variables. Home security system integration via IFTTT is my most critical use.
BTW, A few months ago I did put up a how to post listing alternatives to virtual switches, most of which involve making a physical change in the environment which can then be interpreted by the other system. The main problem with all of these, besides their MacGyver nature, is cost: you usually have to add one or even two new physical devices for each proxy you want to set up. But it can be done if you really need it.
The point to my post and I am sure everyone else’s is to show we all use v switches for much more than the 2 ways @jody.albritton mentions in his post above
Aren’t we largely agreeing with what Jody said? We generally aren’t using virtual devices in the sense of simulating the behaviour of actual devices, and ‘thingsim’ gives a proof of concept of how we could simulate devices in future if we were. We are using virtual devices in the absence of better solutions to provide the functionality we need. It is the ‘better solutions’ we actually need and which ST seem minded to address.
It is a similar concept with child devices. We don’t need child devices, we need the missing functionality for components such as useful labels and compatibility with Alexa etc.
I largely agree with what you said with the exception of the situations where the virtual device is being used to create an integration with another platform, whether that is IFTTT or Alexa routines or something else. In most of those cases you could do the same thing with one or two physical devices, and the virtual device is being used primarily as a cost and convenience option. But I think this is still a significant percentage of the total use cases.
There are many other examples, such as guest mode, grouping devices, creating a visual indicator for presence, etc where everything is being kept within the smartthings platform, and those likely do just need better base functionality to solve the use case. But I do think those are distinct from many of the integration use cases.
That is largely my point. We need to stop thinking in terms of the legacy device concepts.
Take something like triggering Alexa routines with a contact sensor. Why do we need a virtual contact sensor? That’s just a fudge because we don’t have anything else. Why can’t we have a new thing called an ‘Alexa trigger’ that the Alexa integration maps into a contact sensor opening and closing if that’s what floats Alexa’s boat?
Or looking in the other direction, why can’t we have a new thing that third party integrations use to trigger rules and automations? They don’t need to e.g. turn on a virtual switch.
It wasn’t meant to be an exhaustive list. Just some examples and to acknowledge that we are aware that folks are using them. We are looking at ways to improve all of the experiences on the platform for both developers and non-developers. Right now we are focusing mainly on the developer facing roll out of Edge and the current content reflects that. In the future there will be more announcements that will be targeted at the non-developer use cases.
Appreciate the clarification @jody.albritton its just that a few or a lot of us have been around quite a while in the ST universe and have seen items, options call them what you will, disappear or not regain parity at various stages over the last few years
Thanks for be open and well communicator, I think virtual switches are a core issue for thousands of users, to automate and use 3th party dashboards (Action Tiles, Sharptools, etc…) I consider myself a basic user and use more than 20 virtual switches…
Will those 3th party platforms still work with new ecosystem?
Not sure I understand all the consternation around virtual devices. They are super easy to create on the Edge platform, in fact I’ve already got a driver for end-users to create them without requiring any coding. Right now it can create and manage any number of contact, motion, switch, and momentary devices. Contact and motion also includes a switch to control the state and is useful for Alexa triggering (like the simulated Alexa switch DTH from bjpierron.
If anyone wants to try it out, I can post a channel invite.
Is it all contained in the driver that runs on the hub or does it need separate app?
That’s interesting. I couldn’t get my head around the device discovery side of things. I could see you could have a driver create a static number of devices but I couldn’t see how to create them on demand and don’t know how I could do it using an app, for example.
It’s OK to go with the components, but these two functionalities are required.
- show as separate tiles
Homekit has “Show as separate tiles” menu for multi switches, and you can “name” those child switches saparetely.
See the the video below from 12:40 to 13:10 about these features.
An interesting driver would be an Edge version of the smart app that should not be named
(Universal device type) kinda thing
It had all capabilities available and each was configurable for on off useage
A contact sensor for example could have been seen as a water leak, sound, motion sensor etc, and any mix for on off dependant on need, in its day it was very useful
Yes, I agree. I just believe that instead of pushing for legacy style child devices we need to be pushing for:
- drivers to allow user specified component labels (this is something that should be done as a matter of course for any device with components, and possibly just be a standard feature)
- the mobile apps to actually use the labels that are there (they are a bit pants with them at the moment)
- the ability to display more than one dashboard tile for a device (it is a shame that the device config doesn’t define the dashboard as an array)
- integrations to work with all the components (why do many just use