I created a rule that's supposed to detect if it's been ran in the last 5 seconds-- and exit if it has:
but sometimes it does run within 5 seconds:
I was sure to click 'Done' on the rule.
Notice the (skipping) on the 2022-04-15 02:53:41.133 pm line even though the IF has [TRUE] on it. Does that have to do with anything? the conditional is being evaluated to TRUE, but then it has a strikethrough on the Exit.
Am I doing/expecting something wrong ?
If I had to guess, and that's all I can do since everything else looks correct except the oddity you note, this might be some sort of race condition due to your rule being triggered twice in a row about 300 ms apart. That is quite fast, so you are likely dealing with concurrent/re-entrant execution, which can cause problems. (It already looks like now from the second execution is getting set before the IF THEN from the first is even reached, though that shouldn't cause this particular problem.)
What is triggering this rule, and is there anything you can do to prevent that from happening? (I'm guessing not and that's why you have a rule like this in the first place, but it's worth asking...) If not, I might see of some alternative fares better--perhaps a required expression instead of a conditional in your actions. But addressing this on the device side, if possible, is likely to be the best idea.
an HSM Disarm. I'm using the Ring Keypad Community Driver (awesome btw) that can sync multiple keypads. the way it does that is by arming/disarming the remainder of the keypads when one of them is manually armed/disarmed. so with three keypads, when you dis/arm one of them manually, HSM gets 3 dis/arm events -- one from the manual keypad you touched and the others from the driver syncing the other two.
EDIT: actually i'm not even sure that it's the driver now that i'm thinking about it. maybe it's just HSM doing the syncing? not sure. in either case... something is syncing them.
So I want a rule that'll send me a push notification when HSM is disarmed-- and figured using the 'now < lastrun+5' could keep the rule from running more than once in a given period.
yeah, Ill see if that can make a difference.
there doesn't seem to be any kind of now() to compare in Required Expressions. maybe a feature request for @bravenel
Right, you may need to re-think the logic a bit to something else that would get the same outcome. Something like this might work:
unfortunately that's not fast enough. even with the first action being set the boolean = false, the 2nd iteration of the rule has already started while boolean = true.. was a good idea.
Hm, so back to the other idea: I'd really try to address this on the device/driver side. I'm not familiar with that particular integration, but perhaps a second or two of delay between arming all the keypads would be enough to just eliminate the duplicate events in the first place.
Not sure if this applies to RM but my immediate thought was I'd want brackets around the (lastrun + 5000) just to make sure it was evaluated in the right order. Though logically I can't see any other order it might mistake it for 
Download the Hubitat app
