The End of Groovy Has Arrived

The ones created by community developers that run as Edge Drivers can. :sunglasses:


That won’t work after September 30. You should check in the author thread to see if anyone’s working on something for the new platform. :thinking:


What’s the deal with these edge drivers.
Is it really just a matter of downloading them onto your hub and then these devices / drivers appear within ST.

1 Like

If they are official edge drivers written by ST, you don’t have to do anything. They will get automatically downloaded to your hub and matched with new devices as you add them. And there will be some kind of automatic transition as part of the cutover for Sept 30.

If you want to use a custom edge driver, you just follow a link the author will give you to subscribe to their channel, and after that the drivers you select will get downloaded to your hub. Once the driver is on your hub it will get automatically used when you add a matching device. Or you can switch between drivers available on your hub by using the ST app.

So it’s all much easier than using custom groovy DTHs was. :sunglasses:


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. :sunglasses:

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:

  1. follow the link the author gives you to subscribe to their channel

  2. wait for the code to be downloaded to your hub

  3. 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.

  4. 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.

  1. 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.

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.


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?


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.


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.


I already ask… Neato no answer from the developper @Alyc100 :frowning: 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.


@orangebucket, @joshua_lyon

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.


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…


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.


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