Virtual switches a bit broken? (November 2024)

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.

So more than a bit broken I suspect.

2 Likes

I also played with this a little.

Dimmer is cloud based only. It is created with out issue and works as expected.

Switch can be either hub based or cloud based.

Trying to create a hub base switch ended up creating 3 non-functional switches.

Creating a cloud base switch worked with out issues and the switch worked expected.

So only the creation of hub based virtual switches that is broken.

3 Likes

I made similar test.

In AWA error message
vSwitchStd creating in AWA  500 Internal Server Error
and non-functional switch is created.

ST has changed the device profile.

New profile
“profile”: {
“id”: “c8a59b6e-dd51-393e-a562-b000c946e70a”
},

My earlier made VIRTUAL type virtual switches are still operating. Also other VIRTUAL type devices that are using my own driver are operating.

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.

2 Likes

I hadn’t even thought about trying to make a cloud one. I just click to create it on the hub because, well… why wouldn’t I want it local?

But I’m glad it’s not just me that’s broken…

2 Likes

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. :mag_right: :lady_beetle:

1 Like

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?

2 Likes

related to this perhaps?

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.

Labs has never worked for me which is why I have always used @TAustin 's vEdge Creator.

2 Likes

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.

3 Likes

I can also confirm that local virtual switches can again be made use Labs.

1 Like

Sadly I can confirm that the preference still doesn’t work on local devices.

Hi everyone

The team has confirmed that some changes were made to address the issue.
Could you please confirm if the issue has been resolved?

Thank you!

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.

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

3 Likes

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.