Reliability Has Been Super

I noticed a difference as I said a billion times throughout other threads.

What kind of motion sensor devices do you have ?

I primarily use the GE in-wall combo Motion Dimmer/switches.

I have a few ecolink zwave battery operated ones too, but I have to have the pet setting on (have pets) and they are slow as heck.

Also have a few NYCE Ceiling motion sensors (zigbee) and the are great and very fast. Expensive, though.

1 Like

Just an FYI, it looks like my motion lighting issue was due to how I had the ML rules setup. I added some switch behavior in because I kept having issues with ML thinking the light was in the opposite on/off state (maybe a separate issue/bug, but that's another story).

Looks like how I did this made a loop in the on/off logic, causing the 3-7 events/second going to/from the hub.

Not sure if Bruce is going to make a code change to prevent that type of scenario, or if it is just up to end users to not do that.

I would argue an app shouldn't easily let you make a loop, but would also concede that the issue was mainly a well intentioned "user error" issue, not app problem per se.

6 Likes

That was the lure of RM v4.. that WebCoRE like Rules could be built. And that is true enough... however, "Rules are Free" is still a clear winner.

I still retain individual rules for turning on Lights and things with independent rules for turning them off. That's RM2.5 or earlier thinking that's locked into my head, I imagine, but I don't have the slow downs, still. I've always attributed that to Luck more than Skill.. but maybe the Luck is in the skill-less use of lots of Free Rules. :smiley:

4 Likes

That's me. I'm still locked in the 'daisy-chaining of small rules' mindset. Maybe that has kept the gremlins away? I don't know. It does make it easier for this dumba$$ to troubleshoot.

1 Like

Counter argument, I have tons of RM rules some highly complex, others simple. All my buttons are controlled using RM button controller UI aswell, because even they are really complicated depending on loads of conditions. I also have motion lighting probably using every single little bit of that app and I don't have any issues what so ever. Only time I reboot the hub is for updates or if they break something in the beta and it crashes the hub. Other than that not had a issue for about 18 months now. I also have a ton of "trusted 3rd party apps".
Key thing with my hub? I don't have loads of cloud or IP devices. Have a few ping devices for presence, GH, Chromecast (beta) and SONOS.

5 Likes

Things like race conditions are almost always user error in the end. Yes, Bruce tries to put in as many (reasonable) workarounds to prevent users from doing that to themselves, but he can't anticipate every usage of every variable.

The gradual slowdown some users see over time with RM may indeed be user error, too. However, if it is something specific being done by users in RM rules, I don't think anyone knows exactly what those specific things are that lead to the performance degradation over time.

Otherwise Bruce would have coded around them/prevented them and/or there would be warnings to "don't do this in RM rules".

1 Like

Just curious, how is the distribution of your rules RM4, RM3 RM2 etc?

All RM4, upgraded all old version during the beta from memory.

2 Likes

Y’all are being such positive naysayers In this thread, I don’t know what to think :rofl:

@j715 Thanks for the post. Good to hear the good sometimes when there’s so much complaining on the forum. Maybe there’s something to the idea of chaining rules together that makes the difference. I’ve been very transparent about my Rube Goldberg method of chaining rules together with virtual switches. Works very well.

I have over 100 rules and many virtual switches that tie them together. And a good point @csteele that RM4 partly came from complaining that RM3 and earlier wasn’t like webCoRE (although that’s my personal take, not how you phrased it :wink:). While I do recognize the value it ads, it’s still much more difficult for me to use than RM3 and earlier. I personally had hopes to see something more like Stringify was. With RM4, I got something sort of like it, but not really. Still a damn good app regardless.

I love my hubs too. And yes, I have things disrupted among two HE hubs now (among others). All my major issues have turned out to have been device related. That’s not to say the hub is bug free. Nothing is. But RM definitely is a star of my system. And yes, things are being done to address the complaints with the system, just as they always have been :zipper_mouth_face:

For the record, a lot of my stuff is IP based. Very few of my devices are joined directly to the main hub. My problem (partly self-inflicted) Z-Wave devices are on a hub by themselves, along with some OSRAM bulbs to keep them company. “Misery loves company” right?

My main hub is RM with two Z-Wave plus devices and a dozen or so Zigbee devices.

Everything else is IP connected.

  • Insteon via Insteon hub
  • Hue via Hue Bridge
  • Lutron via Smart Bridge Pro
  • Ring Z-Wave devices via Ring Hub (although that could easily be @bcopeland ‘s very good drivers, but I keep alarm systems separate out of choice).
  • Xiaomi devices via Xiaomi Aqara HomeKit hub and Homebridge
  • PIA Z-Wave devices via Link to Hub/Hub link
  • Alexa / GH
  • Google Assistant Relay and Castweb API
1 Like

My reliability has been perfect, just over 2 years, never had a hub related issue. All my issues have been self-inflicted or community code which was removed or fixed. Reboots only for upgrades

I have ~20 RM 4 rules that for one reason or another I can't move to SL/ML, mixture of Z-Wave, Z-Wave Plus and Zigbee, no locks, nothing exotic

Also can't say it's skill on my part so it must be either dumb luck or a great product... I'll go with the latter

Enjoy

4 Likes

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