[ST Edge] vEdge Creator: a virtual device generator for end users

sorry for my trivial question, but what is this for? I came here on the advice of a user, to be able to use virtual devices with drive edge for the location of the smartphone. As virtual I understand that the position will always be determined by the device created by my smartphone and I will be able to make a rule to align the position of the edge driver with the real one of my smartphone. But what is it actually for? and what changes compared to the old virtual devices created by the IDE. If I check I see that the old virtual device is seen locally, while the new edge is seen in the cloud. Am I missing something? I’m sure there is an explanation that I still don’t understand

The stock Virtual Switch and various other virtual devices are part of the legacy ecosystem which will eventually be turned off. As you are aware, the Virtual Switch can run locally. Most can’t.

Edge Drivers, which are in beta, are the replacement for Groovy DTHs for hub connected devices on the ‘new’ ecosystem. They all run locally. It doesn’t matter what the IDE thinks, that’s on the legacy ecosystem too and has limited understanding of the ‘new’ stuff.

Edge Drivers can also be used to create virtual devices and they have been.

So if you want a virtual device you have options. You use whatever you prefer.

Personally I prefer to mirror mobile presence (new), with Automations (new) or Rules (new) onto a virtual device implemented with Edge (new) and monitor things with the apps (new) and CLI (new). I use the IDE (legacy) for working with legacy devices.

2 Likes

thanks, now I understand, I will gradually replace all my virtual devices made in the past on IDE with these new facts with Edge then. I hope to see good news in the future and also that someone will come back to work on the abandoned projects that now work with DH but if they close groovy I guess they will not work anymore (I think of netatmo camera and meteo station)

All - Version 2 of this driver has been added to the shared channel and is available to install on your hubs. As explained in my prior post, this removes the use of Settings to create devices, due to its currently unpredictable behavior.

You can continue to use the prior driver as long as you would like, as I will not delete it any time soon, however you may find that you will not be able to create any further new devices in that driver. When you are ready to transfer your current devices over to the new driver, go into each device details screen, tap the 3 vertical dots in the upper right corner, chose ‘Driver’ , then tap the ‘Select different driver’ button and select the Virtual Devices V2 driver. (This is all assuming you have installed the new driver per below) When you are completely done with the V1 driver, you can delete the vEdge Creator device and use the invite link to uninstall it from your hub.

To get started with the V2 driver, first go to the channel invite link and click the ‘Available Drivers’ button and then be sure to select the ‘Virtual Devices V2’ driver. Once it has been downloaded to your hub, you can do an Add device/scan nearby and the ‘vEdge Creator V2’ device should get added.

To create devices with this new version, simply set the quantity you want to create on the details screen, then tap the button below it to select a device type, and the virtual device(s) will be created. You will see a message confirming how many devices were created. (It will go away after a few seconds.) Look in your ‘No room assigned’ room for the new devices.

Virtual device types now supported are as follows:

switch, switch level (dimmer), momentary, contact, motion, presence, shade, thermostat, lock, smoke, water, alarm

4 Likes

Is there anyway the created devices can be given an ID in the IDE ? Maybe in the device network ID

The reason I ask is that when a device is created there is no record of the created vdevices name, I wanted to delete the v1 creater but as some vswitches were still used somewhere in the app I was unable to delete the creator

I looked in the ide but nothing indicated the v1 v devices were Taustin versions

I have now found them and can replace them with v2 versions but an agile name record would be very useful

The device network ID is not shown in the IDE for Edge devices. Nevertheless all Edge devices certainly have them. Interestingly, not even the CLI can be used to display it (unless someone can correct me)!

Just to clarify, there is no need to ‘replace’ any devices you have already created under the prior driver. Those can continue to happily exist - either left under the old driver - or transferred to the new driver.

Nevertheless I get the challenge and will consider ways to make it easier to identify the devices, but it will depend on the output of the tools we have. For now, I’d recommend using some kind of convention when you rename them to your liking, since the device label is really the primary identifier in these tools right now.

It is easy to find the various vEdge devices in the CLI if you haven’t messed with their device names. However if you have changed the driver the device names retain the .v1 suffix they were given when first created, so it isn’t easy to see which driver created them.

Thank, you for the update and adding the virtual water detector.
The new virtual device creator is pretty slick.

1 Like

Are you doing a ‘smarthings devices’ CLI command? The table that gets output has a column labeled ‘Name’. However this is a bit misleading because it is the name of the device profile, which is common across all devices of the same type.

@TAustin
The virtual water detector seams to work well and the status on the device tile changes to reflect what is going on.
The virtual smoke detector has improved. It still does not reflect the state on the device tile, but the “checking” note is gone.

1 Like

Thanks Paul. The smoke detector state is awaiting a fix from SmartThings platform.

Virtual Devices V2 works perfectly fine for me. Thanks for that. I just wanted to check, is it possible to set the virtual switches to become useable as a trigger in Alexa routines? Currently, it only allows contact and motion sensors. Thanks.

All the virtual devices with switches should be available from Alexa. I just checked mine and they are all there and can be controlled from Alexa. Did you list All Devices in the Alexa app?

Controlling is fine. I can control the virtual switch with Alexa. But I could not trigger an action or routine using them. Under Alexa new routine, the “When this happens” option do not see the virtual switch (in fact, even actual switches). It only allows me to select virtual Motion and Contact Sensors. I think Yakov did it by adding a hidden contact sensor capability to the virtual switches.

1 Like

See the first post in this thread. Instead of creating a hidden sensor in a switch, the edge drivers created in the method described in this thread add a switch to each virtual sensor so that you can actuate it. That then makes them usable to trigger Alexa routines. So use the method from this thread to create a virtual contact sensor, and you will find that you can turn it on and off from smartthings as desired. On is open, off is closed. :sunglasses:

  • Includes a switch in each virtual device to control device state (also useful for Alexa triggers)
2 Likes

Is it possible a single virtual Edge driver can be given multiple capabilities configurable within settings

Yes that would be possible to do however it’s best to stay away from settings for now - until they get those settings problems addressed.

What do you see as the advantages to having one device with all those capabilities vs having them in separate devices?

I think the capabilities would have to always show on the device details screen; don’t think you could control the display dynamically. So not sure what ‘enabling’ or ‘disabling’ them would actually accomplish?

I have absolutely no idea Tod

Forgive my fogie memory but i think the original IDE driver was created by one of the hubitat guys before they left ST, it was not a well received item due to its multiple options

JD or someone with a better memory than me I’m sure would know the full story

Though having thought about it, would a single driver like this cut down on the driver limit count, instead of multiple drivers to do simple tasks would this not help ?? Duno

If you mean the DEVICE limit count then yes, that would be an advantage to this approach.

1 Like

The original thread from 2016

Screenshots remind me of how easy it used to be to see what states were like instead of the god awfull crap we have now

1 Like