Hi, Just acquired a few XHS2-UE contact sensors but I am having trouble with a simple open door close door time out rule. The closed event seems to never happen. Here is the rule...
and here are the logs for the rule. If I close the door before, the timeout, the 'Off' action never occurs, but if the rule 'Wait for event' times out the Off action happens. Am I missing something here or am I approaching this incorrectly? I have always thought that the closed event triggers the rule again...cancels the wait for event... and proceeds.
Also sometimes seeing this error: org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: GenericZigbeeContactSensor.recoveryEvent() is applicable for argument types: () values: [] (method recoveryEvent)
Could this be the reason? I am using the 'Generic Zigbee Contact Sensor' driver
Your error is likley not related to your problem, but it also means that you were not using the driver you are now at some point in the last. To fix that problem, go to Logs > Scheduled Jobs, find a job with the name "recoveryEvent" for this device name, then hit the delete (trash) icon in the Actions column for it.
As for the rule, it looks fine to me (assuming you always want the "Off" action to run at some point), so I'm not sure why it isn't working. Maybe try re-creating it?
Ok, that would have caused the issue.
In the latest version of your app, I think you have to explicitly cancel the delay upon entry.
Wait(s) should auto cancel.
Xxxxx Never mind
I would check event history for contact and see if the close is being caught by the app.
Xxxxx I see in the log that app is getting event…
You see the rule executes when the closed event happens but the 'IF' statement returns false for the closed condition. So is this a new RULE MACHINE problem??
No, not a Rule Machine issue, rather a rule design issue.
You appear to have some sort of race condition. There is a very short period of time after the device has closed (the closed event) and the test of the closed state in the first action of the rule. About 200 msecs based on your logs. Evidently, that is too quickly for the device attribute to be updated by the event, so when the rule tests it, you're getting this contradiction.
Now, the obvious thing is, why test the condition at all? You know it closed because of the trigger event. If you introduce a one second delay before the test, if will most likely work as expected. For some devices, you can go to the device page, hit a command, and watch the attribute change. For some devices it is nearly instant. For others, not instant. That's the crack this particular case falls in.
You didn't ask, but I have a very dim view of rules that use *changed* in a trigger followed by an IF-THEN to see what happened. That's not a smart approach to this sort of problem. Just use two rules instead, and you won't have this sort of issue. Rules are free.
What type of contact sensor is this? Have you watched the device page while this device is in use? There's no magic here, just time before the device attribute is being set (none of which is RM).
And why does this matter?
Since the EVENT was generated the Device obviously changed its state.
So, 5sec is not enough for evaluating new Device state?
Yeah, all of that happens in 0 milliseconds, right?
@WetCoaster isn't the first person to discover that testing a device state immediately after a device event doesn't yield the expected result, due to timing issues. @vitaliy_kh has encountered this problem as well.
The point remains, there are always going to be timing and indeterminacy issues associated with events and states examined with close timing, and it remains true that there is no need to push on this particular issue in automations (except for case where a user wants to merge multiple rules into a single rule with lots of IF-THEN-ELSE to sort them out).
If you look at my first post #1 you will see my original rule. The closed event was not firing and the Off action was never being executed. That's what led me to do these tests. So I am not sure your reasoning is applicable here, perhaps it is I don't know. I am trying to find out why my light was never turning off.
No, there is always a Delay but Event is always happens before any change related evaluation.
And introduced 5sec (yours suggestion was 1sec) should/must be more than enough for reevaluating new Device state. I don't see any reason why this test rule is not working.
The device event for closed is in your logs, and recorded by the app as well.
And you know this how? You've put in detailed logging and compared all of the timings?
As I have explained maybe 10 times, the hub is multi-threaded, there is no determinacy as to relative timing of threads.
Consider that if simple device attribute tests were failing in RM, that would result in an avalanche of posts about RM not working. But, rather, the only posts all have the same thing in common: an event that triggers a rule that immediately tests the state of the device that generated the event.
This isn't even interesting any more; I think ten explanations is too many...
I am sorry but this becomes very interesting. In a past we were talking about only few mS and all the explanations were reasonable. But now we are talikng about 5sec. After this enormous delay everything must have enough time to complete and even multiple times.
