Based on what I’m hearing from the beta, if you go that direction, it might be a half a day or so before the driver was available to you, is that correct? Because it has to be downloaded to your hub.
They don’t appear to have found a hardware partner for smartthings Wi-Fi yet. At least not one that’s been publicly announced. Those hubs are not on the list of devices that Aeotec is taking over, for example.
I’m not a developer, but i was going to try as otherwise i’m reliant on somone else making a edge driver for a device that they may not even have. Again with Groovy it was quite easy to try, not that a command line puts me off, but this just seem…easier!
1 Like
When you are invited to a channel you follow a link where you are presented with a list of your hubs which you can enroll to that channel. If you have previously enrolled a hub the choice for that hub is instead between unenrolling it and seeing a list of available drivers. When you look at the list of drivers you are offered either a button to install it to your hub or one to uninstall it. The install happens straight away.
Where the delay you have picked up on comes in is if the developer updates a driver in the channel. That update will be automatically downloaded to hubs that have already installed the drivers but it can take several hours. Those using the command line can choose to install the driver to the hub again and it will be downloaded straight away, but those using the web don’t currently have a button to do that.
I think that is right …
6 Likes
It looks like a command-line-based development environment.
For people like me who are accustomed to using a window operating system, it may not be very accustomed.
I plan to develop a window tool, users can automatically generate most of the code as long as they do some configuration-users only need to modify it slightly after getting it.
I need some materials：
Command that can get the list of all protocal supported ;
Command that can get the list of all permissions supported ;
Command that can get the list of all fingerprints’s keys（include the value type） supported ;
Command that can get the list of all capabilities supported ;
Command that can get the list of all preferences type include more detail） supported ;
…
Is there any related interface support? thanks
It would be great if the core of smartthings-cli could be compiled into a library compatible with more platforms. In this way, my window tool will be more powerful.
3 Likes
Hi @chenjun, I think the right way to do this would be to interface with platform REST APIs when they are stable and fully documented. During the beta, these APIs are not yet considered fully stable and might change. The source for the CLI is available (https://github.com/SmartThingsCommunity/smartthings-cli) with the edge functionality implemented as a plugin (https://github.com/SmartThingsCommunity/edge-cli-plugin) and may be used as a reference but at this time we might be adding new APIs, modifying how they work, and dropping them so your mileage may vary.
At this time, I don’t think we have any direct plans for making the core of the CLI itself a reusable component, though I may speak to the team about the possibility of adding this functionality to https://github.com/SmartThingsCommunity/smartthings-core-sdk
2 Likes
Thank you for your suggestion! I’m currently developing UI. Regarding the core resources, I will adopt regular updates to keep in sync with SmartThings. We are all working towards a stable version, right?
The previous DTH that were running locally on the hub were not the same Groovy DTH that ran in the cloud. They were custom device handlers compiled and packaged in with the hub firmware. There was no direct route to load a groovy DTH straight to hub.
1 Like
Edge Drivers are going to be the new standard for hub connected devices. Today we are in developer beta for Edge. We will be speaking more about transition plans when we move to the non-developer beta.
2 Likes
Any timeframe on non-dev beta?
What is going to happen to virtual switches that we created in the groovy IDE?
1 Like
For non-developers we are working to reduce the need to use virtual switches. In most cases virtual switches are being used as a workaround in a rule or with a voice integration. Work is being done to improve those experiences.
For developers who want to work with creating virtual devices today we have released a tutorial for creating simulated edge drivers as a tutorial. -Note- This is not a replacement for virtual switches but is meant to highlight that simulated devices can be used with Edge on the Hub. We have more plans for virtual/simulated devices that we will be sharing at a later date as well.
1 Like
One of the most important uses for virtual Switches right now is to be able to activate an Alexa routine (not a smartthings routine).
At the present time these can only be activated by a sensor or a flic or echo brand button. But not by a switch. They work fine with a physical smartthings Sensor, but that’s not always what people are looking for.
And it’s possible to activate a virtual sensor through webcore, but I don’t know of any other way at this time.
So the workaround has been to have a virtual device which is BOTH A sensor and a switch. So when you turn on the switch, the sensor opens. And when you turn off the switch the sensor closes.
That way you could activate the virtual device with any smartthings automation or just with a voice assistant by turning on the switch capability and that would then activate the Alexa routine because it would look like the virtual sensor capability opened.
So this is a major feature that we need a substitute for. But there are multiple ways to do it
-
if we get an easy way to actuate a virtual Sensor, as well as an easy way to create a virtual sensor, the virtual device itself doesn’t have to have two capabilities.
-
if Smartthings has a fully robust Matter capability, we might no longer need this, because more devices will have matter integration and we would be using that instead of Alexa routines.
-
if Amazon ever gets around to adding switches as triggers for their routines, that would be another solution. Then we could just use a plain virtual switch.
So there are multiple possible routes to a solution, but if this capability goes away without one of these being true, it’s going to leave a big gap. 
I should also say that for those who really need it, you can solve this issue with money: use a Switchbot to actuate a flic button, for example. Or have an LIFX bulb come on and its heat trigger a physical motion sensor. But I don’t think most people are going to want to go that route.
2 Likes
No timeframes yet.
I use many virtual switches to manualy control multiple items
Example
V switch to manually control 4 different sets of lights in one room
V switch on - 4 sets of lights on
V switch off - 4 sets of lights off
Using a v switch in an automation that has items attached makes creating an automation easier at times as well
Will we loose v switches completely or will there be an Edge driver that simply replaces basic v switch capabilities
2 Likes
Ditto. I have 8 and none relate to voice integrations.
2 Likes
A quick count hits 40 v switches, to be fair some are now unused but still, even a slight hint of loosing v switches makes me very nervous
I have maybe 10 used for voice or Echo integration
1 Like
Good point, if we had actionable groups that could be turned on in scenes or automations, that would also remove a lot of the need for virtual switches. 
2 Likes
Some of mine virtual switches
-
Virtual Switch that is being switched On, every 1st of the month by IFTTT, for even/odd days for watering purposes. (This can be fixed by allowing Calendar use in Automations, like on evey 1st, or every 15th, even/odd days, every other Monday, etc.)
-
Virtual Switch that is being turned on for Heating, and off for Cooling, for my automation, to go back to previous settings, after A/C goes back from Fan on/off, if someone opens or closes windows or patio door.
-
Virtual Switch for Guest Home mode, that changes how all Automations behave when guests are present.
-
Virtual Switches for Wyze cameras, that are activated on, when motion is detected.
-
STHM Arm/Disarm switches
-
Temp Virtual Switches that I use when testing and creating Automations as a place holder for real device, or when changing devices to keep Automation safe from disappearing.
Not to mention those virtual switches for all of those cloud based devices (SmartLife, Tuya) that are brought to ST as Scene. (This can be fixed by having correct cloud implementation - if it’s switch it should come as switch, not as scene or if it’s fan speed, it should come as fan, with speed control, not as multiple scenes)
7 Likes