RM Variables and wait timeouts

@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? :slight_smile:

References:

2.3.2.139 Release Notes:

  • Fixed timeout in %device%"

Rule 5.1 Documentation (See: Local Variables)

  • %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...

Test Rule (new):

Logs of running actions (no event):

Rule Page after Actions Run (no event):

Documentation.

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.

3 Likes

Yes that will cause several of my rules to stop working.

Next release it will go back. @tony.fleisher

4 Likes

I suppose it could set both if the intent is to move to %value% in the future... just a thought. :slight_smile:

Thanks for the quick response on this @bravenel .

Confirmed fixed in newer release.

2 Likes

I would appreciate any insights on why this rule is timing out?
The rule is:


The log is:

The variable declaration is a Connector:

That is meshed to another hub that has a Global variable defined:

and the variable is loaded from a device attribute:

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.
Here is the whole App Status log (btw: running 2.3.3.140):

Sorry missed the request for Event Subscriptions only , here it is:

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.

That's not what I meant. I meant to not use any Connector at all, only a Hub Variable.

Were there any events in the 15 minute window for the illuminance device? The Event Subscription looked right

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.

Upon examination of the larger App Status this is the excerpt from it:


Ignore my orginal post above.

From device Event log on C5 hub (the one runing the Rule in question):

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.

You have wait for event, not wait for expression (condition).

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?

1 Like

Got it. Thanks much!

1 Like

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"?