100% and I agree it is super frustrating when you have a bug with the built in apps, especially when it is not you and ACTUALLY is a bug with the core code. But for that you pay with harder upkeep and changing, and my understanding is less optimization compared to a purpose built app.
1 Like
I get why you find that useful. 
I just haven't had significant problems w/SA and the Motion app so that hasn't been an issue for me. I also don't have automation needs complex enough that RM is required for me, and I find creating and editing rules in RM annoyingly "clicky," as in way too many clicks required.
Really glad HE and the HE community provide enough options/choices that folks can each find their own way.
1 Like
thank you all for the input, I might check out the biult in soon, but i didn't want to have to learn 3-4 apps on my migration and wanted to learn RM
so far the only thing im stuck on it RM is getting the lights to stay on if the motion keeps happing
1 Like
Your rule, if you want to go that route, has two problems: your "Wait for active" should be "Wait forward inactive" (it's already active or the rule would not have triggered; I assume this was a wrong selection by accident?). Second, you need to remove the timeout and add a "Wait for event/elapsed time" for 5 minutes before the "Off," otherwise that "off" is going to happen regardless of what the sensor does.
If you watched the video from a year and a half or so ago, this would be similar to what they did, except likely with "Delays" that need to specifically be canceled ("Waits" avoid this: the rule triggering again gets rid of them), an option not as easily available at that time. But I also second the advice to not immediately discount the built-in apps. This isn't ST. Good luck!
3 Likes
no mistake just lack of experiance. LOL i honselty do not follow what you are saying here
I once i get this working I'll try out the app for my other lighting stuff since everyone seems to like it so much 
but i will not beable to sleep until i finsh this LOL
I guess I should just state the two changes plainly.
- Change your second action to "Wait for event: Kitchen motion inactive" and remove the timeout.
- Add a "Wait for event: elapsed time 0:05:00" between your (current) second and third actions, so just before the "Off: Kitchen" action. This is under "Wait for events," which I think is what your screenshot is asking.
If this isn't easy enough, I might second the suggestion from others above to start with Simple Automation Rules (the easiest app that can handle the automation above) or Motion Lighting (not much more complicated but has more options than you need for just the above). But I do understand wanting to learn Rule Machine, and the above modifications are one way to make the rule work as expected (there are more in the docs) if you want to keep using RM for this.
2 Likes
like this?
OMG, it's incredibly clicky and rat maze like, no flow, like node red or other GUI programming interfaces. And if you click"back" then all hell breaks loose, like it was programmed by Dominion.
3 Likes
No, the "Wait for event: Motion active --> timeout 0:05:00" thing is still problematic. "Elapsed time" is an option you can choose with "Wait for event" rather than a specific device/capability. (If you don't see this, make sure you're on at least Hubitat platform 2.2.4 from Settings > Check for Update.)
I will also confess to not checking through all the motion/contact logic but will trust that you did.
i just got my HUB saturday, and i checked for updates, from the screen shot a couple posts ago I dont have that option under the delay/repat/wait
I literally LOL at this. Funny, but sad at the same time.
3 Likes
From a "Wait" and motion perspective, that looks OK to me! (Again, I'll assume you know what you want with the contact sensors and the conditionals they're in.)
umm i dont think its working the light is not turning off basically if a door is open i want the light to still turn off after X minutes
the "wash room door" goes to the kitchen it is open most of the time, the "wash room doorhw" goes to garage and is close 99.9% of the time. (yes im going to rename it lol)
That won't happen as-is because your first conditional will be met, and the action contained inside it is the only thing that will run until another trigger happens. If opening the door would also create motion, you can rework the rule to just use any kind of sensor to turn it on and just motion to turn it off. Maybe that would work?
yeah im notice the logs aways "skip" the last rule (i have it set to activate on change) the ON is working great will come on if any door opens OR motion.
The off part is broken (by me not knowing what theck im doing)
Sorry @bertabcd1234, maybe I am not following but I’ve just been using an “on”, and then put my delay on the “off” (see attached example).
Now, I understand “wait for event motion inactive” before triggering an off but...
What is the advantage or purpose of “wait for event: elapsed time?” before the “off” command?
A "delay" will not be cancelled unless you mark it as such and also run a "Cancel Delayed Actions" action somewhere. A "wait" of any kind will be cancelled automatically when the rule is triggered. So, in your rule, if you press button 1, then wait four minutes, then press it again, the light will turn off one minute (not five) after that last press--nothing cancelled the originally scheduled delay. A wait would be cancelled with the second button press because that is a trigger event for your rule. Alternatively, the existing rule could be written with a "Cancel Delayed Actions" at the beginning and with marking "cancel?" (sometimes displayed as "cancelable") on the delayed "Off" action.
4 Likes
Awesome explanation, thanks @bertabcd1234, you rock!
Ok so my next question is, are there scenarios where either may be more advantageous than the other?
(Canceled delayed actions VS Wait)
