I started migrating off of this driver now as well since I keep experiencing issues.
I had 25 virtual devices using this driver. I deleted 10 because they were obsolete and no longer really required. I moved 9 to SmartThings Virtual Switches running locally, and 2 to SmartThings Virtual Locks to control two Alexa connected devices. I just have 4 more to deal with, but I’m still thinking about which virtual driver/devices to replace them with.
Thanks for this. I discovered I was no longer enrolled to the channel, also. I re-enrolled and now all is working fine again!
For what it’s worth, my hub has been enrolled in the “TAustin Shared Projects” channel this whole time while the issues have been ongoing. I don’t think that’s the root cause here. Likely a red herring, as the vEdge devices seem to operate normally for a while before one goes bad again.
As previously reported, i flipped 4 alexa switches to vlocks to see how they worked. They’ve been working fine after two days … just make sure existing routines that use scenes that you add them to are re-saved to not be run on the hub or the routine won’t run.
Today i received a smartthings notification that one of the vlocks has a battery level of 15% and needed recharging. I ignored the battery indicators on them after i created since they are virtual. Can anyone help me with what effects those indicators? Interestingly, when i looked in Smartthings it actually showed 100%.
Found a post from @Paul_Oliver i think, specifying how to turn off the battery level warning in ST which i just did. I assume the level has no effect on how I’m using it in automations to lock, unlock and test as a trigger …??
Any idea why i got a warning on a device showing 100%
There was a bug in SmartThings that was fixed yesterday related to devices that populate the battery type and quantity in addition to the percentage remaining.
Turns out the SmartThings virtual lock you created populates the battery type and quantity so it might be related to that same bug, although the one I reported was for Zigbee devices using drivers and the lock is a cloud device. If it happens again let @nayelyz know.
@mocelet Thanks
As for using the SmartThings Virtual Switches, watch out for the ‘Force State Change’ setting of these virtual switches. I’ve had to manually disable this setting on all but one of the fifteen virtual switches I created since this setting is enabled by default when the virtual switch is created. Other than that, I’ve converted all my virtual devices off of this driver now.
It has been a great run using this driver, so I’m thankful to @TAustin for the hard work that he did at a time when Edge was in its infancy and SmartThings provided nothing at all in the way of virtualized devices. The virtual motion device with it’s auto-restore condition timing was the best original feature.
@DaWeav I’m not understanding the use of the ‘Force State Change’ setting … when you would want to use it and when not … can you explain? Thanks
This is my laymen description.
If a virtual switch is already On and it previously triggered an Automation when it first came On, then with this feature On, it will continuity trigger the Automation again and again since it will force the virtual switch On again and again even though it’s already On.
An example of the only virtual switch I needed this feature On is a ‘When Things are Quiet’ virtual switch since I use it as a timing thing for a Smart Lighting Automation. All of my physical motion sensors will turn on this virtual switch that is set to auto turn Off in 15 minutes which will only happen after the last motion has been detected from any of my motion sensors since it continues to get forced On by the various motion sensors.
@DaWeav - Thanks. If I understand correctly, with this setting on, the device can be virtually turned on, for example in an automation, and will trigger automations driven by it being turned on and then, even though it wasn’t turned off in between, it can be virtually turned on again and trigger once again. I assume it would work similarly for being turned off. In other words, it allows multiple off events or multiple on events to be processed in a row. Did I get it?
Yes. SmartThings defaults to only propagating events where there is a change of state, but you can set a flag to tell it to treat the event as a state change regardless.
The old Virtual Switch device handler set this flag (whereas the Simulated Switch didn’t) and this behaviour was retained for its replacement. The preference is a more recent addition to give you the choice, and it defaults to ‘true’ to avoid it being a breaking change.
I set up a manually run routine to turn a switch on and another routine triggered by the switch turning on. I see no behavior difference based on the setting. if i repeatedly run the manual routine, it triggers the first time it is run and then not again until the switch is turned off. sorry to be repeatedly missing the point, but what will demonstrate the different behavior? thanks for your patience!
What is the purpose of creating a virtual presence sensor in AWA if it has no commands to change its state?
Stock virtual devices can be used to test integrations, check that capabilities are correctly read, etc.
A virtual device has the same capabilities of a real device, that’s why you can turn on a switch but you can’t “press a button” or “make the sensor detect something” since that only happens with a physical event and virtual devices lack that.
I found that a cloud based virtual switch didn’t respect the preferences.
However when I created one to run locally on a hub that worked as expected.
@orangebucket Thanks for the follow-up. I was beginning to think I was being obtuse! I tried it with hub based switches and it worked exactly as described. BTW, do you know why only the switch and dimmer are available hub based vs cloud. Is that just a timing thing with the possibility that the Smartthings team moves others to be locally run as well? Thanks
I suspect it was originally because those were the only production stock virtual devices that we had on the legacy platform so that was all that needed replacing as part of the migration. Yes we did have a whole range of ‘simulated’ devices but those were actually meant for simulating hardware devices for test purposes only and didn’t run locally as the virtual devices did.
Then Todd and others got in first with the LAN driver based sentinel device approach, followed by inevitable feature creep.
Its not like there has been a hugely visible community interest in developing locally running virtual device drivers using the native platform. Indeed I am only think of two other community members who appear to have used them. They have never been documented and they were rather undercooked for a long while. They still seem to get splatted with unhelpful synthetic events on creation and are a bit sus with hub backup (but they are not alone in that). Shame really as they have absolutely massive potential.
@orangebucket Thanks Graham. I’m only using the cloud based virtual lock and cloud based virtual switch right now. I migrated from the @ygerlovin drivers to Todd’s. Am still mostly on Todd’s as I’m not experiencing the issues that others are seeing as of yet. Would you consider the cloud based vlock and vswitch “officially” supported by Smartthings at this point? I’d love to be on something that has staying power for once!
I have not experienced any issues with my vEdge Creator virtual devices. In that case is their any reason I should replace them with the ST virtual devices?
