I am pushing out an update to the driver to address issues causes by a recent Android app update. The Android update was causing any device field with an uninitialized attribute to show the ‘broken cloud’ icon. In some cases this doesn’t affect the functionality of the device, and once that field was set with a value then the cloud goes away. However some of those fields were controls, like a button, and of course having the broken cloud wouldn’t allow you to use it.
I want to thank all the Android-user testers who volunteered to check out this driver update privately before I pushed it out to everyone. I think this update should address MOST issues, however there may be some lingering, so please continue to report them here.
Battery device: Please note that this update does not fix the previously reported issue with the power source not being available as an automation routine condition. This appears to be a platform bug.
Door device: This device has been reworked a bit to correct some issues. For any users of this virtual device, you will need to create a new device under this updated driver and delete your old ones. Apologies for the inconvenience.
Latest driver is now version 2022-06-20T17:00:12.227808021
Is there a guide to understand how the Virtual Drive port works? I find now that it has many more functions than what I am using, but I do not know them so before replacing it I would like to understand.
Maybe the translation got messed up here, but I think what you are asking is how does the Door virtual device work?
Basically there are two attributes supported for this device:
contact - to indicate whether the door is open or closed
lock - to indicate if the door is locked or unlocked
The two additional switches (Contact Control, Lock Control) are there simply to give you a mechanism to control the state of the contact and lock.
As a default, the contact and lock can be controlled independently of each other. However it may be more convenient in some scenarios to have them automatically synchronized: whenever the door is open, it is considered unlocked; whenever the door is closed, it is always locked. To force this synchronization, there is a device Settings option ('Synch States") you can change to control this behavior.
sorry, google traslator is sometimes worse than my level of english. I should have read more carefully :-), Yes this helps me, it helps me to understand that it is not a new version, I simply used the virtual contact sensor and now I have mistakenly tried virtual door, but I don’t think it is useful for me. I only have a virtual sensor to time a lamp, I don’t need a virtual door sensor with locks. But thank you, I learned a new thing in case I need it
All - my position right now is that I’m not going to be adding any further virtual device types to this driver. With the ability to now create virtual devices with the CLI, plus others also creating virtual device drivers, it just seems to me to be a lot of duplicate effort.
I know there is some pushback on using the CLI, but honestly it is THE tool for the platform going forward, so I think everyone needs to bite the bullet and just install it. It’s a bit analogous to the IDE, which everyone eventually learned to use. Maybe some day there will also be web-based version!
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.
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
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.
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.
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.
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!..
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.
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.
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.