So for example, if I wanted to install a virtual device. What’s the process to that?
Sorry just trying to wrap my head around this new way
Right now there are two community-created edge drivers for virtual devices and they work a little differently.
As your first Edge Driver, @ygerlovin ’s might be a little easier to understand.
First you will follow a link to subscribe to that channel. This will download an Edge Driver, YG’s Virtual Device Controller, to your hub.
Once it is downloaded, you will “scan nearby” in your ST app and it will be added as a device to your account, then you will see a device tile for the controller.
Now the magic happens. 
Go into the details screen for the Virtual Device Controller and it will walk you through the steps to create a virtual device.
For more details and any further questions, see that topic:
[ST Edge] Virtual Things Edge Driver
But the steps to use any custom edge driver are the same:
-
follow the link the author gives you to subscribe to their channel
-
wait for the code to be downloaded to your hub
-
use the SmartThings app to add a new device to your hub, probably using Scan Nearby. The device will automatically choose the Edge Driver if the fingerprints match.
-
Once the device is added to your hub, you can see what Driver it is using by going to its detail screen and then tapping on the 3 dots in the upper right.
- to see which custom driver channels you are subscribed to, go to
your hub device page in the mobile app, tap the upper right menu and choose Driver.
5 Likes
Fantastic mate. Thank you.
I’d like to start this now but feel if I start doing this now just before this transition I may screw things up.
2 Likes
Hi @nayelyz! I know it’s mostly just been weekend time since the question was asked, but has there been any clarification on Virtual Switches?
If I’m reading between the lines a bit, it sounds like there’s a potential distinction between Virtual Devices created via the Labs section of the mobile app vs the IDE. Will either or both of those be automatically transitioned to a next-gen platform equivalent?
And will users without a physical hub still be able to create virtual switches?
2 Likes
Im using the new edge simulated switches and they work with Alexa still, not sure if this will be affected on sept 30
1 Like
The Edge virtual devices are part of the new architecture and are good to go.
2 Likes
Should we expect a smooth automatic migration for multi-component devices (such as dual switches) and the automations that use them?
These devices are usually represented in Groovy as a parent device and child devices, but have multiple components (switch1, switch2, etc.) in Edge drivers. My assumption would be that any automation using one of the child devices would break during the migration.
4 Likes
I already ask… Neato no answer from the developper @Alyc100 
no post from December 2021 (I have the same Neato D7 @jjmucker )
@nayelyz Just to piggyback on this, when it comes to virtual devices we really need to know the ST thinking sooner rather than later. I see glimpses of something potentially interesting in the SDK and CLI but nothing I can do anything with at the moment apart from a virtual switch that I hope runs in the cloud. That is hopefully because it isn’t ready yet, but we don’t even know that.
2 Likes
The team hasn’t provided feedback about this yet, but I’m sharing the new comments.
What I’ve seen is that the CLI allows us to create some virtual devices that don’t seem to be Hub-Connected because they have a profileID (so not a DTH) and they don’t have the hubId property included…
I’m not sure how they run and that’s what I also asked the team.
2 Likes
Unless I’m mistaken, I believe Alyc has moved to another platform - unless someone takes the initiative to port it on their own… I don’t suspect he’s working on it at all. Complicating matters is teh underlying api for the newest Neato devices works completely differently than the D7 and prior, so whomever does this will either need to research and implement both types.
Read: This one’s going to be a while Diego… look at IFTTT…
2 Likes
Thanks, it is mystifying me. I could understand it if there was some kind of command mapping yet to be added for those capabilities that are purely sensors and so don’t have commands (e.g. contact, motion and presence sensors), but the SDK doesn’t even hint at anything like that for the standard virtual devices. I am probably being impatient but I am desperate to get rid of my Edge based virtual devices and a little light at the end of the tunnel would be welcome.
1 Like
The drivers that appear in the “production” branch are those that are automatically installed when a compatible device is paired and there’s no other driver that supports it. They aren’t pre-installed in the Hub, so, they won’t appear in the list.
If you have a device installed and controlled by a driver of the SmartThings Beta, it’s ok. The only difference between them is the enabled fingerprints for the default joining process.
3 Likes
From what I gather, for these type of virtual devices where their capability doesn’t inherently expose commands, you would create the events for these via the API or CLI . So for something like Virtual Presence, it’s not quite like the Groovy version where you had an arrived() and departed() command that could easily be used in rules or wherever. I agree that exposing commands via a custom capability would be much better from an end-user experience and better aligns with how people expect to use virtual devices.
For example, the following CLI command would create an event marking the virtual presence sensor as present.
smartthings virtualdevices:events {{deviceId}} main:presenceSensor:presence present
(And if you look at the CLI code in GitHub, you can find the equivalent REST API mappings for these calls)
Where are these published? I couldn’t find them in the catalog of the ST app.
About this one, are you referring to the one included in this repo?
1 Like
Thanks for the tag, JD.
Hi, @949BFN! The instructions to install the CLI in the different OS are in the Developer Documentation > SDK section:
1 Like
I wonder if you could work around it by creating another location and setting up the second Harmony hub under there.
If you’re in the beta group, you can verify the list on this announcement to check which devices have been migrated.
Also, if your devices joined with a stock DTH by default (this doesn’t include when you select a specific stock DTH to control the device in the IDE), they will be migrated.
This is in case you want to move to Edge now, but the team mentioned that if you have a device working with a custom DTH and you install a custom driver (eg. from a Community member) to control it, it will be migrated.
Please, take a look at the FAQ page - Will there be an impact on my current connected devices?
There are other options:
-
Using the CLI
-
Using API clients like Postman to make direct queries to the API.
Note: For this option, you’ll need a Personal Access Token to use in the authorization tab -
my.smartthings.com page (Beta phase)
The ones you need to look further are those using custom DTHs which you mentioned are 35. For them, you need to check what actually changed because sometimes they were a little different from the stock ones, this way, you could take the official driver and apply the required modifications and install it yourself. (We can help you with any questions you may have)
Also, there are Community members that have published custom drivers and you can kindly ask them to add your device’s fingerprint (and install them) which will help in the migration-
WebCore is a third-party app, its web page access isn’t handled by ST. So, it should be available.
The Rules API can be used to migrate that automation, the team continues improving this tool based on devs’ comments.
Also, if you need help “translating” the automation from WebCore to Rules, we can help you out. You just need to create a post in “Developer Programs” and tag us @nayelyz or @andresg
No, in the app, there’s an option to change which driver controls the device. However, for a driver to appear on that page, it needs to have:
- The device’s fingerprint or
- A generic fingerprint that makes it compatible with the device
2 Likes
Yes, that is what it looked like to me. All the use cases I can think of would require the app UI and the Rules API to know how to do that. If I was in a position to make an API call I probably wouldn’t need to bother with the virtual device. I’m probably missing something though, which is why I am trying to grasp the plan.
There is something interesting sounding called command mapping for the custom virtual devices but that could be something completely unrelated.
I use the CLI from the Windows CMD shell. So…
set SMARTTHINGS_DEBUG="true"
… is quite illuminating.
1 Like
@nayelyz sorry if I’ve missed an official explanation:
Per the ST FAQ #4, devices will be automatically migrated to custom drivers if there’s a driver installed. Has it been established how existing child devices and associated automations will behave in that circumstance?
I.e. - I have a Zooz ZEN20, which appears as one multi metering switch and four child metering switches. At migration, will the child switches all disappear, and the multi metering switch continue to exist, now with four sub-devices? Will Smart Lighting or other automations be deleted if they only use those child devices? Same thing for my ZEN25 and ZEN32, eWelink / MHCozy relays, Inovelli notification bar devices, etc.
If so I suppose a workaround would be to create a set of virtual switches and add them to the automation, then replace with the new sub-devices after ST has migrated that device. Lots of effort. If there’s room to make a request, it would save users a lot of time if ST could convert the child devices to a virtual switch during migration, allowing us to swap in the new sub-devices after the fact.
2 Likes