There is actually something you could do for me to help find the issue. I need to see the entire Application State of the rule, both right after you update/initialize the rule, and then later after it has run successfully. Application State is on the App Status page (gear icon). This may entail multiple screenshots as there is a lot there. Whatever difference is causing the failure should show up there.
2 Likes
I tried using 'Wait for expression' instead and still had the same failure. The app logs that it is waiting for the expression (door closed = true) or the timeout, then the door closes and nothing else happens. I switched it back to 'wait for event' and it's failed several times since then. I also edited another rule that was also waiting for the front door to close to see if that was somehow the issue, but even with this rule as the only one subscribed to 'front door contact closes' it still intermittently fails to proceed after the event occurs.
I'm going to try one last thing before giving up. Instead of using the timeout option, I'm going to use an expression of "time since event: door open > 5 minutes OR door closed = true" and see if that works.
Hey Bruce, sorry it's taken a while to get back to this. I thought about starting a new thread but there's too much already in this thread for me to copy over to keep coherency.
Just to review: the rule stalls after consistently after it's very first run after being initialized and the behavior is repeatable by going to the rule page and then hitting "done" to initialize it. The first run after "Initialized" always fails to complete. Any subsequent attempt to run the rule will complete successfully.
Anyhoo... Here is the info requested:
App Status page after successful rule completion:
App Status page after successful rule completion:
Both of you legends above for the screenshots say the same thing. Are these different, one after hitting Update or Done, and the other after successful run?
I really thought so, but it's entirely possible I messed up somehow... I'll initialize it again and post the results. Will probably be later tonight before I get a chance.
Sorry this is split across two threads, but I thought I'd follow up back here on the thread I originally started:
This happened again with my alternate syntax as I posted on the other thread:
So now that syntax has failed also. I just had back-to-back success and failure of the rule. Here are the logs. If there is anything else I can provide other than the logs, let me know.
I grabbed the screen shot starting with the required expression going true at 13:18:37.
- At 13:27:03.347 the rule triggers. You can see the front door opened just before that
- At 13:27:03.589 it begins a wait for the front door to close or for 5 minutes to pass since the door opened
- At 13:28:16.383 the front door closes (logged by the device)
- At 13:28:16.450 the rule logs "Wait Event: Front Door contact closed"
- the rule then finishes its actions
Success!
THEN
- At 13:31:12.493 the rule triggers
- At 13:31:12.722 it begins the wait for event or time since event
- At 13:34:52.647 the front door closed (logged by the device)
- Nothing was logged by the rule or device since that time. The rule should have logged exactly what it did the first time.
FAILURE!
This is frustrating.
The only thing I can suggest is that when it fails, to immediately get a screenshot of the Event Subscriptions from the App Status page of the rule (gear icon), and post that here. It's clear that the app didn't see the event, but not clear if it was even looking for it. If it wasn't looking, that would be a bug. If it was looking but didn't get the event, that's a deeper issue.
So I'm running into a similar, but opposite problem with "wait for event" - I have 4 virtual switches. I have a "wait for all" to be off. I can see in the logs that all devices are successfully turned off, but then the rule suddenly stops and doesn't proceed to the next item. No errors, just nothing. Reliably - 100% after 20 tests.
After reading this thread, I added a "timeout after 2 seconds" to the "wait" and it suddenly started working.
I then removed the timeout option and the "wait for 4 switches to be off' suddenly started working.
I spoke too soon. It's not working without the "timeout". Adding the timeout to the wait for event causes the rule to proceed. And since these are all virtual devices, it's not like it's waiting on a physical switch.
Since these are virtual switches, what is turning them off to generate the event?
I seem to be having a similar issue with a rule of mine, or I am missing something.
The rule: This screenshot was captured after the rule was triggered, see log below. Private Boolean is still false. Could the cancel pending actions be an issue?
The log: At 07:22 the smartplug is < 50 but it just sits and never completes the rule. It's a little after 8:00 at the time of this post, and it is still waiting. Smart plug is sitting with nothing plugged in to it.
The event subscription:
Hopefully this is ok, I guess if it isn't Bruce can flag this comment as well.
Yes, the Cancel pending actions is the problem. Turn it off and verify the Wait works without it.
Example with and without Cancel pending actions to show the problem.
Without first - works as expected
With - not working. I updated the rule after a few minutes to add a time stamp to the log to show that I waited more than 1 minute.
another rule machine app that changes these based on what is happening... (basically, like a logitech harmony - these switches represent "activities" trying to tell me what the current activity is so I can have a different light on for each
Would you post the logs that show the issue?
I had forget I had used that. I noticed it just after posting, while looking over post one last time. Didn't have time to test was about to go to bed. Thanks for checking it out.
So the slide should read cancel all pending actions while the required expression is false? This is the first time I have used that option, and thought it could cancel the wait for turning off the smart plug, if the rule were triggered again during the 1 minute delay after the rules completes. I guess I will just add a cancel pending actions.
2 Likes
That's the problem, there's nothing in the logs - if I put in the timeout, the rule and everything after the "wait for" happen as normal. If I take out the timeout, the "wait for" is the last thing that happens in that rule. There's no errors anywhere - even in debug. I'll do some before and after tests and gather
That was definitely the problem. Works fine with that option turned off. Is this a bug, or do I not understand how it supposed to work?
With the cancel pending actions, as soon as the required expression goes false, it will immediately cancel the rest of the rule. In your example, you are canceling the rule once the first action happens. Your Private Boolean goes from True to False and this triggers the cancel pending actions. The cancel then wipes out the rest of your rule, which is why it does not run.
The rule did run. See screenshot above. It ran to the wait for event and appeared to be waiting. The Private boolean is false but the event of the private Boolean going false occured at 7:07:24.128. The pending action did not occur until after, at 7:07:24.942. Not quite a second later but it was after. Also there was nothing to Cancel at the point the rule was triggered.
Edit: Is a pending action everything or an event subscription?
