This may be basic but I haven't found it. The short version is, does a required expression turning false cancel a wait for event or wait for expression? I know retriggers or exiting a rule does, but my understanding was that (as long as the cancel pending checkbox was not checked), the required expression turning faults would not cancel a wait. I have several rules that have waits built in, but will no longer recognize the wait event if the required expression becomes false. Is this normal behavior?
Usually when this happens, the log will show/recognize that the wait event has been satisfied but will not advance the rule any further. It just stops. Even those wait events that have a timeout on them stop and don't advance any further.
It should work as you describe. A required expression becoming false does not do anything on its own except prevent trigger events from triggering the rule, unless you have the "Cancel pending actions when required expression becomes false" option selected, in which case it will do that.
If you are seeing other behavior, I'd suggest sharing what the Logs for the rule (which it sounds like you have enabled--but do that if you don't) say.
It always stops at the same place, on the wait for event, downstairs door closed. My first rule was hanging there and I tried everything I could think of (update rule, hitting done, editing, etc ). I finally deleted that rule and rebuilt it from scratch with a different required expression. This is the new rule and it does the same thing. It's waiting for the door to close and sees the door close, but doesn't advance. Tonight, I opened and closed the door three times trying to get it to advance the wait. It logged it three times but never moved forward. I just don't understand how it can wait for an event, see the event, and not logically pass it.
Any one see any reason this rule is stopping? I'm completely stuck and can't get this to work. I e rebuilt it three times with slightly different variations, re-initialized it, and rebooted the hub. The long wait seems to just fizzle out and I can't figure out why (other than the required expression turning false). I need the required expression though so that it only triggers under certain circumstances and doesn't cancel the waits.
This is true even though the required expression became false during the wait.
I'm not sure there's a complete picture of your rule anywhere above, but I might look for any "Waits" that might conflict with your trigger (are any looking for the exact same event?). If all looks good, I might suggest just re-creating the rule in case something just got corrupted in your existing rule. Otherwise, sharing a complete picture of your rule setup might help someone catch something that isn't apparent from the above. Also, starting simple and adding more complexity as you verify that each part works, or just splitting a single complicated rule into multiple simpler rules, should also make things easier to troubleshoot.
I 'think' the trigger and waits should not conflict, but I'm totally open to suggestions if there's something looping. Here's the complete rule (screenshot 1). I've rebuilt it four different times and deleted the old. This one has a cancel actions and a few delays that the others didn't have just because I was trying to vary it. I figured if the old didn't work, it couldn't hurt to give it some time between steps. Shouldn't matter, but it wasn't working the other way...
Is it possible that the hubs just wear out or something? Several rules seem to just stop working or don't complete. Others work most of the time, but then don't finish. My room lighting rules work about 95% of the time, but then you'll walk in one of the rooms and the motion will turn to active, but the light won't come on. In the logs, it will show it ran correctly and turned the light on and off. Last night, I ran an action to resume the paused rules (five rules) and it unpaused one of the five (see screenshot 2). Most of these rules were working 100% of the time a few months ago so the unreliability is confusing to me and seems to be getting worse.
The obvious answer would be that I've added a device or rule that is conflicting. But the part that I can't figure out is that, I've had this setup running for about six months with pretty much no change. It seems to be progressively getting worse as time goes on and becoming less reliable. I figured it'd be something I was always tinkering with, but once I got it setup and tuned in, I've mostly left it alone. So the fact that it's starting to "fail" (seemingly) is strange to me.
I suppose there is eMMC storage or something in the hub that could eventually "wear out," but this seems like a less likely cause to me. If database corruption is the cause, you could try making and downloading a current backup, then restoring it to your hub (a cleanup will happen as part of making the backup). I'm not sure if I've seen any cases recently where that helped, but it can't hurt, as long as you don't reset your radios (you'll see some older advice to do a soft reset on the hub before the restore, which can't hurt, but it's not necessary anymore since restoring a backup now effectively does that first).
The issues with the lights seem more like a network issue than an app issue, given that even the app logs suggest it's doing what it says. I'd look into network-specific (Zigbee vs. Z-Wave, etc.) troubleshooting for this, but that depends on the specific devices.
As for your actual rule, I don't see anything there that looks problematic off hand, but the actions are also pretty complicated. I'd revisit this possibility:
I'll look at building the smaller/simpler parts of the rule and see how that goes. I thought about breaking it up into two, but that seemed counterproductive when it's all in one. The whole idea was that it retriggers under certain circumstances and cancels all the waits to re-run the rule, but not under other conditions.
My thought with the hub wearing out was the pausing issue. It makes sense that devices don't always receive an action. But failing to un-pause a rule seems like an internal issue. Or in my case, a command with five rules to resume only completing one of the resume commands seems like the hub might be going bad (or something). The log says it un-paused all five, but only one was completed. Is that even possible?
I'll try the backup and restore to see if that cleans up whatever could be going wrong. I'll have to work up my courage to do it. I have a lot of devices and rules so if I'm wrong, it will be a lot to rebuild. Thanks for helping me resolve it! I'll see how this goes.
As Robert noted this sounds more like a communication/network issue. What kind of devices do you have? If you have Z-Wave devices, post a screen shot(s) of your Z-Wave details.
I have pretty much all zigbee devices. There is a zwave lock, two outdoor plugs (that are only used in December for Christmas lights), and two dry contact relays. All the light switches and dimmers are lutron. The rest (motion, humidity, door contacts) are all zigbee.
Would the network prevent resuming a rule? I don't mean to keep asking...I just want to understand so I can understand the solution fix. I was thinking that was an internal process that was not radio related. The lighting portion makes sense. I've posted the zwave page below.
The device page shows 151 devices. I have 64 lutron devices, six ecobee, about 17 virtual switches/devices, and pretty much the rest are a mix of zigbee devices. I had considered getting a second hub to lighten the load on one unit. I'm not sure if that would help in this situation.
Your setup more or less mirrors my own. This number of devices should not be an issue for the hub.
A few points:
Any events that are logged should happen, if they don't there's a communication error. Not a rule error
As part of your error tracking process you should run tests controlling devices directly on the 'Device' page.
Depending on your layout you may need a repeater for your Lutron devices. Lutron's guidelines are devices should be within a 30 ft. radius of the bridge/repeater. Based on your '95% of the time the rules work' statement this would be my guess as to the cause of your issues.
There are Z-Wave issues, but not likely the cause of your broader problems. #17 & 18 look to be ghosts. They need to be removed as they will cause your Z-Wave devices to not perform well. You should exclude Z-Wave plugs if you are going to unplug them, for the same reasons. Some people get away with just unplugging, but excluding is "best practice"
