awesome, using a global var as a work around.
Thanks!
I really tried, gave it 40 minutes and had the old rule up on a different screen and the one @bravenel helped me with before - but I cant get it.
When I do triggers it says certain time, but I want it between times - because i have a presence rule to turn everything off if no ones home. So if I set certain time, and the rule no ones home kicks in, the certain time rule wont work. How do i do this ?
I'm still trying to figure out timing on RM4. I keep having weird things happen and when I look at events there is too much time between events. For example.
System Events shows my mode set to Home at 6:05.13.
RM4 rule that watches for mode change gets triggered at 6:05.21, 8 seconds later.
This rule sets HSM to disarm which occured at 6:05.27, another 6 seconds.
HSM was then disarmed at 6:05.29, 2 seconds after being told to disarm.
Another example. I had a simple RM rule that when a particular door opened, turn on a light. The delay before the light came on was always 4 to 5 seconds. I changed this to a Simple Lighting and now there is almost no delay.
To me this says there is something in RM that is slow...
You could try the following. It's a little outside of what you might be thinking and it shows off another command (wait) which is really cool.
Trigger
At certain time 5:30 PM
Action
Turn on TP plug
Wiat for Event: When time is 8:30 PM
Turn off TP plug
1 Like
This is one of many attempts at this simple automation for turning a fan off after no motion. I'm not getting RM4 at all and need a bit of help. This is using one of the latest Smartthings motion detectors that only remains active for aprox 15 seconds. The goal is to have the fan continue running until a given period of time once motion becomes inactive. 
I've got a similar setup for controlling lights that does work but I still have no clue what this is doing with Cancel Delayed Actions and the (cancel) after those 5 minute delays.
And then this works just fine with WC.
You should simply trigger this automation off the motion.
Trigger Event: Kitchen Motion *changed*
Actions
IF (motion inactive) THEN
Off: Kitchen Fan Delay 3:00 Cancel
ELSE
Cancel Delay
END-IF
1 Like
You kind of answered your own question on why it doesn't work.... The "trigger" is 'when should I do something'. You have 'when the fan is on'. That will trigger exactly once - when you turn on the fan, and never again.
Trigger = WHEN
Action = WHAT
So when I think of rules in English I break it down like:
- WHAT do I want to happen? That's the action.
- in your case, it is turn off the fan if motion is inactive
- WHEN do I want it to happen? That's the trigger.
- in this case it is, when Kitchen motion changes to inactive
2 Likes
If "motion changed" is the trigger and this is a high traffic area this rule will be firing constantly.
If the goal is to only have the rule paying attention if the fan is turned on, I'm not understanding why a trigger of Fan turns on is not the most efficient way to do this.
I could not get "Fan turns on" to behave properly even in WC so I went with Fan is on. That works and when I look at that piston's activity I don't see it using any resources unless the fan is on and it will be off in a reasonable amount of time if I set the wait time to 10 minutes.
I like the notion of a straightforward trigger as Motion Changed is but it seems like "Switch Turns On" is equally as concise. And, "Switch Turns On" is not going to happen nearly as often as "motion changing" is. What am I missing?
and what is the Cancel doing in relationship to the Cancel Delay that follows the Else?
But that is the point.... If you use 'fan turns on' as the trigger, the code runs exactly one time, then never again until you turn the fan off and on again.
The rule doesn't run periodically, or when the motion sensor changes, the way you wrote your rule. The code will ONLY run when the fan changes from off to on, per the trigger you defined.
So in your case, if motion happens to be active when you turn on the fan, the code will run - see motion is active - and do nothing. And will not run again until the fan is turned off and back on again, tripping the trigger.
Plus, who cares if it runs over and over? It isn't going to run so much that you have hub performance issues.
Probably not all that frequently. Most motion sensors will not report 'inactive' until at least ~30 seconds of zero activity has elapsed.
The fan turns 'on' only once, not continuously. Thus, RM would not know to wake up and check the status of the motion detector.
The Cancel is cancelling the timer that was started in the 'True" portion of the preceding IF statement. So, if motion goes Active while we're waiting for the 3:00 minute delay, we want to cancel that timer and keep the fan on.
1 Like
The only way you could get it not to run every time motion is inactive would be to use a Wait. But, it's going to have to Wait over and over, because one time isn't going to cut it, since you want the fan to turn off after 3:00 minutes of no motion. Doing it over and over would introduce some variability into the 3:00 minutes. This example below would repeat every 15 seconds while the fan is on, but not run otherwise.
Trigger Event: Fan on
Actions:
If (Fan on) Repeat 0:00:15
Wait for Motion *changed*
IF (Motion inactive) THEN
Off Fan Delay 3:00 Cancel
ELSE
Cancel Delay
END-IF
END-REP
UPDATE: Actually, this rule could be prone to fail completely. The only way to guarantee that it's not going to miss a Motion Inactive event is for that to be a trigger event, so back to the rule I first posted above. It is normal for rules driven by motion to be firing all of the time, and this generally does not affect hub performance at all. These events are separated by a long time, a minimum of 15 seconds in your case, and each firing of the rule takes some number of milliseconds. This rule above would fire every 15 seconds due to the repeat plus every time motion trips active or inactive, but only when the fan is on.
@ogiewon Is it accurate to say that "cancel" is actually saying "can be canceled" as long as it is followed properly in the rule by a "Cancel Delay" ?
Should this work?
That is the first rule example I posted above. You are correct that selecting "cancel" where you enter the delay makes the delay eligible to be cancelled by Cancel Delayed Actions.
cheers @homeauto2112 - but like I said I have another rule that turns everything off if there is no presence.
Case:
530pm - tp plugs turns on,
615pm no presence is detected - rule no ones home turn everything off - including plug
730pm presence detected, mode changes back from "away" to "X" - all my lights turn back on and this plug if its between 530pm-830pm; BUT
With my current 3.0 rule, I can leave and come home and the rule/plug is governed by the modes. But if I leave with the 4.0 rule, when I get home it wont turn back on until 530pm the following day..
@bravenel ?
I must say, you've given me a lot to go on here.... 
1 Like
You're showing two different rules that don't resemble each other as to what they are supposed to do. So I don't know what's wrong or what you are trying to do. And neither has anything to do with leaving or coming home.
Sorry - @bravenel. I need to recreate this rule in RM4 and need guidance please.
The presence regards to RM4 only having a trigger I can see for "certain time" vs "between times".
Trigger Event: Certain Time: 5:30 PM
Actions:
On: TP plug
Wait for Event: Certain Time 8:30 PM
Off: TP plug
Unless you are trying to run this from some other rule. But you didn't mention that... Then it would be different. In that case, the other rule would run this rule's actions, below. This will do both...
Trigger Event: Certain Time: 5:30 PM
Actions:
IF (Time between 5:30 PM and 8:29 PM) THEN
On: TP plug
ELSE
Off: TP plug
END-IF
Wait for Event: Certain Time: 8:30 PM
Off: TP plugI have a presence rule, if no ones home - turn all the lights off (including this plug) if presence returns, turn all the lights and plug back on (the sub rule being only TRUE if it was between 530 and 830pm) the rule you example above, if the presence rule turns off the plug, it wont turn back on until 530pm the next day, correct ?
*Ah - I think your edit has answered this.
