So, i've just switched over from ST, so far very happy with the switch.
I had an automation that i ran in Webcore for ST that worked "most" of the time, and i would like to put it in here and possibly perfect it.
So the goal is to set HSM to armed when the following conditions are met:
No motion for 20 min on 3 motion sensors
1 light switch (specific light) has been off for 20 min
The current HSM status is disarmed
Time is between midnight and 31 min before sunrise
So i'm ok to add all the conditions except for the 20 min conditions
For instance, let's say there's no motion for 15 min and all of us a sudden there is, i want it to restart the timer. So 20 min of no motion will TRUE that specific condition.
HSM status is Disarmed TRUE
Time between 12:00 AM EDT and Sunrise-31 minutes FALSE
Garage Light(on) is off FALSE
Dining Room Motion, Kitchen Motion, Living Room Motion all inactive TRUE
ZMC, suggested above, would make some of this easier. Otherwise, you could take advantage of the fact that a "Wait" in a rule gets cancelled by any trigger event (by which I mean that gets cancelled and nothing after it runs), so something like this may do what you want:
Trigger Events:Dining Room Motion active OR Kitchen Motion active OR Living room motion active OR Garage Light on
Actions to Run:
Wait for conditions: Dining Room Motion inactive AND Kitchen Motion inactive AND Living Room Motion inactive AND Garage Light off
Wait for event: elapsed time --> 0:20:00
IF (HSM Status is Disarmed AND Time is Between Midnight and Sunrise-31) THEN
Arm HSM
END-IF
You can create the conditions ahead of time if you want (what you copied and pasted at the bottom of your second post). However, it's important to note that they don't do anything on their own unless you actually use them in the rule, as I did; that's just a "bank" you can pull from later if you want, which may or may not be easier than creating them on the fly (in which case they will also get added there).
This requires Rule-4.1, new in Hubitat 2.2.5, so you'll need to upgrade if you're on older firmware or find another way to do this. (If you're on 2.2.5 or newer, this is the version of Rule you'll get when creating new, so no need to worry.)
If all the motions are inactive for 10 min and then suddenly a motion is active, since it's in the trigger event it'll restart the trigger for the rule and once it goes back to inactive it'll restart the timer?
Is there any disadvantage to having the triggers fire off so often? Because I only want it to trigger anytime between midnight and sunrise.
So for 24h every time there's motion or garage light is changed, it'll check to fire off the rule. If there's no drawback to firing it that often than i think that'll work perfectly.
Those will match trigger events and your wait will be canceled. The timer will start again after everything become inactive (and the switch is off). So I think the answer you're looking for is "yes," but I didn't want to get hung up terminology.
To be clear, you only want it to do anything if the time is between midnight and sunrise. Just because the rule triggers doesn't mean all the actions will run. The above will do that. In general, the fewer apps you have subscribed to a given device's events, the better, but I can't imagine anything like the above being a problem on normal hubs.
They being said, there is another approach you could take depending on what you actually want to do: trigger at midnight, wait for all the sensors to become inactive and the switch to be off (conditions), then arm HSM if it's not. You'd have to work the "sunrise" thing into there somehow (or settle for a timeout, the easiest thing I can think of off the top of my head), and it has the possible disadvantage that it will only "work" once per day (i.e., will not re-arm should you disarm for some reason on the middle of the night after things quiet down again). But again, I wouldn't really be worried about the original suggestion.
Just because the rule triggers doesn't mean all the actions will run. The above will do that. In general, the fewer apps you have subscribed to a given device's events, the better, but I can't imagine anything like the above being a problem on normal hubs.
