I have at three rules that have all gone bonkers. They all use Sonos to notify when a contact sensor (fridge, freezer, or pantry) has been left open. I also have three sibling rules to terminate the Sonos alert when the contact sensor closes.
I want to restore the individual backups of the alerting rules but have the following questions:
-Should I rename or delete the existing broken rule before restoring its backup?
-Will the sibling rules that terminate the Sonos alerts need to be modified or will they associate with the restored rule automatically?
Thx
This depends on whether you removed the original rule. "Restore" and "Import" are similar but have slightly different outcomes. If you removed a rule (or any app), you can do a "Restore," and this will give it the same app ID, and other rules that reference pausing/resuming that rule, setting private boolean, or other rule-specific features should work as before. If you "Import," it will basically be a new rule, and you'll have to re-associate actions like the ones I mentioned in your previous rules (it is like cloning in this sense).
It should also be noted, because it's not clear what the original problem was, that if you removed a rule because you think it was corrupted, an export and import or restore won't help--the old internal rule data will come along. Re-writing would be the recommended path in that case.
EDIT: I should add that this applies to recent platform versions. If you're still on 2.2.6 as your profile suggests, then...I don't recall, but I wouldn't suggest that unless you have a specific reason. 
3 Likes
Appreciate the answer but you appear to contradict yourself.
What is internal rule data?
I'm on the latest platform release. Need to update my profile.
I donāt think itās contradictory, itās two distinct elements.
With a restore or import, all the content of the new rule will be the same. The triggers, conditions, actions, events etc. So if the old rule was corrupted in some way, the new one could be too presumably. One key difference is:
Restore = same app id (same as the old rule)
But import = new app id (as if it were āa new ruleā)
So it sounds like youād want to try deleting your rule and then restoring. That way youāll be able to maintain the āsiblingā rules you mentioned. But as @bertabcd1234 said, depending on what ābonkersā means, the restored (or even imported) rule could potentially have the same issue I think.
2 Likes
No, as @marktheknife noted, I was referring to different things. By "new rule," I just meant that existing rules that reference the old/existing rule will not be able to associate with the "new" rule automatically for actions that refer to other rules, like pause/resume, Run Rules Actions, or Set Private Boolean. You will have to edit those actions in other rules to point to this one. This is because a cloned or imported rule gets a new (internal) "app ID," and that is how other rules and apps refer to these.
This is the part that isn't new. 
The internal rule data is technically things like the settings and application state (two internal structures of all apps, including rules--an aspect of development you don't really need to know much about as an end user, but that's how apps can store things). This includes selections you've made in the app UI, plus other things the app may choose to store for itself to keep track of whatever it needs. So, again, if you have something that is "messed up" in one rule (e.g., if opening it throws an error), then cloning, importing, or restoring is unlikely to help--all your old selections and whatnot are going to be there still. If you are just testing new things and want a way to go back to the old rule easily, then this doesn't apply. Just wanted to make sure you weren't headed down a path that was unlikely to help!
2 Likes
Okay, in summary:
Restore will replace an existing (or deleted) Rule with the same app ID.
Import will create a copy of an existing (or deleted) Rule with a new app ID.
Correct?
Yep! (Also, clone behaves similarly to import, if you are wondering.)
