The following is probably no surprise to all the experienced folk out there but I thought I'd throw it to the board to see if it sticks... and if so, help someone less experienced in the future.
I have a rule which on a high temperature trigger turns on a Sylvania Smart+ Outlet IF it is found to be off,
then immediately goes into a Wait for Expression which waits for a low temperature OR the outlet being turned off (manually) before the rule proceeds and wrap things up as desired.
Here is the log entry of that WAIT line in action:
Action: Wait for Expression: Temperature of Motion - mBR (80.41) is < 72.0(F)
OR
Outlet - mBR(on) is off(F) [FALSE]
Now an interesting thing happened when I first tested this...I found this Wait expression tested that Outlet state BEFORE the thing was showing ON after the rule had JUST commanded it to turn on in the line prior. Of course that caused the Wait to end and the rule to proceed.
So I put in a 1 minute delay AFTER turning the Outlet ON before moving on to that Wait...and all functioned as I intended/expected (I think, gimme another 24 hours).
So I'll go ahead and ask the obvious - have other folks noticed the need for Delays to SLOW DOWN THE PROCESSING in order to give devices time to take a command and reflect that state in HE ?
As you suspected someone like me might say, this isn't too surprising. 
But it's not necessarily "processing delay" on Hubitat. Here's where I think what you describe is happening in this chain of events:
- The hub tells the Zigbee outlet to turn on
- The outlet turns on
- The outlet sends a message back to the hub that it is turned on
- The hub processes that message into an event (switch: on) for the outlet
If your rule is telling the outlet to turn on (#1 above) and the immediately testing the state, the next action is probably running between items 1 and 2 above. Maybe 3. Either way, it has to get all the way to 4 before the condition you're testing in your wait will evaluate to false. How long this takes will depend mostly on the device and state of your Zigbee mesh, but even on fast devices this will probably take at least a couple hundred milliseconds. Adding a minute of delay on the app (rule) side should be safe, though even a couple seconds should be more than enough if your device and mesh are good. I strongly suspect that the space between #3 and #4 isn't of concern here, though that also takes some milliseconds.
I do see some people surprised by items 2 through 4 above. The "switch" state will not immediately change to "on" on Hubitat just because you sent an on() command, at least not with most devices (Zigbee, Z-Wave, most non-polling LAN devices, etc.). This ensures that the state you see on Hubitat actually matches what the device is doing. So, if it in fact does not turn on (because it's unplugged, unresponsive, has a dead battery [if it were a different kind of device], etc.), this ensures that the Hubitat state is more likely to be accurate, and it can also help you identify if there is a problem somewhere.
2 Likes
Glad to know I wasn't dreaming this up. Nice outline of the steps. Thanks.
Figured 1 minute was way more than necessary but it was no detriment to wait that long in this case.
(I hesitate to mention that I STILL don't know for sure when it's best to use Wait for Expression vs Wait for Event but let's save that for that other thread where it was being discussed.)
