Would you mind posting a link to the instructions for this? Thank you!
You’ll want to first make sure you have the latest CLI (version 1.0.0-beta.9) by downloading it from here.
The readme file at this link has the list of all commands including the new virtualdevices commands. For example:
smartthings virtualdevices:create-standard
will let you create a variety of standard prototype devices.
1 Like
Not practical devices in most cases though. Capabilities like contact, motion and presence don’t have commands so there is no way to set the virtual device attributes based on them in Routines/Rules, only by API calls.
1 Like
As @orangebucket points out, those aren’t going to have both switch and sensor capability, though, will they? The “trigger and Alexa routine from a smartthings routine” use case? Or am I wrong?
Also, just curious… What hardware do you need to run the CLI? For example, I only have a tablet, I don’t have a laptop/pc. That’s pretty common among millennials unless they have a gaming computer.
I recently installed the CLI on my Windows 10 laptop.
Even though I’m a techie (been working in IT for 30+ years), I find the CLI to be rather clunky.
Having said that, I should check to see if I could get it working on one of my Raspeberry Pi devices.
I think there might be an issue with the virtualdevices aspect of it, or my expectations are off.
If I type " ./smartthings virtualdevices" it comes back with “no items found”.
If the command is supposed to give me a list of all of my virtual devices, it’s not working.
I have three virtual devices created from TAustin’s driver.
I eventually found the UUID of my current devices by going through what I think is the beta of the replacement IDE(?) at my.smartthings.com
My understanding based on limited testing:
As things stand at the moment, you could define a device profile containing a switch capability and a contactSensor capability which you could use to create a virtual device. That virtual device would have those two capabilities.
The switch capability would have the switch attribute and the on and off commands, and the on and off commands would set the switch attribute on and off because that behaviour is defined in the capability. So that is a functioning virtual switch as we know it.
The contactSensor capability would have the contact attribute but there are no enum or setter commands (or any other commands) defined in the capability so no commands are generated. Normally when creating a virtual contactSensor we add custom open and close commands to set the attribute but there seems to be no way to provide those at the moment. The only way to set the attribute is via the API and that isn’t something Routines/Rules can do.
So either Rules become virtual devices aware, or there will need to be a way to add command mappings. However that still leaves the question of how you would sync the two capabilities together and there doesn’t seem any scope for extra intelligence.
Hopefully it will all become clear.
1 Like
You have three community developed virtual devices created using the LAN device type, which means a LAN based hub connected device implemented using an Edge driver.
The API virtualdevices endpoint is specifically for the new VIRTUAL device type created by SmartThings of which we know very little.
smartthings devices will show the ID of all your devices in the CLI.
Rather than a replacement for the IDE, my.smartthings.com was introduced as a web based version of the mobile apps, though obviously with only a subset of the functionality. It isn’t clear where it is going. It might just be a convenient placeholder to discourage use of the legacy IDE during a transition period. We really don’t know.
2 Likes
I’ll just say that your virtual devices have customizations that the SmartThings native virtual devices and others don’t have. I’m sure it’s a lot of work, but it’s extremely appreciated, thank you!
For example, your virtual motion device has the ability to set the auto-return to inactive with a user defined duration timeout value. Because of this feature, I use it as my ‘Things are Quiet’ device. With a routine where if any motion sensor is active, it turns On the Things are Quiet virtual motion device which has the auto-return to inactive duration timeout set to 900 seconds (15 minutes). So the Things are Quiet virtual motion device then triggers my STHM to arm stay mode when it’s Off at sunset, or turns Off after Sunset.
2 Likes
There are versions for Windows, MacOS, and Linux. ipad users are out of luck, for sure; I would think that MS Surface would work; don’t know about others. Your point highlights the need for a browser-based front end to the API. I’ve been tempted to give this a go, but decide against it for two reasons: 1) I don’t have good front-end development skills, and 2) I keep thinking that SmartThings must be working on this already… Kind of like the web-based rule builder that was announced last fall and never materialized!..
1 Like
Does it though? I think if there is a lesson to be learned from the Groovy IDE it is ‘never again’. ST is doing exactly the right thing by not reinventing the wheel when there are development tools like IntelliJ IDEA and Visual Studio out there. The CLI slots in nicely with those.
Both of those require macOS, Windows, or Linux. They don’t run on a standard tablet either.
My point was if we start putting some advanced features like creating virtual devices or even some basic features like seeing the Z wave route, into an architecture that is only available from the CLI, that will leave out a lot of into potential users, particularly younger ones. And many with accessibility issues.
This came up during the pandemic lockdowns because a lot of homes didn’t have a PC.
2 Likes
The CLI is just a front end for the API that lends itself to use in environments that traditionally use text based command line tools. It is like putting curl through a table generator. It can’t do anything that can’t be done in a browser and there are plenty of tools and websites to help anyone do that if they choose to do so. Absolutely no one is being excluded from anything and taking advantage of existing mature tools is a positive step.
Should things like virtual devices and, hypothetically, mesh routing be more easily available to end users going forward? Of course they should. Has there been any indication that they won’t be? No, because one hasn’t had a launch worthy of the name and the other doesn’t exist.
On the other hand, should development aids be focussed on the environment which developers are actually using? Again yes.
2 Likes
To circle back on the question of adding further devices to this driver. Thanks for everyone’s thoughts on this, expressed both here and in direct messages. You all have made the case that, while the CLI virtual devices may be useful for very basic devices types and purposes, there continues to be a need for more ‘intelligent’ virtual devices.
I’d still recommend anyone looking for a simple device to try the CLI first and if that doesn’t meet your needs, let me know how I can help.
So I’m getting to work on adding additional devices and hope to have them all done by end of next week. On my plate: garage door, fan, panic alarm, refrigerator, temperature, TV, and video camera (to obsolete my separate virtual videocam driver).
If anyone has any change requests or other device type needs, let me know now and I’ll try to include in my next update.
6 Likes
Can your driver Tod have an A/c icon, the ability to be seen in Alexa and also have the ability to display/mirror temperatures found from different zigbee devices working in ST ? So the end result would be a V/device that looks like an A/c controler ?
Thank you if possible
Edited
due to being a little convoluted, meh, it happens 
You’re not asking for much! At this point I would arrange for @TAustin to come to you house and make a bespoke solution just for you. Isn’t there already a V thermostat driver? And using the Broadlink and Alexa app sounds rather over complicated and cloud dependant, you know RM Tasker Bridge on a tablet can send Broadlink button presses and Macro’s directly on the local network? @TAustin’s Web Requestor keeps everything local too.
re. A/C controller - I’ll have a look at this. There is an A/C icon and device type I could use and it could include a temperature field that could be set by a routine. When you say you want it to be seen by Alexa, what exactly do you mean? What kind of interaction would you want to have with it from Alexa?
1 Like
The A/c device is IR Tod, i have a broadlink IR blaster that provides app control of the A/c via Broaflink > Alexa integration
In theory i could create a few routines that would tie in a Virtual ST switch and the Alexa integration
I guess i would have to create a few ST routines as well with v/switches for on off, temp up down but it is probably doable, all in all a little faffy but doable
Just would be nice to have a virtual device in ST that acted and looked like a real controler with a temp displayed and an on off
Once it gets pieced together with routines i can then use ST to control the device based on other temp sensors
Im unsure if it is possible to display a temperature from a seperate device inside another but i thought i would ask
Ok I’ll include an A/C device in my update this week.
1 Like
All my vEdge switches are showing as connected on the Device tile and show they are in the on state regardless if they are on or off. The switches still work and show the correct state on the detail page.
Rebooting the hub did not help.
This applies to both old and newly created vEdge switches.
3 Likes
That has prompted me to look at my app and I am seeing the same thing. The state on the dashboard tile is always Connected, and the icon is always active in both dashboard and details views.
3 Likes