One of these days it's going to sink in what editing & hitting DONE does if a rule is already active

[PunchCardPgmr]

@bertabcd1234

if you have something like a delay waiting to set private Boolean or a hub variable to a certain value and are testing that value with an expression anywhere in your rule (including the required expression),

OK this is the most common case, in fact I JUST had to go in and manually change the state of a Private Boolean cause the greenhouse fan was NOT triggered ON at 80F and the temp climbed to 113F.

So thanks for SPELLING THIS OUT for me. That is the root of the problem 70% of the time, I go make a change, hit DONE...and cross my fingers that the cycle of events will sort themselves out.

Or I ponder what is active and what isn't...(ie. is that Boolean going to be changed after that WAIT [cancel-able or not] and just go in and make that overt change to the Private Boolean anyway...and then ask myself..."this rule was triggered, did I just shut it down".

....THEN later....I think to myself, could this get messed up in any other way while such that I need to put some "clean up" rule in place to mend things when I'm traveling. (along the lines of the Power Loss or Reboot Recovery Rules folks employ)

Truth be told I've even avoided editing a Rule I knew was subscribed (active) opting to not disturb it fearing messing something up (especially the case with night time Security related stuff).

Again, thanks for this discussion folks.

EDIT: At the risk of me not knowing where...and somebody saying "THAT'S IN THERE ALREADY DUDE" I have often wished I could go look at the instances (subscriptions) of a particular rule to see if I have multiple versions of it in play....and kill one or more.

[ChrisP]

I have two work around I use for rules that I tend to fiddle with, err, improve.

When the rule does its thing I'll set a local variable to the current time. When the rule is triggered I check that local variable against the current time and if a large enough difference the rule will do its thing other wise the rule will exit. Downside is that you can't evaluate local variables in required expressions. (I forget why but recall Bruce saying there is a good reason why.)

I really don't like doing it but for a few rules, in another rule I'll change the original rule's private variable to true at a certain time. Downside is that it only works if the original rule is somewhat time based.

In just thinking about this (haven't tried it yet) what about in the original rule's action run another rule's action that will change the original rule's private variable after a delay.