I've read prior occurrences of this but found no solution. Per the subject, I'm making a ton of edits (and backing up regularly) since integrating a new Envisalink. I've experienced 3 corrupted rules in as many days--the causal step is always the same: I copy/paste something. I've re-created 2 rules so far but this one is lengthy and the recurrence/pain is high hence reaching out.
I've tried cloning and replacing devices--didn't work.
I've tried exporting/importing in the hopes some syntax/coherence hygiene in the import codepath might fix it--didn't work.
I've tried looking at the exported JSON--nothing obvious in there (needle in a haystack mostly, though, prevented anything useful).
Looking for suggestions.
Happy to post the entire metadata and JSON if needed but wondered if there's a trick?
@bravenel for any assistance since he's addressed a few of these over the years (TIA!).
Feature suggestion: CTRL-Z for rule machine; rewind 1 minute or the like.
To your question: tough to say but I believe they were a jumble of variables & equality conditions whose actions changed the state of some device or another. If I could get into the rule to see the clipboard, I could be specific... but I can't.
LOL... obviously, I would've done that if I could. I'm unable to get into the Actions editor, doing so triggers the errors I pasted. Is there another way to edit Actions, perhaps a command-line interface I'm unaware of?
I am not able to reproduce any problem with copy/pasting actions like yours. So I have no way to determine what is causing this problem. You will have to recreate the rule and avoid copy/paste -- unless you want to attempt to determine exactly the steps that caused the problem.
There is no "command-line interface", or any way to repair this rule. I'm sorry there is a problem, but for the moment there is no way to determine just what it is so as to fix it.
And actually, I think I was wrong earlier--the error I posted before appears to also have been caused by me trying to enter the Actions editor (the Sonos speaker was relaying a lightning warning at the same time hence... unless the error returned is the same which seems unlikely).
does the update address the cause of the rule corruption or the inability to edit the actions of a corrupted rule... or perhaps both?
Thx!
// EDIT: @bravenel , I can repro this now. Net net: I restored to a 2-day old backup, exported the rule, restored back to a moments-old backup, recreated the conditional delay, copied it, pasted it... broken. The live logs, however, reported the same error I've already posted. What I do have, though, is a working copy of the rule in an exported JSON file... happy to provide it if helpful.