Currently, when you delete a device, any associated automations disappear as well.
Does ST have a solution going forward or should 3rd-party developers try to tackle this? I’m thinking an anchor virtual device that’s mirrored by a physical device.
As I mentioned in the Z wave replace thread, that would in practice halve the number of devices allowed per location, since there is currently a limit of 200. So I’m not sure that’s going to be the best approach. 
200 Device limit - How to proceed from here?
Some people currently have a single dummy virtual device that they add to automations when they are going to delete a device. The presence of the dummy prevents the automation from being deleted, and that only adds one to your device count. You can even add it to every automation at the time that you create it if you’d rather, since it has no purpose except to keep automations from being deleted so it doesn’t matter if it’s getting turned on and off.
Not necessarily, it depends if they remain viable with the condition or action associated with the device removed. However that doesn’t change the thrust of the thread.
Bear in mind that this is something ‘the app’ does to Routines and Scenes. It is not something that happens to Rules in general. I have no insight into what is coming along Rules-wise apart from having seen a ‘Recipe Creator’ mentioned and having assumed that will be a developer grade front end for creating Rules which will hopefully encourage broader adoption of Rules instead of the cut down Routines built into the mobile apps. Hopefully that will handle the situation with deleted more elegantly.
OK, so the automation may remain, but you still lose any condition or action which references a deleted device. I typically create the new device, click on routines, add the conditions/actions for the new device and then delete the references to the old device. Of course, getting the conditions back in the same order (might have some short-circuit logic advantage) is like playing Towers of Hanoi. I just did a bunch of this when switching to Edge drivers.
So, you have a choice of 2 projects. Either mirror placeholder devices or write a ‘Recipe Creator’ that uses external symbolic names with a mapping to physical devices. I don’t know if ST just has a lot on their plate or is intentionally dragging their feet to see what solutions the community will create for free. It seems that WebCoRE is most likely to ultimately pick up the slack.
Webcore is a groovy program, so it will go away when the SmartThings -hosted groovy cloud shuts down.
The shift is to the new Rules API, Although it’s not at feature parity with Webcore yet. But it’s still in development. ( they call their equivalent of Pistons, “recipes.“)
Some people have been experimenting with the automation studio as you mentioned in your next post and nodeRed, but there seems to be a limit on the number of flows you can create right now. I don’t know if that project is still in development or not.
There’s been some discussion in the forum, such as the following thread:
That is a little vaguely documented if you aren’t otherwise familiar with Node-RED (I’m not), and there is an element of uncertainty about its future caused by it being presented as a free trial. If nothing else it is useful for cross Location automations so I hope it sticks around
Samsung have made the SmartThings plugin (I don’t know the terminology) available for users own Node-RED installations. Plenty of users seem to really like it. It doesn’t really float my boat.
1 Like
Also @rossetyler has been doing some interesting things along the same lines of what you’re suggesting.
I meant a WebCoRE updated to use the new ST APIs. WebCoRE already has all the machinery. It just needs a new interface to ST.
Automation Studio can see my devices, but I wasn’t able to create anything useful. Looks more like a mock-up than beta.
1 Like
To the best of my knowledge, in the 28 months or so since ST presented a proof of concept of webCoRE running on the Rules API and invited the community to take it forward, absolutely nothing has been done. There hasn’t even been any talk about it.
WebCoRE pistons are Groovy SmartApps running in the SmartThings cloud. Take that away and there isn’t much of webCoRE left beyond the piston syntax.
There is a future for webCoRE on Hubitat. The only way I can see a future for webCoRE on ST is if Ady has quietly (or rather silently) been doing it all himself.
As I know you know, but @nmpu may not, Webcore has their own forum which covers both the smartthings and the Hubitat versions, so people can see what’s current there.
As far as Ady (The original webcore author, for those not familiar with the history) he left the smartthings staff a few months ago and is now working at Chewy. Com according to his LinkedIn page.
It’s at least being actively maintained. But I think usage wise it ranks well behind Rule Machine and even Node Red.
1 Like
Sorry for digging up an old post. I’m way behind on updating my devices and ran into this same issue as my rules slowly “disappeared” when devices were deleted to be replaced with edge driver devices. Both automations and smart lighting app rules were affected.
Automations should break when a device is deleted out from underneath the rule. I just don’t want them to disappear - I wrote some of those years ago and can’t remember them until things stop working like they used to.
If the ST app UI could be made richer to hold onto those existing rules/automations by disabling instead of deleting them. Even better put some type of notification like a red background on the disable slider or some icon - similar to the home icon that shows local execution - so I know the automation is broken and needs to be reviewed/fixed.
It would be nice if there was an advanced lifecycle feature to “replace” a device. This would stop my external links like Alexa from breaking as well. For now just don’t eat my automations please.
4 Likes