On or off?
Either way what is sounds like you want is a simple turn on with motion then turn off after the detector is in-active for X time. For that basic rules or motion lighting app will do that.
2 Likes
ah so it's very new.
just when I need 
great !
thanks
Question.
Does this have less startup overhead than RM? I know you said RM was approx 75ms load time.
1 Like
Not much less. All apps incur overhead of 50 to 60 msecs, more or less.
1 Like
Having used rule machine, CoRE and WebCoRE in smartthings before I came over to Hubitat, I agree with those that have encouraged using Hubitat’s built-in apps to accomplish your automation goal, which is absolutely possible, just requires an understanding of how each of them works.
But in case you decide to look into their options, I thought I’d clarify that WebCoRE has been ported to Hubitat. That means that the groovy code portion runs on your Hubitat hub. The web interface runs in the WebCoRE cloud, just like with SmartThings, unless you choose to run it on your own web server (which is possible if you use an RPi or similar always-on PC).
AFAIK, CoRE was not ported to Hubitat, but I never really even looked into it. I’m surprised to hear anyone still uses it, TBH, since it pre-dates even WebCoRE. But like rule machine on ST, if a piston is still working despite being quite old, why replace it,? So I get that.
As an old ST user, you might find this thread interesting. Rule Machine was the first “real” rule engine that was available for ST, IMHO.
It still works ok for Hubitat too 
.
4 Likes
Cool. So no real reason to convert simpler existing RMs.
Thanks.
There is this huge urban myth going around about RM overhead. If you're banging the sh** out of your hub with all sorts of stuff, so that the hub is overwhelmed, app overhead might be something to consider. Otherwise, simply put, it is not an issue of concern.
"It it ain't broke don't fix it."
3 Likes
Yup I get it
I just keep trying to apply the KISS principle.
Sometimes, not often, engineers have been known to over engineer things.
A number of occasions I have had things working and then had a oh $&@# moment and realized I could have handled it simpler.
Edit: plus I assume the new app will not have access to GVs.
Perhaps I’m dense, but I’ve read your post 3 times and I’m not seeing the difference.. the pseudo rule Bruce wrote also isn’t going to cancel itself as written, as least as far as I’m seeing.
I don’t really follow why you’d need to “ask” your lights anything - I’m not sure that makes sense in an event driven system.
1 Like
Yep looks like you’re right for those actions. I was thinking other actions where you typically have to mark it as cancelable and explicitly call an action to cancel. However, the example used a straight time delay which does require it to be cancelable and would require another action to cancel a wait.
Anyway, my overall point still stands, I’m not sure that what you are stating is any different than the rule offered up in practice. At least for the example laid out in the last couple of posts.
Which in practice, you end up with the same outcome. Light turns on at 9, wait 5, light turns off at 9:05. Or your preference, light is on at 9, 5 elapses, "something" polls the light to check state and it turns off. You end up with the same outcome.
Either way, given the event driven nature of the hub, rules and actions are triggered based off of an event triggering. Rules or apps don't just run constantly in the background when no events are occuring.
But good luck to you, seems like you've got something that works in the way it went already.
How would the system know that it is time to check this? Would it check the time and event history every minute? With the other solution it only runs when the event you are interested in happens
All you do is this
Trigger: light on
Actions:
Wait for elapsed time 30 minutes
If (lights ON) Light off
Now it does a check after the 30 mins and if it's still in what ever state it does something?
You could then put it in a repeat, maybe to check again? Can't remember but this was answered before in another thread, it is possible to do what you want you just need to think about it. Whilst still remembering the apps are based on events
Well, you could have variables for the last time every bulb changed with rules to update them on state changes, then have a rule that goes through them, but... what triggers that rule?
It could be done with variables, but I fail to see why one would. Nobody is doing it with variables cause the end result doesn't change and the rule posted by @bravenel works fine. But if you want Rule Machine to trigger something after a light has been on for 30 minutes, without using rule machine's "Wait for Events" or "Wait for Condition" do it with variables. It will be more complicated and involved to create the rule, and at the end of the day it won't have any increased functionality over the method shown above, but it will adhere to your specific condition of only triggering after a light has been on for 30 minutes.
Not everything is a myth...
I translated all my Rule Machine rules to a (even better working) custom app.
The usage statistics dropped from ca. 7% to 0.1% => Factor of 70!
I’m not sure anyone has argued that an experienced developer couldn’t write more efficient, purpose-built apps that can execute faster or with fewer system resources than rule machine. In fact @bravenel usually says the opposite.
The myth, as I understand it, largely centers around the idea that rule machine’s resource use or execution time can be measured as greater than option x, y or z.
So that means the other options must be “better,” or that using rule machine is a huge risk for inducing general degraded performance that’s actually perceptible to users as automations are running in their home environment.
Part a is true, but that doesn’t mean part b is.
You raise a good point. If there is no noticeable degrade in performance, than you are only relying on measurements and that is not as simple as it sounds.
I tried one custom app that allows conditions as "triggers", its execution time was quicker at the expense of running way more often. When any of the parts that made up the conditions in the automation changed the app would fire up and run. Yes, its execution time was less than RM, but this came at the expense of running way more often. So what really is the gain, and how do you measure this?
1 Like
That's an easy one:
Just look at the "Percentage of uptime spent on each app (% of total column)" in the App stats - it counts the sum of all activities.
Those stats clearly say that not only every app call is much faster, but also the sum of all calls is 70 times less than the equivalent RM rules.
Among other things, the Hubitat GUI is now much smoother to use... 
