So I use the virtual switches a lot in the labs for certain automations, I’ve also noticed they’ve recently added virtual dimmers that I’ve not tried yet.
But are they broken right now? The old ones still work, but trying to make some new ones and well, first it says it couldn’t make it and asks if my phones connected to wifi, which it is… then you go back and find it’s made 3 of them. Secondly they’re all stuck in the “device hasn’t updated all its status information” stage. Which doesn’t normally happen.
Any idea what’s going on? They also have a new setting “Force state change
Allow the device to generate events that can trigger routines without those events causing a change in the device state.”
So it’s clear they’ve been tinkered with recently… I tried resetting the hub but they’re still stuck.
Earlier this year the ‘Virtual Switch’ Edge driver, which has always supported a virtual dimmer even if it wasn’t so easy to create one, was modified to add the device preference you mentioned. There were two problems with this. One was that the device profiles being used to create the virtual devices hadn’t been updated to include the preference so you couldn’t see it. The other was that preferences weren’t exposed to Edge drivers being used for VIRTUAL devices. The end result was that the state change behaviour of existing devices flipped so they only sent out events when the switches toggled between on and off rather than on every event.
It sounds like things have moved on but I haven’t had a chance to experiment.
The error about a lack of updates is particularly surprising given as part of the device creation process they generated random synthetic events to initialise the attributes even if you’d already done the job better in Edge drivers.
I have now had the chance to experiment with my own virtual switches. I am finding that the device creation process actually returns an an HTTP error 500 (internal error) and although a device is created at the API level there is no evidence of it being created in the Edge driver log.
I get the error about the status information not having been updated.
I always could see the device preference in the app with my own virtual devices so there is no change there. I don’t know if they have now made the preference accessible to the device in the driver because there is absolutely no evidence that there is actually a device there.
That is a limitation of the Virtual Switch tool in the Labs. If you use the CLI, the AWA or your own API call you can create a local dimmer using a standard prototype.
It will, however, be as broken as any other local VIRTUAL devices you attempt to create, whether they use the stock prototypes or home brews. Error 500 every time.
Existing devices continue to work fine. Newly created devices show no sign of having been created at the Edge driver level.
Since this is an official feature, please report it as a bug via the Contact Us option in the SmartThings app. That way it can get officially assigned to staff to look at.
Actually this is a development issue as well as it prevents me developing my Edge driver that runs all my virtual devices. So I think I can legitimately tag @nayelyz here.
Nayely, the bottom line is that the API returns a 500 error when attempting to create new VIRTUAL devices that run locally, both the standard prototypes based on the Virtual Switch Edge driver and community created ones based on custom drivers. The API objects are created but the Edge driver device isn’t. It’s like having a car without an engine. Would you be able to nudge someone please?
I was going to say I didn’t think so. However creating a VIRTUAL device to run locally involves the API making sure the required driver is installed on the hub and installing it itself if necessary. Even though I think we all have the driver installed already there could be something going wrong at the ‘making sure’ stage.
I note that the local VIRTUAL switches seem to have their engines back. They must have put them in the boot by mistake. Stock local dimmers created when there was an issue don’t have the switchLevel initialised but new ones are fine.
I haven’t yet looked to see how preferences are behaving at the Edge driver level but they are OK in the app.
The issue in this thread with an error 500 creating local VIRTUAL devices has been resolved. However there were three other issues with local VIRTUAL devices in general, and the stock Virtual Switch in particular, which were discussed in another thread.
Although a preference had been added to the Virtual Switch Edge driver and added to the profiles in the driver package, local VIRTUAL devices don’t use those profiles and the profiles they did use hadn’t been updated. That has been resolved.
The new device preference is working at the API level, but unfortunately device preferences have never been available to Edge drivers being used for VIRTUAL devices. By that I mean device.preferences is empty in the driver. That has not been resolved.
Edge drivers being used for VIRTUAL devices do not receive the infoChanged lifecycle. That has not been resolved.
The new code in Virtual Switch looks for the device preference being true in order to be back compatible with the previous code. As the device preference can’t be read that means the behaviour of the stock local VIRTUAL switch has changed. It now doesn’t include state_change=true by default.
I note that a PR has been submitted for the Virtual Switch. The effect is that unless device preferences are available to the driver the old state change behaviour will always be be used.
