I've not had an issue but lately my hub is under severe load and I'm guessing my rules might be causing an issue? Is there a better way to do the below these days?
Thanks
As a starting point (not for performance reasons), can you describe what you are trying to achieve in the rule?
yeah sorry, so if it's dark and motion is detected the lights switch on, then they should switch off after a couple of minutes of no motion detection.
If you only want the whole thing to trigger when someone hasn't already chosen to turn on those lights, best to have the lights not being on as the predicate
Can't imagine this would cause you too many performance issues, even with a quick reporting cycle for the motion sensor.
In terms of rule design (and I'm no expert), I am thinking the luminance condition could be moved into the new predicates section, switching around the condition to be >= 25, meaning that the rule won't even be looking for motion during brighter times.
The only thing I'm not sure about, but can't imagine would be an issue, would be whether the off would still occur when the predicate is false... I wouldn't think that should be an issue. Actually.... yes, it would be if you still have that as a trigger....
So I would have:
Predicate:
Illuminance of Hall Sensor >= 25
Illuminance of Hall Sensor <= 25
Trigger:
Hall sensor becomes active
Actions:
On Hall Light
Wait for not motion in Hall Sensor
Off Hall Light -> delayed 4 seconds
1 Like
Thanks, I'll give it a try.
1 Like
And you may also want to consider looking at the Motion Lighting App, but why not learn a little more about RM in the process, then refine later... 
1 Like
I am confused, I thought the OP's goal was to turn on the lights if it is dark and motion is detected. If so shouldn't the Predicate be....
Illuminance of Hall Sensor <= 25 ????
Unless I am wrong I thought the rule will only be triggered if the Predicate Conditions are true. Therefore the Illuminance should be <=25.
You're completely correct, I somehow got it in my head I needed to flip the logic around....
I've corrected my earlier post. Thanks for spotting that @Sakman
1 Like
I happen to like the rule suggested by @sburke781 better*, but your rule as written is a pretty common pattern and shouldn't be causing problems. Have you tried checking the "Logs" page for "Device Stats" and "App Stats" to see if anything there looks unusual? (If you're on on 2.2.9, where this was moved to "Logs," these are under "Runtime Stats" on their own page instead.) It seems far more likely to me you'll discover something there than with this innocent-looking rule.
*Actually, I'd make a minor change: use a "Wait for event: elapsed time" instead of a delay (this will need to be its own action, since you can't attach this to an action like you can with delays) so it gets cancelled on re-trigger, or even easier in Rule 5.1, combine it into a "Wait for condition: Hall Sensor inactive --> duration 0:00:04," then do the Off.
2 Likes
