@bravenel I was testing some behavior of wait and timeout and found that the behavior of Rule-5.1 does not seem to match the documentation (and other references in the forums).
The references I found all seem to indicated that after a timeout, the built-in variable '%device%' will be set to the string "timeout", but it seems that my testing with 2.3.3.123 indicates that the %device% variable is not set, but rather the %value% variable is set.
Is this a bug in the implementation or in the documentation?
%device%: name of the device that generated the event (or "timeout" after a "Wait..." action if a timeout is specified on a wait and the next action is reached because the timeout expires)
Evidence / Screen Shots
Note: Tested by clicking "Run Actions" in case that is relevant...
Ah, except that isn't fair. It just changed. I think it probably had been %device%. That change wasn't well considered. I think perhaps it should go back to the way it was.
I had the rule working until my ZWave Sensative strip's battery died. Now I am trying to pick the illumiance attribue from my Tempest. No joy on that yet....
Run the actions of the rule manually, then take a screenshot of the Event Subscriptions from the App Status page to post here (gear icon). Let's see what it's looking for.
Separately from that, I'd suggest to get away from using a Connector at all, as it just introduces more complexity and an extra device. A Hub Variable can be used directly, and passed via Hub Mesh if needed.
OK, I just tried switching from Connector device to Connector variable. Same result. Not sure I caught your point completly as the creation of both start with a Global hub variable. Both are listed under Variable Connectors in both hubs when meshed.
Your logs show no evidence of any event for that. Do you have all logging turned on? You can look at the device events using the Events button on the device page to see if there were any events between 7:30 and 7:45.
I am seeing the issue now. My Zwave device produced more illuminace events then the Tempest does plus I usually have the timeout at 30 mins. I reduced it to troubleshoot AND natural light was low between 7:30 and 7:45 ( altough I started looking at this earlier than that after none of my Sunset rules triggered for some reason). P.S There are many events in the interval of Sunset and 40 mins post normally for this device connector.
This Wait condition is a bit counter intuitive to my thinking as the Wait condition has been met based on the evaluation of the conditional expression using the current values of the variables in the expression. Why do we need to wait on a change of state?
Thanks for putting me on the path of explanation. I will monitor my Sunset events more closely in the next few days.
Rule Machine has two types of waits, "Wait for Expression" and "Wait for Event." If you want to match a current state, you want "Wait for Expression" (where the "expression" means one condition or any combination of them). "Wait for Event" does not care about current states; it will only wait for a future event that matches what you've selected. "Wait for Expression" will effectively wait for such an event too if the expression is false when reached. Sounds like this is what you're asking about?
Just created a new rule on the latest build 2.3.5.101 and after a wait for event elapsed time, timed out, %device% is equal to "elapsed time" not "timeout". I guess that is expected? If it is an event from a device I assume it will still be "timeout". I will have to go look at my rules, but I thought it had always been "timeout"?