Speedy lighting & Rule Machine overhead

This thread is unrelated to slowdown of hubs, but an attempt to get speedy rules
If it's one thing that we notice, it's walking into a dark room, and waiting for the lights to turn on. So frustrating. Then I read this:

After reading Bruce's post about RM's runtime overhead, it got me thinking. All my lighting rules were in Rule Machine. I had also previously created my own zone motion sensors (in rule machine) and then developed large lighting rules in Rule Machine, so all my lighting logic went through Rule Machine effectively twice. I've not been happy with the snappiness of the rules for motion. So, I created a test by using the inbuilt Motion Lighting app to turn on the lights. I then logged the data and compared the results (simultaneously).

My tests results show that Rule Machine is nearly a 1.2 seconds slower than Motion lighting. The Rule machine logic is going through rule machine twice, (once: my own zone motion controller rule, and two: the Rule Machine lighting rule itself) so it's probably not a fair comparison, and since the Motion Lighting app gets to the gate first, it's getting through the gate much earlier (which may then also slow down the Rule machine processing).

So, what I've done is use Motion Lighting simply for turning on the light quickly, and disabling all other Motion Lighting commands for off (via selecting all modes for disable off). I'm turning off the lights via my normal Rule Machine rule for that room.

I plan to do this for all my lighting rules - using the inbuilt Motion Lighting app for quickly turning on the lights, and nothing else. Alternatively, if anyone can put together a tiny/speedy lighting app that only turns on lights via a few selectable motion sensors, that might work too.

Hope this helps.


to add to this, i really liked the way ML and SL turned the lights on (it might just be a state of mind) but RM punched the lights on and off for me with motion, where ML and SL seemed to have a slight fade to on (hard to explain / personal pref). For really simple stuff, ive been using ML with zone motion sensors and really liking it.
Good research there mike.

I had a similar experience. I wanted something a little more complex than ML and moved to some RM configurations. Firstly, using GVs, which was a no go, they added a huge overhead. So I moved to local variables. A little less templated and useful overall but much faster. None the less, still too slow compared to ML.

The challenge with an app like RM and even ML to some extent, is they're built to be robust and flexible. Robust apps are more complex.

In the end I wrote my own custom app to do it exactly as I was wanting. The performance and reliability in a purpose built app is superior by far.


Any chance you might share your app so folks could build off your framework?

I've shared a few apps to this community. My Occupancy Governor, in particular, is not ready for the public and I'm without the capacity to support it currently. When a dev releases an app here, it takes quite a lot of time to support initially.

These are the most popular.

1 Like

I was referring to the custom app that you created for your motion lighting that you mentioned was much faster and more reliable than RM. I dont even know where to start writing an app to do motion lighting, seeing someones example would give a huge kick-start.

That's Occupancy Governor. It's not finished enough to release.
There are a lot of custom apps that are more simple than Occupancy Governor that would be a better example of getting started.

There's a community maintained Github as well with several basic examples.

why this?

Mainly because I have pretty complicated rules involving color and delays.

In the bedroom, I have automatic switches set by my android phone (see this post).

In the other rooms, I have lights that turn on/off/colored based on TV's, garage door open, lux and presence.

When I said I am using the Rule Machine rules for turning off, it's really that AND any turning on, apart from motion lighting.

This talk about lighting got me thinking: would there be any interest in creating some sort of open-source "Community Lighting" app that provides a skeleton for a basic motion lighting app that users can then tweak the code for to suit their specific needs? I can certainly provide the basis but am not sure when to stop--my immediate thought would be to provide something that just does on with motion, off with inactivity after a timeout, with possible restrictions based on time or mode...but then I've basically provided Simple Lighting with fewer features, albeit one users could customize to meet their needs without resorting to a full-blown Rule (how many people would actually want to do this versus that?).


I certainly would appreciate it. Something that is small and lightweight. I'm wondering how much quicker it would be than say the built in Motion Lighting app?

I'm guessing not much, though Motion Lighting has become a bit complex as feature requests have been added. No clue what the code looks like, of course. The main advantage I'd see here is that people who know Groovy--or can even just modify other people's--would have a "custom Groovy lighting app" template they could modify to suit their needs, especially if all they need to do is change an "or" to an "and" somewhere or whatnot.

Yeah, all I'd need would be: motion, lux, mode, and a switch to disable on. I'd do everything else in the Rule Machine. I could probably even get by without the mode restriction, as long as there was a switch for disable on.

It bugs me no end when I walk into a room, and I begin to wonder why the lights have not turned on yet.

I'm definitely intrigued by this. I've written an app that turns my lights on and off automatically for each room. Been using it for months, works great for my needs. I'm going to strip it down so I have two separate child apps, one for just ON and another to handle just OFF. Will be interesting to see if there is any speed difference.

My opinion of the platform is the fewer subscription to events the better. I do not believe that separating on and off into different apps is more efficient, probably the opposite (though likely immeasurable). In such a case I imagine you need a subscription to the same motion event in both apps.

My point was more a long the lines of how many lines of code and conditions need to be executed before the app turns on or off the lights. The fewer, the faster.