So, I have a rule that has a 4 second delay with cancel on truth change. It worked fine yesterday. Today it had a change and a second later it changed back but the rule was never re-evaluated as false.
So, no idea why the rule is not evaluated correctly? Isn't this the whole point of rule machine @bravenel? I mean, we're told to stop using webCoRE but Rule Machine doesn't seem to work either. What's the story?
I would need to see some information about the rule to give you an answer.
Such as? There's no easy way to get a screenshot/printout of the setting page but I can grab all of it if that's what you need.
How about a screenshot of the rule itself?
When you say "it worked fine yesterday" and today something different happened, that would suggest there is more going on than just the rule (since software doesn't behave that way in the ordinary course of events). Does anything else touch this device, any other apps?
No. And you can see in the events that I posted, on the 5th when the contact opened it went true and then when it closed it went false. Then, on the 6th, the same sequence of events did not result in the rule going back to false.
The only thing I couldn't get in was the mode restriction. And the system was in that correct mode on the 5th and the 6th. Until I logged into the system and checked the rule and saved it, it then went to fals (topmost entry in the log above).
You can see in the activity log, that the rule evaluation of true is picked up by RM after the contact is closed and the rule should have gone back to false. But the evaluation of the rule as True is happening after the contact has already gone to false.
Also, what this is hooked up to is an RF receiver that I have paired with one of the buttons on the homelink in the rearview mirror of my car. The RF receiver has a NO relay output. However, because it's a simple RF system, it sometimes gets false readings but they never last more than a second or two. What I'm going to do to try and fix this is change the length of time the trigger is required before the contact sensor registers as open. Its a Hubduino board so it's customizable. However, i think that looking at this to find out why the rule truth isn't correct deserves looking into.
I'm wondering if the mode restriction caused that. I stopped using restrictions on rules due to the funky interaction with true and false state....I try to keep them to triggers only.
If the rule is true and restriction goes into effect, the true state seems to stick even if the condition is false when the restriction is lifted because the rule is not re-evaluated when the restriction stops. Then if the conditions goes true again, nothing happens because the rule is still in true state from before the restriction.
So something like this as an example:
Condition/Rule of Switch On
- Switch turns on. Rule is now true.
- Restriction goes into effect
- Switch turns off. Rule is restricted, so no evaluation and no change to truth state.
- Restriction stops, rule is still true even though the switch is off.
- Switch turns on, nothing happens because the rule is already true.
Any chance something like that happened?
No...the only restriction was the mode of Away and it stayed in away mode the whole time. You can see in the logs that the timing is the culprit.
Open = True and Closed = False
Time 0 - Open
~500 ms later - Closed
~200 ms later - Rule evaluated as True and actions taken.
It appears that RM needs at least ~700ms between events in order to subscribe to them successfully. I've been able to rework the device to put the delay timer in there, so I won't have this happen anymore. But if that's a restriction of RM, then it should definitely be more explicit.
1 Like
Just had what is possibily the same thing happen. Here's the rule. No restrictions, this is everything.
Here one switch turned off and another one turned on ~150ms later. The switch off caused the rule to go false, switch on should have made it go back to true but didn't. The top row going back to true was me going into the rule and hitting Done.
Turn on the rule logging to see what's going on.
Isn't that what he just posted? Is rule logging something else that I'm not familiar with?
No, he showed app events. The logging is in Logs and shows the rule evaluation states.
And how do you access that if not in the rule events? Isn't the first line of his picture showing the rule evaluating as false? I'm not sure what else you're expecting to see.
On the Logs page.
This is interesting. It's difficult to see what is actually happening, except that there could be multiple instances of the rule running at the same time. There could be an issue underlying that, not sure.
It has nothing to do with the fact that the evaluation of true is occuring after the sensor has already changed states? All within 1 second from start to finish?
Yes, it probably does have something to do with that. Obviously, there is a problem, right?
There is? That's the first time you've said that. Thank you.
Hey, it's late on Friday night, and I'm slow at comprehending... I believe I know what's going on, and it isn't good. The next part is for us to figure out how to remedy it. This is anomalous behavior for a rule, no doubt. Interestingly, I don't think I've seen it before. But, irrespective, not good.
1 Like
