I think it could work however, you may not like the Alexa command, which would have to be “Alexa, turn off xxxxx” or “Alexa, turn on xxxx” for unlocking and locking. However you would be able to have one SmartThings device with both a contact and a (custom) lock, with the ability to control both with companion switches, and also to optionally auto-synchronize. And the device would have a lock icon.
So it seems it’s pretty hard to have the best of both worlds, and there will have to be compromises either way.
Hey all, I’ve been using SmartThings for a long time but haven’t been keeping up with all the changes. I realized recently that with the new app changes, presence wasn’t working right for some of my most important automations. And with both my wife and I getting new phones recently I definitely want to make sure they are working correctly.
Now as I understand it this edge driver will allow me to create virtual presence sensors so I can actually SEE the status of our phones in the app while I test and troubleshoot my routines. I’ve installed the driver and done the scan nearby and even created 2 presence sensors, however I can’t for the life of me figure out how to map those sensors to our phones.
I’d really appreciate any help you all can give me on this!
Yes, but once you’ve set the virtual presence sensor to match what your mobile presence is currently reporting the automations will keep it in sync. Its purpose is to make your mobile presence visible in the app as inexplicably you can’t see it at all. It isn’t going to fix anything but it does help you determine what is broken more easily.
You probably wouldn’t use it in an automation/routine because you’d lose the extra features built into Member Location. However you can just use it like any other device, working with ‘present’ and ‘not present’.
Just like the previous Groovy virtual presence sensor, different people use the edge driver virtual presence sensor in different ways.
if your “member location” in the official SmartThings features works well, you may still want the virtual presence sensor as a visual indicator in the SmartThings app or a third party dashboard so you can see who’s home and who isn’t, or to use in trouble shooting. In that case you would still trigger routines from the real member location, the virtual device is just a proxy for display.
if your “member location” in the official SmartThings features does not work well, you may want to use Geopresence from another service/technology, like Life360 or anything that can use Geopresence as a trigger in IFTTT, so that the other service can show as a presence indicator in ST. In that case you trigger routines from the virtual presence sensor, because the whole point is that the official ST member location isn’t reliable for you.
if you have someone who doesn’t have a smartphone (or just isn’t part of your ST household) but you still want to have their presence/absence trigger different routines in your ST setup, like a dogwalker or a guest or even a temporary worker, or again, you just want a visual indicator of who’s in the house, you could give them a physical device like an iBeacon or some other trigger to turn on a virtual presence sensor. This one is a little more difficult to visualize if you don’t use it, but has a lot of practical applications. Just as in 2) above, in this case you would trigger your routines from the virtual presence sensor, because in this case the person represented doesn’t have a regular member location you can use.
For further discussion of presence sensors we should start a new thread as we would be getting off topic here. But the point is just that there are several ways to use virtual presence sensors. Some expect the base ST Geopresence features to be working well, but others don’t.
A virtual device is treated by the system as a physical device. But of course the virtual device itself doesn’t have any interaction with the physical world, so you have to “actuate“ it (turn it on or off, or in the case of a sensor, set its values) through an automation or through the app or by voice if it is visible to Alexa.
People use them for several different purposes.
to create a visual indicator for something that otherwise would not be visible in the smartthings app.
For example, Device presence can be used in routines, but doesn’t show up on the dashboard. So some people create a virtual switch to be a proxy for presence. That way you can see at a glance who is home and who is away.
to provide group control that can be used in a routine or a voice assistant. You create routines so that when the group switch is turned on each of the devices in the group turn on, and when the group switch is turned off each of the devices in the group turn off. You can do something similar with scenes, but some people find the virtual proxy more intuitive.
to create an integration with other systems, including Ifttt, Alexa, and some other systems. For example, smartthings home monitor security mode is not made available to other systems. But by having a virtual switch that turns on whenever STHM is armed, you can then trigger events on other systems with that change in state.
Alexa routines can turn switches on and off, but they will not trigger from a switch turning on, whether it is a virtual switch or a physical switch. But they can be triggered by a sensor. So for this very specific use case, we use a virtual device which is BOTH a switch and a sensor. When you turn on the switch, the sensor looks like it opens. When you turn off the switch, the sensor looks like it closes. That way you can trigger an Alexa routine from the virtual device.
Here’s one that I use. The switch is on, so the sensor looks like it’s open.
other technical purposes. Virtual devices are also sometimes used for other technical purposes, such as creating a daisychain between two routines or as a form of timer. But you don’t have to worry about those for now, if you have a need for something like that, and you ask in the forum how to create that kind of automation, someone will explain if a virtual device would help.
Hi Guys - The best way to check your installed driver version is by going to the device details screen of the vEdge Creator device, and choosing Driver from the 3-vertical-dot menu. There, you will see a Version date/time value, and the latest is:
As long as you have your hub enrolled in my shared channel, your driver gets updated automatically when I push out any driver updates. Now, there is an exception to that, and that is when I release a new driver - for example when we went from Version 1 to Version 2. On those occasions, you would be installing a whole new driver, rather than updating your existing one. This happens when there needs to be major new function. So it’s possible you may have both a Version 1 and a Version 2 driver running on your hubs at the same time. However, you can move individual virtual devices you created under Version 1 to the Version 2 driver when you want to, and eventually delete the Version 1 creator device and driver.
To move a device to a different driver, you go into the Driver option in the 3-vertical-dot menu for the specific virtual device and tap the Select different driver button. Then choose the driver you want to move your device to, and then tap Use this driver. I believe you shouldn’t have to change any automations you’ve defined that use the device(s) you are moving.