Reliability Has Been Super

Just for shits and giggles, I installed RM and Lutron this morning just to time my motion lighting.

So only one rule. If motion is active turn light on. There is no other apps installed besides Maker.

800-900 ms to turn my light on. Urgh!

So now, I'm reading up on programming. I'm going to make my own basic app, which all it will do is, if motion active, turn light on. I want to see how fast it is after I get this together.

1 Like

That is very slow Here's a similar setup: zwave+ motion sensor (Dome) used to turn on a Lutron switch.

Screen Shot 2020-04-21 at 10.21.06 AM

So that's 174 ms from motion being detected to the Lutron switch being turned on.

I'm doing all my motion lighting through Node-RED.

Can I ask if this is a consistent timing.
The reason I ask is the first time I get a rule to run after a reboot or defining it, they always run slow the first time then pick up after that.
Just wondering.

1 Like

I agree, which is why I use HS for motion lighting.

I want to construct my own mini apps to see if it's faster then ML and RM.

1 Like

Seems likely. ML would give me a time of ~300 msec for the same automation that I linked to above (I've never used RM for motion lighting, so I have no RM times to compare).

@asj had released small apps that worked well for motion lighting and the times with his apps were around 200-250 msec for the same automation as the one above.

It's already well defined and clear that RM is slower than a micro-app or even ML. RM is huge and has overhead.

1 Like

Do you have a link to his apps?

Yes, I know. ML delivers around 350 ms on average.

Then what's the test against? Or just collecting the stats to have them?

RM -> timing
ML -> timing
App -> timing

To compare all the timings. It looks like this was done though and I have my answer. A small mini app delivers 250ms in comparison to 350ms using the ML app.

Cobra has a motion lighting app you might try.


Also @jeubanks

Recall - my tests were done while my HE had lots of other apps (and RM rules) running. So I would hesitate to make any specific conclusions from the times I've noted (for ML and @asj's Pluggable Lighting). However, the broad conclusion that Pluggable Lighting is faster than ML is accurate.

What I am comfortable saying is that using Maker-API + Node-RED consistently yields the fastest motion lighting automation I have quantified.


So I tossed together Node-Red and the hubitat plugin which uses maker.

Motion lighting is around 200-220ms.

1 Like


1 Like

If you use this Lutron Caseta integration for node-red, you'll shave another 30-50 ms off that.

I'm going to take a look at this.

Stupid question, I have it set if motion is inactive to go to a delay of 4 mins, and then to tell the light to turn off. If the function (don't know my terminology) becomes active again would the delay cancel?

In general, I use a stop-timer node to stop the sequence when motion is active, and it restarts when motion is inactive. Here's an example

To avoid derailing this thread, I suggest following up on the node-red nodes for Hubitat thread.




Have you tried lovelace animated backgrounds? The animations change based on the status of Dark Sky weather entity. It's pretty awesome!

1 Like