There is a new action available in the 2.1.0 release of Rule Machine: Wait for Event. What this action allows is the selection of an event to pause action execution, waiting for that event to occur. When the event occurs, execution of the actions resumes. A pending Wait for Event is automatically cancelled upon rule truth change, being triggered or being stopped.
The available choices for the event include most of those available for a Trigger Event. Not allowed are Periodic, rule related events (Rule Truth, Private Boolean, Rule Paused, Other Triggers), Lock/Keypad Codes, Button LED, and Cloud/Local Endpoint. For sensor device events comparison to values, other devices and variables is supported, just as with a Trigger Event.
Warning: Care should be taken if the devices or variables used in Wait for Event are also used in Conditions or Trigger Events. It would be possible for both the Wait for Event to resume execution of the actions and for the rule to be fired by the same event at roughly the same time. This might or might not be a problem depending on the circumstances.
The example below shows how Wait for Event can be used to allow arming/disarming of HSM to control the setting of modes.
Not sure if this is the right place to post this, but...
I have a wait for the thermostat coolSetpoint to reach %CoolSetpoint% which is 81. It never executes the instruction after the wait.
The error log shows:
Waiting for Cool setpoint of Thermostat(81) becomes CoolSetpoint(81)
and it never executes the next instruction (which is a wait for the HeatSetpoint.
It is very likely that the setpoint is already at 81 when the wait is executed. Is there a transition needed for the wait to notice?
Thanks
Ah, waiting for Godot. Wait for Event does just that. It doesn't test a condition, it waits for the event described. In this case, that would be for the setpoint to become 81.
If I'm understanding this correctly, no. If the setpoint is already 81 it would have to become something else (80) and then come back to 81 to satisfy the wait and continue.
Some might see this as counter intuitive. So, you are saying that the wait is only safe if it is part of a simple if statement checking to see if the value is already what you want it to be???
Not meaning to be picky but,,,
Are you intending to put this fact in the documentation in VERY LARGE LETTERS?
No, that's not true. Obviously, it is possible to wait for something that may never happen. That would be true of a trigger also, or of conditions in a rule. It's just up to you to be thoughtful about the design of your rules. There are an infinite number of rules that won't work. Not something worth PUTTING IN LARGE LETTERS.
Hubitat is an event driven system. Wait for Event makes sense if the event you are waiting for is likely to happen in the natural course of events. If it is not likely to happen, why would you wait for it?
I must not be explaining this very well, sorry.
Actually, I'm saying the opposite. If you're waiting for something to become true and it is already true, I would expect to not wait at all instead of waiting for it to become false and then back to true.
I. E. if what you're waiting for has already happened, why wait at all??
It isn't waiting for something to become true. It's waiting for an event. The event it's waiting for, the fact that it's waiting for it, has nothing to do with the state of anything. You're over thinking it. All it does is wait for something you tell it to wait for. It doesn't test anything, or check it for true or false. You can do that yourself with Conditional Actions, if that is a consideration.
In your case, you're not really wanting to wait for an event. You're talking about waiting for some condition to be true. Perhaps there could be a different action called Wait for Condition. But, in the meantime, there are plenty of ways to accomplish what you're trying to do.
Don't confuse Wait for Event for something it isn't, such as Wait for Condition. There is a subtle but super important difference between events and conditions. Events are simply things that happen. Conditions are the states of things. Now, the state of something comes about by events changing its state, so it's easy to conflate events and conditions. But they aren't the same thing.
I'm loving wait for event. I've already found several places to use it. makes my rule logic much more straight forward. I think "wait for condition" would be another great addition!
It's coming... Subtle differences between Wait for Event and Wait for Condition. The latter tests the truth of the condition, and if it's true does not wait. If it's false, it waits for it to become true.
I came here looking for a "wait for event/etc" + timeout.
Example:
Close dryer door. Wait 5 minutes.
Wait for event: dryer vibration. Timeout 5 minutes.
FALSE: Cancel all rule actions.
TRUE: Wait for event: No dryer vibration for 5 minutes. No timeout.
-- Somehow come up with logic to determine no-vibration for some time.
-- Notify driver complete.
So I guess as above, "wait for condition" would be really slick, but I think even better would be if part of the condition could be "true/false for x timeframe," before reporting true. I know I can do this with a bunch of rules that control each other with booleans, but it's far less than ideal. I love wrapping things up into fewer rules. I'm a huge fan of the real if,then,else functions, but it can be a pain to trick the UI into allowing things to nest, and there's no and/or operators that I can find. If I could just write out the custom logic, I'd be a happy clam.
I'd love the same logic for my door-knock as well. Maybe do some conditional on the acceleration strength of my contact sensor. I hate that car exhaust can trigger it.
These conditional actions are new. If you need logical operators you do that in a Rule. In effect, a Rule gives you a top level IF - ELSE. You can nest Simple Conditional Actions inside an IF-THEN block in Actions.
Still trying to figure out how to use the Wait for Event. I'm having trouble with the 'IF (Cool setpoint of Thermostat' statement near the end. Here's the code:
Notice how even though the condition of the if then is false and it says it is skipping the then statement, it executes the then statement (the wait) anyway.
What am I missing here??
@bravenel is it possible to nest simple conditionals under full if-then-else? I swear I have that working sometimes, but nothing in this rule fires off at all.
