I have several 5.1 rules that are meant to control status displays (switch LEDs, etc) that I find are obviously out of sync with the status of the device(s).
When I look at the rule, all of the state values are current but it looks like it never ran even though the trigger should be true.
If, I change the state of a trigger (I.e. a door lock), the rule does not run.
If I “update rule” then change the trigger state, all is well until the next time I notice that it is wrong.
I have tried to correlate with things like hub updates, restarts, internet connection issues, but nothing definitive.
I would like to proactively run “update rule” on all of the rules daily until I am able to determine what’s wrong, but that’s not realistic.
What evidence supports the rule having not run? (I know the outcome for sure, but it's not clear if this is why.) Enable all logging for the rule, and provide output of the logs filtered to just this rule when you think it should have run--or note if you still don't see anything with all logging enabled. Also provide a screenshot of the rule.
Dang it, just found another in the “should have run” state.
Changed the trigger device several times to be sure.
BUT, didn’t have any logging turned on and when I turned it on and saved, the rule began working properly again.
Also, what does the "Events" page (accessible from the device detail page) for each of the trigger devices look like?
If you notice one that isn't working despite all looking OK: capturing the "Event Subscriptions" section on the app status (gear icon) page for the rule may also be illuminating, although you won't be able to do or change anything there.
FYI, I opened rule to look at it and it is still in “bad” (running) state. Just looking hasn’t changed anything yet.
So if any information in th details is valuable I can capture.
It seems like your first action (setStatusLED(6, 'Off', 'No') on Sunroom Light, Bedroom Light) changes the "variable:LED_Refresh" status -- is that a correct correlation ?
If so, that seems to somehow keep the rule stuck in a running loop.
I realize "changed" triggers should work fine (and probably do in many cases), but I've stopped using them altogether... I've found they are often too mushy, especially when the corresponding trigger events typically change back-&-forth very rapidly (door contact status, lock status, etc) or can otherwise change while the rule is in motion.
I can well relate to the attraction of getting a desired result all under one single rule, but for the two rules posted in this thread so far, I'd instead split them up into seperate rules with distinct/specific triggers.
I haven’t had issues with changed, but I they can be related to the “still running” issue, I can live with double the triggers (on/off,true/false) for these rules.
Yes, if you will post screenshots of the complete logs for a rule that doesn't behave as expected (copy/paste of logs is unreadable). The 'running' state is new, and it is possible that it still has some bug.
Exit Rule is one special action that sets 'running' to false. I just checked this for Exit Rule in IF-THEN or Simple Conditional, and 'running' is indeed set to false by Exit Rule. Also, a rule completing all of its actions sets it to false as well.
It looks to me as though you have a race condition with it being triggered rapidly. There's only 5 msec between end of running and new event, which is not enough time for the app's state to have been updated:
Do what @hydro311 suggests: Get away from *changed* triggers followed by a test on the same thing, split the rule, etc. Get away from using the toggle for not triggering while running, as that is killing your rule.
What happened is that the second instance, the one that reported NOT Triggered, grabbed the rule state while 'running' was still true, then that instance wrote state back when it exited, overwriting the first instance trying to set it to false.
No, it's not a bug. It's a race condition. Events in the real world happen faster than the software can process. App state is always written when an app exits, that's how the platform functions.
Dealing with race conditions can be difficult. Generally, something has to be slowed down, or filtered somehow. Splitting the triggers reduces the rate of trigger events, getting rid of the IF-THEN speeds what's left. What is setting the variable? That's happening awfully fast. If it is being set as a consequence of this rule running, then you are creating your own race condition with that variable changing as the trigger...
These rules monitor the states of doors, windows, lights, HVAC, etc., and light various LED in meaningful colors to show me the house state in a nutshell.
It is these things changing state that tells the rules to check their devices and to update their LEDs.
Randomness is not controllable.
So, during this brief period of time there are two threads holding copies of the app state and obviously the active thread turns off “running” (among other things) while the “blocked, not gonna run, thread” holds a stale copy…. With which it dutifully overwrites the “real” state.
Honestly I am surprised that this isn’t a much more pervasive issue.
If you can’t fix it with a mutex or such, then would using the private Boolean method be any less likely to lockup?
