I do agree it's 100% less susceptible to change. For these two closets the light sets that turn on are the same. My bad for the example. They just happen to be next to each other. Each of my others will be different light sets for each sensor, so I don't think just matching on open / close will work in the same rule.
My guess is I could future proof this a little better by doing two "contain" statements for each instead of an exact match.
IE - It's probably a safe bet %text% will always contain the device name and either "open" or "closed." ...even if the overall string changed.
It awesome that the RM gives such easy access to complex action and triggers. The more I learn how to get around in it...the better I like my C8.
Unless you change the device name for some reason.
I would honestly avoid using that for rules, and just create separate rules for each different action so you can just trigger on the device state. When you select the device as an entity from a menu it is linked to the device ID and not the text of the name.
Complexity of the rule and future maintenance issues.
Since the names of the rules is totally flexible you can name them so they sort / group how you want. There is even another app in development that can give you little containers to group rules with.
Future Maintenace sounds like a solid reason. I'm kind of used to complexity. While it's been a couple decades, I used to program database applications with 10's of thousands of lines in C++ just before object oriented got big.
That said, my focus probably isn't what it used to be either.
Now that makes a huge difference. My HS4 hub ran on an i7 laptop w/ 64g. Logic decision speed/load was never my problem with it. If the C8 has trouble running complex rules with multiple IF/AND/OR statements in a rule...that's good to know upfront.
Maybe you meant something else by smoothly...but that is what it conveys. If not. please clarify.
Conditional rules are not the issue. Poorly designed rules can be an issue. These hubs use ARM processors - like the ones in Android TVs. They’re not as powerful as an i7. They also have less RAM than your HS4 hub.
What makes several IF/AND/OR statements in a rule poorly designed?
I really do just want to understand. 10% CPU seems like nothing. I wiped out a complete S2 install (with over 100 devices) and started over again to avoid impacts to speed after reading posts and asking questions ....and started over again.
Hubitat is usually described as an event-driven system. Apps are normally not "running" except in response to some event (or sometimes scheduled job, callback method, or similar, but this is by far the most common for most apps). A trigger and wait event in a rule (which is an app) just create an event subscription. The app is effectively "sleeping" in either case until the event happens, at which point it will wake and do whatever it is supposed to do.
In the case above, the rule will start running the actions when triggered (because of an event). When the wait is reached, a subscription will be created for that event too until either that event happens or something else cancels it (the rule being re-triggered, manual cancellation from another rule, etc.).
The second rule, then, is normally described as more "efficent" (though in practical use I would not consider the first inefficient, just technically less so and also more difficult to write, which matters some too). Instead of triggering on any of two events and then needing to check which one it was, you just trigger on one specific event (and temporarily create a subscription for another when needed) and get to write simpler actions.
...is probably what @aaiyar would have said I didn't steal this moment from him.
If the processor never breaks 10% or so while running rules, it seems like even in the rare event of two rules colliding at exactly the same time there would be some leeway.
However, processing must be impacting at some point though. I’ve seen the hub miss turning off all of my lights using the dimmer approach to off. I’ve change that over to switches where the programming Interface gives you the option to only send commands to devices that are on. I just did that tonight, but I am assuming that will solve that problem.
I recall seeing somebody post on another topic (S2) that there is an app for monitoring the CPU. I have no idea how detailed it is, but it might be interesting to see the impact of different approaches on the system.
You guys have been awesome. It’s great to get guidance from people who know what they’re doing for someone coming over from another platform to Hubitat!
