So I have many rules that turn lights on/off based on lux sensors, door triggers, occupancy, etc.
I seem to have some challenges in my logic when trying to prevent the rules from repeating when not necessary.
For example, I want to turn on cafe lights if it's dark enough, we're home, and we're in the space they are installed. I want to turn them off if any of those change. So I want a rule to both turn on and off based on conditions, but I don't want to send the 'on command' every time the trigger fires the rule. So I have logic like "turn ON if x, y, and z, and also if cafe lights are off, ELSE turn OFF if any of x, y, and z (are not desired state) and lights are ON."
I have too many that seem to have small gaps that cause lights to turn on/off over and over from the trigger and I'm betting that I'm just approaching it slightly wrong. what's the best practice method for these scenarios?
I'm not sure how RuleMachine works, but in webCoRE a command is only sent if the device is not already in the desired state. That is, it will not send the "Turn On" command if the light is already on. I would assume this happens at the Hubitat device level so it could be handled similarly with RuleMachine.
I think you can probably get rid of the "we're home" condition. If you're in the room, you're home.
For automatic off, I just use the motion sensor status, so if there's no motion in 5 minutes, turn off the light. If lux rises above your threshold in that time, the light just stays on until there is no motion. No biggie.
Thinking of lux... I also set global variables "light inside" and "light outside" based on the lux level from my sensor. That way I can just reference the variable instead of constantly evaluating the light level in every rule/piston. That makes it easy to set the same lux level trigger/condition across the board.
My suggestion is to simplify your rules as much as possible, then only add in the additional conditions if you need them. I can't tell you how many times I've had rules collide and do crazy things.
MY best practice is to return to simpler automations when things start getting out of hand, and just reflect on what I think I want and why choices so far didn't work. Eventually a comment on this site or an internal light bulb will spark a reason to return to adding things that would be convenient to include (as opposed to necessary).
Earlier I had problems due to being too ambitious too quickly in this regard. But I don't think that's an uncommon trait for home automators.
The other thing to consider is if using Rule Machine is even the "right" tool for this kind of request. Have you looked at Room Lighting as it might better serve your needs and simplify the approach.
The sample above gives you an idea of how to combine motion, presence, and lux with activation. Most likely, you only need motion to turn on and off you lights since that would determine occupancy. You can probably get rid of presence at home since motion would help determine that; however, I included it in the sample to show how it can be used to limit activation. Using Room Lighting, you can also limit activation via Lux level. Basically, the sample shows that a motion sensor must be active, lux must be below a certain level, and presence must be true before a light turns on. The light will turn off after the motion sensor goes inactive and stays that way for 5 minutes.
I actually left it off at first on purpose because as @Equis and @bob.t were getting at, I wanted to back away from what I had and rethink from the ground up. Especially since I've had struggles with this on more than one rule, I was betting it was just the wrong approach.
But here's the current rule, with the 'off' command disabled for now since I have other rules that will turn it off when it really matters, like leaving the house or going to bed. Of course they were on most of the day today until I actually turned them off bc automation makes me lazy sometimes lol
One aspect I didn't mention, but as @Equis mentioned, I have a virtual omni sensor and I leverage 2 zooz outdoor motion sensors and another (Aqara zigbee) inside the porch that dictate whether it's 'dark' (0), 'gloomy' (50), or full daytime light-ish (100) and I use that for setting either brightness in some lights, a 'rainy day scene', and of course cafe lights (I have 4 different switches of them, and this rule is only for the 2 in the rear yard)
Required Expressions are something I haven't really leveraged as much as I probably should have, but really do like the idea of running less (even if skipping) just to decrease load and cycles on the machine.
But if I had the lux below certain level, this would never trigger to turn them off. Likewise if I left.
But otherwise, triggers for motion and inactive for several minutes isn't exactly as desired, because I basically want them on even if we're inside or in the front yard etc.
The basic use case is that we're outside at least once / moving around and if it's dark enough.
This is a great example of why you need to look into required expressions and use two rules. For the turn on rule, make the required expressions be that the lights are off, in certain modes, and the OMNI sensor is at or below the correct level. This rule would only run once since the lights will turn on and make the required expression false.
For the second rule, require that the lights be on and have the action turn off the lights when the appropriate triggers hit (not present, Lux above certain limit, etcā¦). Utilizing two rules would help simplify your approach rather than trying to cram it into one.
Alright! Now this is why I posted. What you're saying is very out of the box for my perspective on this issue.
So I guess the reason I didn't go that route initially is that I'd have like 60% of my rules to be on vs off.
But on the other (current) hand, I feel like I have a million conditions for so many rules so it is probably so much cleaner to do that sorting on the top layer.
Thanks all for helping me think through this! Best community in the world!
Slightly off topic, but related. This reminds me of some people I work with who try to cram like 20 left outer joins and multiple nested CASE statements in their SQL queries instead of just separating out UPDATES (and actually leaving comments as to why certain values are updated to somethingā¦) and all because they want to write everything in a single statement.
But, guess whose code is easier to read and more supportable? I live by MR KISS (Model Reality. Keep It Simple Stupid) Quite honestly, the performance difference is so minuscule and I donāt end up confusing the optimizer.
All to say. I donāt think thereās an issue with separate rules as long as you are consistent with your naming convention so itās easy to find something.
My thoughts exactly... and to your point, cramming 20 joins in a SQL query is right on track with my intents on my rules with conditions.. nesting nested nests into conditions and not only is it likely easier on the machine but also unbelievably more reliable and easier to troubleshoot as long as you standardize your naming conventions.
You could change the [ELSE] and the following [IF] to [ELSE-IF], which functions the same in this case but does not require you to close the nested IF, and then the rule will function the same but not require the second [END-IF]
Glad this discussion triggered some thoughts on how to help simplify/solve your questions. I do have one more idea for you to consider. Have you looked at Room Lighting? That app would allow you to dictate both activate(on)/off in a single instance.
The above gives a rough example of how you might want to activate and turn off your lights. Your triggers for both rules would be the Means to turn on and off. Your required expressions would be the limiting conditions for activation/turning off.
I think Room Lighting would be the best app for your initial wants, but separate rules in Rule Machine would work too.
I really need to look more into Room Lights. I tried a couple automations with it but didn't immediately get excited about it compared to what I was using with motion lighting or RM. Turns out as you mention, it has more features baked in and actually would fit many of my scenarios from both.
I lean heavy on RM bc I specify just about any trigger, action, or condition; compared to motion lighting, room lights, basic rules, etc that limit some of those aspects
