Apparently I don't understand "Wait for Event with Timeout". I was thinking if the event occurs, then the rule will move on and execute the next statement immediately. But this seems to be waiting for the timeout to complete even though the event has occurred. In this case I am waiting for the Ring alarm to be "off", and if so, continue with more action. But the logs indicate that it is delaying until the timeout is complete. What am I doing wrong?
This how it works.
I am not familiar wit the ring hub integration, but I think I follow your logic. It looks like once you set the mode to "disarmed" the ring integration then sets it to "off." I can't see anything off in your logic if I'm understanding it correctly. You might try changing "wait for event" to "wait for condition" and see if that helps, but that's just a guess.
Yeah, from what I've been able to tell, the Ring setMode command has to be set to "Disarmed" (off is not an option) and this actually returns an "off" state, which is fine and what I want. I thought the log item I have highlighted below meant that the event has occurred and the Ring is in the off state at that point. I must be misunderstanding the difference between wait for event and wait for condition.
Yes that's how I read it as well. You'd think there would be about an 8/10ths of a second delay and then things would continue to process. What version of the hub software are you on? Also try changing the WAIT FOR EVENT to WAIT FOR CONDITION... EVENT should work just fine but I'm curious.
What's interesting is the Ring integration appears to send the "off" event twice...
I am on a C-7 Hub, FW Version 2.3.2.135.
I will try the WAIT FOR CONDITION option this evening when I am back home.
And I thought it strange that Ring reports the event twice as well!
Thanks.
Just for the heck of it you might update to .138. I looked at the release notes and didn't see anything obvious but you never know. If WAIT FOR CONDITION doesn't work you might also try moving your question to a "ring integration" thread. It might get more attention from Ring users and maybe one of them has seen this before.
There is another report of problems with the Ring integration and a rule not recognizing the triggering event, or in this case the Wait for Event event. I'm not at all understanding why this is failing.
You definitely need to be on the latest version. Also, if you can grab a screenshot of the Event Subscriptions before the timeout expires, but after the Wait has started, that would be helpful.
It would also be helpful if you could edit the Wait for Events action, and take a screenshot of what comes up. Don't change anything, and you can cancel out of that.
Ok, I can do some more testing either this evening or tomorrow morning. And I'll upgrade to the latest version as well. Remote right now.
I am not sure where to find the Event Subscriptions. Is that under Logs?
Below is the screenshot of the Wait for Event action edit:
OK, well it's not the problem I described.
Am I right in assuming that as soon as Ring reports being OFF (the event occurs), that the rule should immediately begin to evaluate the next statement (in this case my IF statement), making the timeout moot?
Yes, that's right. It's not seeing the event properly, and I don't know why. You could do a small test: Create a simple rule with a trigger on the Ring mode turning off. Turn on Event and Trigger logging. My bet is that it won't trigger.
Ok, all is good now. I upgraded firmware to latest (139). There was also an upgrade available for HPM and the "Unofficial Ring Integration", so I did those. Tested a couple of times and works as expected!
Mine is broken again this morning and not responding to the event trigger...so need to run some similar tests. I may need to try to convert to condition driven rather than event driven.
It is frustrating when a problem is not repeatable with consistency. I tried the test @bravenel Bruce suggests and the event as a trigger worked the first and every time thereafter. I then triggered my rule that began all of this questioning, and it worked fine. No delay on the wait event. I am not sure what is breaking but I definitely need to find a more robust solution.
As usual, need to see the logs from this when it doesn't work as expected.
Yeah, sorry Bruce, Here is the most recent failure, but now I can't get it to break again...
And here is what it looks like when it works:
Two things: in the first set of logs, there were double mode off events back to back, and a blank event at 07:30:00.435. These are suspicious, and suggest this driver isn't quite right.
In the second set of logs, those things weren't there: just a single mode off event.
I don't have this integration and can't really dig into what it's doing, and how that interacts with RM. But, I'd look for those things going forward as clues.
1 Like
