Will these sort of devices be gone once things change with groovy? I don’t really get the jist of when things are changing and what’s going to go away but id certainly miss that one that’s for sure. 
1 Like
The groovy version will go away, but one community member has already created a version for the new architecture which you can try now if you want to, although it’s still in beta.
Note that in addition to a different creation process, the new architecture will require that you have a smartthings or works as a ST hub from Aeotec if you want to use these virtual devices, which the current groovy architecture does not. (Otherwise you can create your own virtual devices for the new architecture, but you will still have to host them yourself somewhere.)
Here’s the link for the Vedge device. The topic title is a clickable link.
Oh nice. Thanks.
I’ll wait it out until things are rolled out officially but that’s good to know that these sort of things/devices will still work, and even better by the sounds of it ( local).
I’m guessing I’ll have to start from scratch though with all things groovy though and create everything again? Thanks.
Edit. Actually just re read that and are you saying this new process ( edge ) won’t work with V 2 hub?
1 Like
No, sorry, as far as I know it might work with the V2 hub, but ask in that thread, someone there will know.
Here are the list of requirements:
The virtual edge device work great with my V2 hub.
The only problem I have seen is that the icons eventually switch the the genetic “thing” icon.
1 Like
It happens with Aeotec V3 hub too.
There is already a community produced driver that is demonstrating that Edge Drivers can support virtual devices as we are familiar with them. However Edge Drivers are hub based so it does introduce a hub dependency.
ST haven’t detailed their plans in this area, but have identified that much of the usage of virtual devices is not to simulate actual devices, rather it is as a workaround in the absence of more appropriate functionality. They seem minded to create some of that functionality.
We don’t know what they have in mind but we could wildly speculate. Take Alexa for example. Just because Alexa routines can be triggered by e.g. contact sensors, that doesn’t mean virtual contact sensors have to be used on the ST end. There is no reason why ST couldn’t have a ‘trigger’ entity that got converted to a momentary contact for Alexa’s benefit. Similarly, rather than using virtual switches for binary state, why not just have a 'boolean entity?
1 Like