You have everything in your Smart Home knitted together and purring and then a hardware failure occurs. With SmartThings, replacement hardware will come with its own/new device id that will not be referenced by the old rules. All of these references have to be tracked down and changed. Did/can you find them all? How do you know? Good luck. It is way worse if the hardware failure was the SmartThings hub itself. Start all over. People have been complaining about that forever.
I am a new SmartThings Edge Driver developer and run into this issue every day. In my development cycle, device ids are like tissue paper: I blow my nose into them, toss them out and create new ones. This breaks all the Rules.
So, I have started to script my rules in Python. As input, these scripts take my inventory of devices and cross reference their ids by the unique labels that I (and my Edge Drivers) give them. Output is SmartThings Rules JSON input that can be applied with the CLI. All of the software build/deploy dependencies are specified using Gnu Make so that a change in inventory or rule source will automatically be reflected in the deployed SmartThings Rules at my Location.
I am building my solution to address my limited needs but I can imagine a much richer solution that would support the whole SmartThings Rules API. The upside to this solution is that it addresses the stated problem and it is now easier for me to write, maintain and deploy my rules. The downside is that I have to maintain this infrastructure and that none of it is accessible through the SmartThings App.
Definitely not the only one: this has been a weakness of the smartthings architecture from the beginning. No backup/restore and only rarely a migration tool. (Right now there isnāt a migration tool.)
Some people have done as you have done, others have just put up with the frustration.
Many competing platforms, including Hubitat and Homeseer, are just much more user ā friendly in this area.
There is some hope that there may eventually be more utilities of this type once the transition to the new architecture, including edge, is complete, but I havenāt seen anything official on this.
Tagging @joshua_lyon just in case he has any thoughts on this, since he wrote one of the earliest third party rules engines for SmartThings.
No, you arenāt the only one. One glaring omission compared to the Classic app is there is no longer a z-wave replace function. A backup/restore/replace function has always been missing. One good thing that has been added recently is a Routines tab on the device page so you can see what Routines the device is used in. Makes it a little easier to manually replace the device in automations (assuming you havenāt deleted it from SmartThings yet).
Yes, that might be considered another downside to my solution. Although, I suspect, Automated Routines generate Rules, my generated Rules are not considered Routines so they donāt show up in the SmartThings App. I guess that is OK as my solution addresses the need for such cross referencing anyway.
Now that I am creating, destroying and recreating hundreds of devices a day (with my Edge Driver development) this has become a huge problem. I suspect that developers in my position are much more sensitive to this issue.
I knocked up an app on my web hosting that, among other things, gives me a cross referenced listing of my devices and Rules and flags any unknown device IDs that crop up, and where they are.
I use VS Code to edit my Rules in YAML (it makes them almost readable), and use YAML anchors and aliases so each device has a meaningful name and the device ID only appears once in each file. If I have to change a device ID I already know what the old ID is so it is simply a matter of looking in one of the Rules to confirm what it was, and then doing a global find and replace on all my Rules to replace the old ID with the new one. Then I just run GNU Make and itāll update my Rules for me as required. The actual updating is performed using a batch file which determines whether a ācreateā or āupdateā is needed and works out what the Rule ID is. I havenāt used Makefiles for well over twenty years so I thought Iād keep them simple. It also means I donāt actually need to use Make if I donāt want to.
As a āRecipe Creatorā app is supposed to be coming along I didnāt think it was worth getting too carried away with the Rules creation side of things just yet.
I am working on replacing an old Groovy SmartApp that controls my perimeter lighting using sensors such that the brightness of each light reflects the nearness of the stimuli (open doors and motion) as well as well as daytime, ambient illumination and visiting hours. The meat of my Python logic is less than 50 lines long but generates close to 1500 lines of JSON input for the Rule. At the rate that I am churning, I cannot afford to do anything less that what I am doing now. Continually editing JSON would certainly carry me away.
My Makefile is around 30 lines long but imposes patterns on the implementation files of the rules. I can easily add rules that adhere to the pattern without changing anything else. For each, I keep a āruleā file around with the UUID of a previously created rule so that I know whether to create a new one or update the old one.
I am not sure that any āRecipe Creatorā app would address my use case well. Anything with a GUI will always be much slower than just typing āmakeā.
