Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
-
I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.
For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.
@3rdStng said in Feature Request - Wait for an event/trigger within Reaction:
I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on.
A Repeat...While group will execute and prevent the remainder of the Reaction from running until it breaks (conditions are no longer met).
The delay prevents it from becoming a huge CPU consumer.
Yes, this is a bit of a kludge, and a dedicated action could be more useful. I'll look into it, but in the meanwhile, this workaround should play nicely.
-
Hmm.... Thanks for this, I think I can make it work, but it may take two Repeat While actions. It doesn't appear that I can wait for a change. It's only waiting for a True or False and not a change from Opened to Closed.
I believe in my rule I would need a "Repeat While the door is false" (open) to wait for someone to actually open the door. Then a "Repeat While the door is true" (closed) to wait for them to close the door and then continuing on the actions to turn off the lights.
-
Well, really if it's just as simple as turning on the lights when the door opens, and then waiting for a close to turn them off, the rule trigger conditions should handle detecting the door opening, and the first action in the Set reaction would be to turn the lights on. Then you can wait for the door to close, and turn the lights off.
But then, if the rule triggers are only detecting if the door is open, why not have the Set reaction turn the lights on, and the Reset reaction turn the lights off? No "wait for" needed at all, because the logic is handling it.
As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Well, really if it's just as simple as turning on the lights when the door opens, and then waiting for a close to turn them off, the rule trigger conditions should handle detecting the door opening, and the first action in the Set reaction would be to turn the lights on. Then you can wait for the door to close, and turn the lights off.
But then, if the rule triggers are only detecting if the door is open, why not have the Set reaction turn the lights on, and the Reset reaction turn the lights off? No "wait for" needed at all, because the logic is handling it.
As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."
@toggledbits said in Feature Request - Wait for an event/trigger within Reaction:
As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."
That is very possible. I'm still mentally mapping this out too. And I 100% know that an image of my rule set would really help clear things up. I'm not in a position to get a screenshot at the moment. I'll try to put my thoughts in to text. (scary)
Rule set as of today:
Triggers:
After midnight AND
Before sunrise AND
Any Presence Sensor in the group changes from Not Present to PresentActions:
Turn on the porch light
Turn on the driveway lights
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lightsWhat I am after is within the Actions only. The Triggers are still the same.
Actions:
Turn on the porch light
Turn on the driveway lights
Wait until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lightsThe waiting until the hub variable is what's potentially causing the issue. When I go to bed, and assuming the door was open, I'll close it and lock it. So the hub variable now reports "Manually locked". If someone arrives after midnight and before sunrise, the variable will still report "Manually locked" since the lock status hasn't changed yet. So theoretically MSR won't wait since it already sees the variable as what it is looking for.
And as I type this out, I suppose I could insert a set variable into the actions. I honestly haven't looked yet, but can MSR set a variable that is local to the hub only? Not within MSR.
Actions:
Turn on the porch light
Turn on the driveway lights
Set HE Hub variable "lastDoorLockEvent" to "waiting entry"
Repeat Until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lightsThe entire concept stems from Hubitat's Rule Machine's "Wait for event" that you can define in a rule. I have a couple of these at my remote HE, where I can't run MSR easily.
-
OK. This makes it much more clear. Your solution is workable. There are a few ways to attack it, but what you've posted should work. You picked up on the state of the hub variable, which is important. You hub variable should appear as an entity with the
string_sensorcapability, and it should have an extended action (x_hubitat_Variable.setVariable) to let you change the value. -
OK. This makes it much more clear. Your solution is workable. There are a few ways to attack it, but what you've posted should work. You picked up on the state of the hub variable, which is important. You hub variable should appear as an entity with the
string_sensorcapability, and it should have an extended action (x_hubitat_Variable.setVariable) to let you change the value.@toggledbits said in Feature Request - Wait for an event/trigger within Reaction:
hub variable should appear as an entity with the string_sensor capability, and it should have an extended action (x_hubitat_Variable.setVariable) to let you change the value.
Worked perfectly!
Thank you for the feedback and allowing me to type out my thoughts to refine this rule.
-
Well, really if it's just as simple as turning on the lights when the door opens, and then waiting for a close to turn them off, the rule trigger conditions should handle detecting the door opening, and the first action in the Set reaction would be to turn the lights on. Then you can wait for the door to close, and turn the lights off.
But then, if the rule triggers are only detecting if the door is open, why not have the Set reaction turn the lights on, and the Reset reaction turn the lights off? No "wait for" needed at all, because the logic is handling it.
As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."
@toggledbits One case I can think of where this is useful is as follows. Note I try to avoid making multiple rules to achieve this since it make managing them much harder.
I have some triggers (not relevant in this example) for my front doorbell when a person, vehicle, animal or package is detected. Each of these have their own respective rule. In the actions I have TTS action that says "{object name} detected at the front door". I also have another action after that send a notification to my phone with a snapshot and description of the doorbell activity.
The problem I run into, is that on occasion the snapshot takes a few extra seconds to come through. Now in my case I want the TTS to say what's at the door right away regardless of the snapshot since its irrelevant and then wait till the snapshot updates to send the push notification.
To combat the delay I added a condition in my triggers that wait for the snapshot time to update before sending the TTS and notification. Using this workaround it introduces a delay in the TTS action as well. Ideally having a "wait for" action for when the snapshot updates to then send the notification will fix the problem without needing to create another rule.
-
Refined my actions to include a timeout, just in case someone comes home, but they leave without entering the door.
Actions:
Set variable 'lastLockEvent' to "pending entry"
Turn on porch light
Turn on driveway lights
Repeat While:
-- Triggers:
-- [lastLockEvent] contains "manually locked"
-- [OR]
-- [lastLockEvent] contains "pending entry" (condition sustained for 20 minutes)
-- Actions:
-- Delay 10 seconds
Delay random between 1 to 5 minutes
Turn off porch light
Turn off driveway lights -
@3rdStng said in Feature Request - Wait for an event/trigger within Reaction:
I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on.
A Repeat...While group will execute and prevent the remainder of the Reaction from running until it breaks (conditions are no longer met).
The delay prevents it from becoming a huge CPU consumer.
Yes, this is a bit of a kludge, and a dedicated action could be more useful. I'll look into it, but in the meanwhile, this workaround should play nicely.
@toggledbits just an idea related to this "repeat...while" group that it could benefit from similar functionality as is available for pulse to prevent it from looping indefinitely. There are sometimes devices not updating their status properly and in those cases it would be nice to ensure exit within reasonable time.
This functionality can be done in a following way, for example, but would be more straightforward if it was already built-in
-
T toggledbits locked this topic on
