So maybe I am misunderstanding... But, what would the advantage of using the Notifications App over Rule Machine?
Notifications app is just that, notifications only. Incredibly simple to setup and use. RM is a powerful and complex tool.
It will prevent you from making any one of the dozens of mistakes several of us have helped new Rule Machine users with when they come here asking why their rule doesn't work (and occasionally even complaining about how the rule is perfect so RM is obviously just broken). 
Pretty much anything you can do with a built-in app ("service"-style integrator apps aside), you could do with Rule Machine. As is often the case with software, the tradeoff is the one mentioned above: ease of use vs. power. That being said, the Notifications app still does have a lot of options that I often see people resort to RM for first without checking, like "only notify once within X minutes" (possible to do with RM, just a lot more work than filling in a box), so I'd definitely check it out first if you haven't.
1 Like
I would NEVER do that! LOL! In all honesty, I try to approach most problems as "WTH am I doing wrong?"
Actually, I get the ease of use option. I was looking for the "Notifications app does "x" and RM does not" statement. But your very last example really drives home the ease of use point.
Thanks!
RM can do pretty much anything. If you install the Notifications app, you can see what the options are. If you don't want to do that, you could also just look at the docs and see a sample (though there's a bit more it doesn't show).
RM can do everything the Notifications app can do, and more. It's probably time to retire it, just like the separate Button Controller app was.
Yeah, but in that case they could retire many standard apps. As I understand it, these are designed to (1) more easily/quickly provide common functionality without having to create rules (hence capturing and providing best practice) and (2) run more lightweight and hence slightly faster than an RM rule which requires RM itself to run (thereby also reducing load on the system). As an example, the notifications app allows notifications to run once per day. To achieve that in a rule would take a bit of work (ok it's relatively easy, but still inefficient for thousands of us to all have to create that when it can be provided "out of the box" in the standard app). So personally I'm hoping they keep these standard system apps but also continue to enhance the RM 
Actually, if I'm not mistaken RM is slightly faster than some of the standalone apps is my understanding. I don't know if it's enough of a difference to be noticeable though.
The thing about it is, they're a small team, and the notifications app is getting behind in features. I'd rather they roll it all into RM and work on other stuff personally, then have to maintain a separate app, which more often than not, I see posts from someone asking or complaining about why the notifications app "can't do this", or "can't do that", and in the end the recommendation is to just use RM anyway! 
Good points, and very well made
Please don't. 
Button Controller was different because they shared a significant section of the code base, but BC lacked features RM had like access to global variables, and the entirety of the BC interface (plus RM additions) were made available via a special trigger. I don't see a way to make that happen for notifications, but I do see it making support (whether us or them, trying to help people generate notifications) much harder.
Imagine the example: "only notify once per 30 minutes." Much easier to type a number into a box than explain to someone how to use Private Boolean, to say nothing of conditionals and a "changed" trigger. (And if your Z-Wave sensor sends duplicate events, a local variable would be better, which adds even more difficulty.)
Ha, different strokes I guess. I set up notifications and Iām done. But buttons I set up all the time. For me, I kind of wish I still had a separate button controller app.
1 Like
I do too, but only because it's easier to explain to people how to use it, and it's less scary for them--even if mostly in name only--because it's not "Rule Machine." (That being said, some people do have trouble discovering the "Button Device" trigger.)
Oh, and it's just nice for logical separation so my list of rules doesn't get so long. And most of the time I don't need the RM features, anyway. Oh, well...
1 Like
Same here. Made it easier/neater to configure my z-wave remotes.
Still not sure how I feel about the "smaller" individual apps. Yes, I tend to get into more trouble with RM... But almost everything I try to do, starts off simple/small. It then gets incorporated into other larger rules outside the capabilities of the smaller apps. Up until recently, I was using simple lighting to turn off my outside lights at sunrise. This is the simplest rule I have... But I decided to pull that into RM since it was so easy to create.
@Angus Are these simpler apps really lighter loads, requiring less CPU cycles? It would be a good justification to use these if this really was the case...
Anyway, I appreciate the feedback and input of this community.
Some people have timed Motion Lighting vs. Rule Machine for similar automations, and, no surprise, RM usually is a bit slower. Staff have hinted as this as well. In most cases, I don't think this is drastic; my concern wouldn't be CPU load but execution time. For me, time is critical for motion-based lighting automations. If I wanted to walk into a dark room, I wouldn't have Hubitat. Everything else can take a few hundred extra milliseconds for all I care, so if it's "easier" for me to do in RM than figuring out if a built-in (or custom) app can do it, then RM it is. That is still not a path I recommend to new users trying to learn the platform.
Have you measured this?
When ever I've measured any Groovy app they are 2-4x times faster. RM4 to respond to an event and execute 1 line takes ~400ms while the same action from an app takes ~150ms.
RM4 is great for what it is, but it's slower than groovy and I believe it has problems with concurrency. (aka if a sensor produces many events at once say <50ms apart)
I would think the radio would be the choke point if a sensor produces many events in rapid succession. They are serial and speed limited by the protocol definition.
@Eric.C.Miller RM4 seems to have 300ms to 400ms latency to handle events for the simplest of rules. Latency isn't a perfect measure, and I'm making a few assumptions, but let's run with it for a moment.
If a device produces more than 3 events/sec it looks like you could either be queuing events, or if it's multithreaded you're doing concurrent processing. It's pretty easy to overwhelm this rate even with protocols as slow as zwave or zigbee.
Now you can protect a rule by checking/setting a boolean, PB or otherwise*. But I do have a few sensors that appear to bounce, aka produce a lot of back to back events**. These produce interesting errors in the logs at time. And I've felt that system latency has started to increase after one of these events.
*) Boolean protection doesn't appear to be atomic. The command is if (pb == false) pb = true This looks like two steps, which means if two rules running at once on different threads both could see the pb as false and continue into the rule.
**) The logs show very fast back to back reports of the same value. I assume the sensor is sending multiple packets, or there's a bug in the radio driver and it's reading the same event multiple times.
Hmmmm??? I can't say that I have had/seen any timing issues, But I don't have any motion based rules as @bertabcd1234 has mentioned... Yet. So I'll have to remember this thread/conversation when I start implementing motion sensors into my house.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
