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

@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.

@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 Present

Actions:
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 lights

What 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 lights

The 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 lights

The 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.

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.

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.

I have an older Vera Plus controller that has been collecting dust for a little while. I know the hardware is no longer supported but I would prefer it to go to a good home vs the eWaste center. No charge, just pay for shipping and it's yours. If you are interested, let me know.

I love it when solutions come to you in your dreams. It dawned on me that my Hub Security on the hub was reset but I still had it enabled on MSR. As soon as I enabled it on my hub and restarted MSR, and literally had a kid walk through the entire house, every motion sensor was tripping back and forth from inactive to active back to inactive.

Running MSR latest-23344-ca53d088 within a Docker.

My Hubitat (HE) hub suffered almost a 4 day outage from a corrupt backup that failed to restore. During this time I had my MSR docker stopped. Well, I didn't stop it until the the hub had been down for 24 hours. Anyway, I finally got the hub back online this morning and am fixing my MSR rules for everything that was lost. Support needed to purge out the Apps section of the backup.

So my issue. So far everything I have fixed is working as expected, with the exception of my motion controllers. I can see them go "Active" within my HE, but the Entity within MSR never changes from false to true. I ran through a slew of rooms that have motion sensors and only 1 out of 6 changed to true.

I removed the sensor I'm testing with from Maker API, restarted MSR, re-added it, restarted MSR, but no difference. I then Deleted it from MSR and restarted MSR. It was re-added, but again no change. How can I go about testing this further to find out why/what is going on?

Hmm.. OK. I was re-reading the HubitatController section of the docs and realized that I removed my Hub Information device a couple of months back. Perhaps that was part of the issue? I put it back and then upgraded to 2.3.7.140. So far so good. Hopefully it was the missing Hub Information device, or perhaps my HE was just having an off day? I'll monitor things and report back if there is any issues. Thanks all.

Same here. Docker image latest-23344-ca53d088. And I am aware that he would need more details. I'm not reporting this has a bug since he hasn't blessed 2.3.7 yet. I actually upgraded earlier in the day and some rules were triggering just fine. It wasn't until the evening when a lot of my logic was SUPER slow, delayed, or not working at all. Which would make sense if MSR couldn't chat with the hub.
I don't subscribe to the remote backups, so I don't think that bug will effect me. But good to know, thanks.

If you are thinking about upgrading your Hubitat Elevation hub from 2.3.6 to 2.3.7, and you are using MSR.... wait! I was trying to resolve a different issue with the HE and didn't even think twice about how MSR would react. Well... MSR was not happy and was complaining that the events feed had become unresponsive. And my automations were not working either. I have since reverted back to 2.3.6 and will happily wait for @toggledbits to do his magic.

Hi @toggledbits,

I had an idea about my Echo speaking which windows or doors are open when an announcement is made reminding the family to close things up when it is hotter outside. Let me start off by saying I'm not great with expressions and in no way any programmer. To get started I read the How To: Expressions and what do you know, you have an example on how to do exactly what I am looking for. However I think I found a typo/correction that may be needed? Again, not a programmer here.

In the How To: Expressions with Entities section you state the new expression called open_perimeter_doors and give the example with the end of null : doorid. In the description you state you order them this way because when the door_sensor.state is true, the door is closed/secure. I have a few different brands of contact sensors and all of them are just the opposite. They are true when they are open and false when they are closed. For me, this was an easy fix. I swapped them.

What blew my mind and took a bit of thinking was a little further down in your example of joining the getEntity ID and getName.

join( each doorid in perimeter_doors: do
           e = getEntity( doorid ),
           e.attributes.door_sensor.state ? null : e.getName()
       done
    , ", " )

The "e.getName()" in the example would cause the expression to never evaluate. I needed to change this to "e.name". With e already being set as "getEntity( doorid )", only name was needing to be appended. In your example you are appending ".getName()", resulting in "getEntity( doorid).getName()"

Again, NOT a programmer, but perhaps a stale How To example from before a major update to the expression logic? Just wanted to share my results in case the manual does need an update.

I'm not in need of it. As I was moving off Lighting Director I just happened to notice they had a max number of lights. I think the OG DeusExMachina did too. I think how you have it would be more lifelike. Especially when you couple of a few specific OFF rules so the lights turn off faster than 10-20 minutes.

MSR: latest-23078-d592d400
--Docker image on unRAID
Hubitat C-7: 2.3.5.121

I'm always looking to simplify my rules and reactions and having finally grasped the Array function with a loop of perform.Action, I decided to re-write one of my rules. The kids like to play music on the Echo devices at a high volume, and I also have TTS loud during the night if a door/window are to open. In order to not have her yell at me later, I wrote a rule that resets the volume on each Echo device to a level of 2. However having 7 Echo's, there are many steps in my Reaction. Set the volume on device 1, wait a few seconds, set the volume on the device 2, wait, and so on.

Sample snippet of the set reaction: (This works BTW.)

To make it better, I created an array of the devices and want to run a perform.Action command. Less steps with the same results. Or so I thought. The end result is now a volume level of 0 or 1. I think the Echo gets confused. Either way, not a level of 2 like I was expecting. BTW volume 1 across the room is too low, in case you were wondering.

New set reaction:

${{ each device in Echo_devices: performAction( device, 'volume.set', { level:0.20 } ); 0 }}

The av_transport.stop works as expected. The issue is with the volume.set, {level:0.20}. Do I have something wrong in my command?

Global expressions used:

@kellyjelly32 Is there a way to specify how many lights should be on at one time? I tested REM last night and the most on at the same time appeared to be two. I'm fine with this, but curious if there was an option or way to adjust it. Again, thanks for sharing your logic.

Ahh... I miss that app. Probably one of my favorites from my Vera days. The "Lighting Director" app on Hubitat just isn't the same.

Thanks for posting your setup @kellyjelly32. I've mocked this into my MSR and if all works well, DeusExMachina returns. Well kinda

@toggledbits Awesome. Thank you.

I know you know, but for others, the rule ID is also noted in the logs. Makes it easier to copy and paste without having to look up the ID within the GUI.

Thank you. I changed all my rules that had a presence sensor written in them. As well as a few other rules that have an app that phones home every minute. Just restarted MSR for good measure and can see a different. I'm over 30 minutes right now between .log and .log.1.

If I am understanding your global expressions correctly. Are you saying you moved your rule triggers to an expression and then changed the trigger to be the value of the expression?

Original rule checking presence:

Now as a global expression:

With an updated trigger:

When Life360 updates, won't it force the expression to revalidate its value? Are these not logged?

It does appear to mostly be related to rules that have to do with my Life360 presence sensors.

Correction to my log level comment above. Changing the rules and engine to 4 did slow things down a bit. I saved that changed and restarted my docker at 7:43 AM. I'm just shy of 2 hours now to fill/rotate all 9 logs.