Hi @nayelyz! I know it’s mostly just been weekend time since the question was asked, but has there been any clarification on Virtual Switches?
If I’m reading between the lines a bit, it sounds like there’s a potential distinction between Virtual Devices created via the Labs section of the mobile app vs the IDE. Will either or both of those be automatically transitioned to a next-gen platform equivalent?
And will users without a physical hub still be able to create virtual switches?
Should we expect a smooth automatic migration for multi-component devices (such as dual switches) and the automations that use them?
These devices are usually represented in Groovy as a parent device and child devices, but have multiple components (switch1, switch2, etc.) in Edge drivers. My assumption would be that any automation using one of the child devices would break during the migration.
@nayelyz Just to piggyback on this, when it comes to virtual devices we really need to know the ST thinking sooner rather than later. I see glimpses of something potentially interesting in the SDK and CLI but nothing I can do anything with at the moment apart from a virtual switch that I hope runs in the cloud. That is hopefully because it isn’t ready yet, but we don’t even know that.
The team hasn’t provided feedback about this yet, but I’m sharing the new comments.
What I’ve seen is that the CLI allows us to create some virtual devices that don’t seem to be Hub-Connected because they have a profileID (so not a DTH) and they don’t have the hubId property included…
I’m not sure how they run and that’s what I also asked the team.
Unless I’m mistaken, I believe Alyc has moved to another platform - unless someone takes the initiative to port it on their own… I don’t suspect he’s working on it at all. Complicating matters is teh underlying api for the newest Neato devices works completely differently than the D7 and prior, so whomever does this will either need to research and implement both types.
Read: This one’s going to be a while Diego… look at IFTTT…
Thanks, it is mystifying me. I could understand it if there was some kind of command mapping yet to be added for those capabilities that are purely sensors and so don’t have commands (e.g. contact, motion and presence sensors), but the SDK doesn’t even hint at anything like that for the standard virtual devices. I am probably being impatient but I am desperate to get rid of my Edge based virtual devices and a little light at the end of the tunnel would be welcome.
The drivers that appear in the “production” branch are those that are automatically installed when a compatible device is paired and there’s no other driver that supports it. They aren’t pre-installed in the Hub, so, they won’t appear in the list.
If you have a device installed and controlled by a driver of the SmartThings Beta, it’s ok. The only difference between them is the enabled fingerprints for the default joining process.
From what I gather, for these type of virtual devices where their capability doesn’t inherently expose commands, you would create the events for these via the API or CLI . So for something like Virtual Presence, it’s not quite like the Groovy version where you had an arrived() and departed() command that could easily be used in rules or wherever. I agree that exposing commands via a custom capability would be much better from an end-user experience and better aligns with how people expect to use virtual devices.
For example, the following CLI command would create an event marking the virtual presence sensor as present.
If you’re in the beta group, you can verify the list on this announcement to check which devices have been migrated.
Also, if your devices joined with a stock DTH by default (this doesn’t include when you select a specific stock DTH to control the device in the IDE), they will be migrated.
This is in case you want to move to Edge now, but the team mentioned that if you have a device working with a custom DTH and you install a custom driver (eg. from a Community member) to control it, it will be migrated.
The ones you need to look further are those using custom DTHs which you mentioned are 35. For them, you need to check what actually changed because sometimes they were a little different from the stock ones, this way, you could take the official driver and apply the required modifications and install it yourself. (We can help you with any questions you may have)
Also, there are Community members that have published custom drivers and you can kindly ask them to add your device’s fingerprint (and install them) which will help in the migration-
WebCore is a third-party app, its web page access isn’t handled by ST. So, it should be available.
The Rules API can be used to migrate that automation, the team continues improving this tool based on devs’ comments.
Also, if you need help “translating” the automation from WebCore to Rules, we can help you out. You just need to create a post in “Developer Programs” and tag us @nayelyz or @andresg
No, in the app, there’s an option to change which driver controls the device. However, for a driver to appear on that page, it needs to have:
The device’s fingerprint or
A generic fingerprint that makes it compatible with the device
Yes, that is what it looked like to me. All the use cases I can think of would require the app UI and the Rules API to know how to do that. If I was in a position to make an API call I probably wouldn’t need to bother with the virtual device. I’m probably missing something though, which is why I am trying to grasp the plan.
There is something interesting sounding called command mapping for the custom virtual devices but that could be something completely unrelated.
@nayelyz sorry if I’ve missed an official explanation:
Per the ST FAQ #4, devices will be automatically migrated to custom drivers if there’s a driver installed. Has it been established how existing child devices and associated automations will behave in that circumstance?
I.e. - I have a Zooz ZEN20, which appears as one multi metering switch and four child metering switches. At migration, will the child switches all disappear, and the multi metering switch continue to exist, now with four sub-devices? Will Smart Lighting or other automations be deleted if they only use those child devices? Same thing for my ZEN25 and ZEN32, eWelink / MHCozy relays, Inovelli notification bar devices, etc.
If so I suppose a workaround would be to create a set of virtual switches and add them to the automation, then replace with the new sub-devices after ST has migrated that device. Lots of effort. If there’s room to make a request, it would save users a lot of time if ST could convert the child devices to a virtual switch during migration, allowing us to swap in the new sub-devices after the fact.
I migrated most of my devices edge drivers. I had a smartthings outlet fall offline for some odd reason so I deleted it and readded it. But now, I can’t get my routine to work that basically turns on and off the outlet based on a humidity reading from a sensor. It was working yesterday fine. Not sure if it’s related to the platform update happening today.