Wish editing a rule (and introducing an error) didn't lock you out from undoing that error

I think I just learned a lesson to create a temporary CLONE of a rule before editing it. I've never thought to do that as a precaution as "getting locked out from editing" has been happening less and less, either due to fewer of MY mistakes and/or an improving RM.

I had added some variables to store humidity from a couple of so capable devices. I think I had selected NUMBER as the type for those. Then I went up and was cutting and pasting a SET variable line I had from storing temperature from the same devices and was going to just go in and change out the variable name and select humidity.

SOMEWHERE in that process, likely my fault, but I'm actually not sure how and why, I ended up bounced out and not able to reopen the Rule to edit it due to the above pictured error.

At this stage I just wish I was saved from mucking about in the rule. I tried cloning.. and the error carries, I tried exporting and re-importing.... and the error carries (but at least there's some code I can see to remind me of all the things I did in the rule).

That last part is "the irk", I can understand that "sh_t happens" be it due to user error or software bugs, or software intolerance. But when these things happen and the rule is flat out unreachable that is irksome.

1 Like

Without knowing what you had in the rule with 0.0, it's pretty hard to know where a protection against this error would be needed.

Yeah, I get it...I'd just like to go back and recreate the problem for ya. But that's the point, there's no going back now.

Only 0.0s I am seeing on the Rule Status page is in a stack of Value Offsets.

OK, I'm rebuilding this rule by looking at both the Rule status page and the extracted JSON file to jog my memory at all the variables and actions I had. It's a simple environment status announcement rule but a bit long with all the variables I set on a daily scheduled triggering

In my editing that led to introducing an error I had just added new variables for humidity (integer) off some motion sensors I was already reading temperature and setting appropriate variables.

I was starting to create the SET variables commands for the three new humidity readings and I did this by CUTTING & PASTING the existing rule line that was used to SET a temperature variable (decimal) then I was going to go alter the statement to humidity reading from a temperature reading. Figured this wouldn't be a problem as long as I was still in Editing Mode.

In looking at the pieces I now have to work with to rebuild this rule, sans error, ...I see where I got to the point of setting up:
Set humid-greenhouse to DoorLR - Greenhouse - Temperature

Where humid-greenhouse is an integer variable and DoorLR - Greenhouse - Temperature is a decimal temp reading off the motion device.

This isn't what I wanted of course, I was going to go alter that to read DoorLR - Greenhouse - Humidity (presumably an integer value indicating %). Somehow I ended up OUT of the Editing session and never able to get back in and finish the work.

So the question is...might this be the source of the error? Decimal vs Integer mix up.

I don't think so. It looks like it was a string value "0.0" that was entered.

OK. Thanks.

Not sure what all transpired on this.

So I rebuilt the three year old rule and was very grateful for what was available TO BE VIEWED in order to remember all the components and reconstruct it ....even if I could not see it in the more readable editing mode.

I am a huge proponent of this, especially with complex rules. It allows you to go back to a previous iteration of a rule easily.

Could you not used a nightly backup to go back in time before this rule was corrupted?


Could have in theory...but this particular hub is operationally relied upon for a number of farm related things come summer. The risks of doing a restore in the middle of the operational day are an unknown factor for me. I guess I considered restoring from backup a "last resort" when lots of critical things have run amuck.

In this case only that specific rule was impacted. Just don't know for sure what impact there might be on states, conditions, variables, "getting things out of sync" etc. in the sense of resets/undoing/reversion to the "as was" conditions "when that backup was taken".

This C-5 works SO RELIABLY WELL...under some pretty adverse conditions...that I just try to tip toe around it during these months, even ceasing software upgrades till Winter.

EDIT ADD: Lemme come back around to my original post and say that there were things I could do all around getting info about the subject rule, including successfully exporting the JSON file, i just couldn't edit it due to the error. I mean if I felt confident editing the JSON (and what to edit) I guess I could have even done that and imported the file back into HE. It begs the question, and I'm going to speak beyond my knowledge here, but what if this editing could always be done (or maybe allowed to be done after a problem occurs) in some sort of "sandbox" environment where errors of any sort are flagged and acceptable things to be dealt with without locking everything up. Just thinking out loud as I'm not the first to get tripped up introducing (or encountering) an unrecoverable error in a Rule.

I've had this happen a few times now. So what I do now, before I make a major change to a rule, is I clone the rule and then disable the original rule. I make edits to the new rule and if they survive a period of time without glitches, then I erase the disabled original. If there are bugs, I edit until I fix, knowing I can always delete the modified rule and go back to the original at any time.


Yes, as of yesterday that has become my standard practice and should be an HE Best Practice in the Documentation . Thanks.

Without knowing the internals I can paint a picture of a time in the future where a user opens a rule to edit and the system creates a versioned copy whence upon competition of your edit you are asked if you would like to make this latest recently edited version live, and maybe you have to purposely delete that previous version if you don't want it sitting in the stack DISABLED.