I have two rules that use illuminance sensors. Both are written that the Triggers are IF less than, then do X or if greater than, then do Y. In the log snippet below, the less than/greater than is around 100. However, I noticed that the rule evaluates any change in the illuminance (in this case from 409 to 408) as a trigger and plays through the rule. Which puts extra stress on the system and logs more data.
I need the change in illuminace to actually be a trigger, as it is what turns on inside lights, so I can not just pull that out of the triggers and leave as a condition. Is there a way to write it to be like 'changes to be less than or equal to 100 or changes to be greater than 100 (such that a change from 400 to 401 does not trigger the rule)?
If you are using "changed" as a trigger, the the rule will evaluate every time the illuminance changes. You would need to set the specific trigger to prevent this.
The luminance doesn’t change that quickly, does it? How about making the trigger be a periodic event, trigger every minute or two, then evaluate your luminance condition. Might be able to make a better suggestion, but we haven’t seen your full rule.
Sometimes it does change often, depending on which sensors you are using. If you are using the aeotec ones be aware that they're very chatty little guys. If you can at all figure it out a way not to use illuminance as a trigger, then you'll be in better shape, although I saw a rule that referenced greater than and less than that worked just fine as a trigger.
[EDIT]
I have a temperature/lux sensor that is so accurate I had to space the settngs out a bit to prevent fluttering of a fan.
HSM status reports changed OR
Presence: Anyone Home changed OR
Master Lights Override(off) turns changed OR
Illuminance of B Multisensor Outside(19) reports <= 100
Actions:
IF (HSM status is Disarmed(T) AND
Presence: Anyone Home present(T) AND
Illuminance of B Multisensor Outside(19) is <= 100(T) AND
FR Sofa(on) is off(F) [FALSE]) THEN
On: FR Sofa, P Ceiling, P Desk, K Under Cabinet, Inside Lights Group
Dim: K Under Cabinet: 25
Dim: FR Sofa, P Ceiling: 33
Cancel Delayed Actions
ELSE
IF (FR Sofa(on) is on(T) AND
( HSM status is Armed Away(F) OR
HSM status is Armed Home(F) OR
HSM status is Armed Night(F) OR
Illuminance of B Multisensor Outside(19) is > 100(F)
) [FALSE]) THEN
Delay 0:05:00 (cancelable)
Off: FR Sofa, DR Sideboard, P Ceiling, P Desk, Inside Lights Group
END-IF
The sensor is sending the info to Hubitat for any change of illuminance anyway. That's what lux sensors do. So there is already that traffic going on. I have several rules that trigger based on illuminance changes just like yours and it is fine. My rule takes 2 lux sensors, averages them, and stores the result into a virtual lux sensor. It gets triggered on any lux change at either sensor.
The load on the hub should not be an issue unless the rule is very large. You can try to configure it to filter out the redundant cases quickly. For example, use a local variable to count and then process only the 10th iteration. Or store the lux in a local variable and calculate the change and then only proceed to the bulk of your rule if the change is significant (as you indicated in your original post). I doubt if this will affect your hub performance much.
Or as @672southmain suggests, take a time-based approach to your trigger instead, if the rate of lux change is not important to you.
I know you have your answer but I just wanted to add that I use my lux sensor to change the status of a virtual switch. Then use the switch to do the automations. I don’t know if that actually reduces load or not...
Trigger : lux < 400
Turn DarkVS off
Wait for event lux > 400 then
Turn DarkVS on
Then in a second rule have the trigger be DarkVS turns on
As @Angus_M said, the hub is already receiving the data, so in terms of hub load, it's not going to be a big deal. However, you did mention the excessive logging. You can reduce that by turning off some or all of the logging for your rule. I find that once I have a rule working as I want it, I don't really need to see much logging for it, so I turn it off.
I'm in Connecticut and just missed the outage area caused by a local storm. Small compared to Laura but knocked out power just the same. Funny at the same time I'm trying to sell my generator (too big for me to handle).
In Memphis just getting the tail end of Laura..not enough to cause the outage...but a tree fell over two streets down and took down the lines.... such is life
This really depends on what the hub has to evaluate for each event. Things like lux, power, and temperature as triggers for rules could have a more significant impact on the hub than simply logging the value, date and time.
I would love to hear something on this from the staff. What is the best practice for tiggers with greater than or less than options? These are often things that will be evaluated many times without actual needed change.
Trigger temp > 80
Turn on fan
Wait for event temp < 80
Turn off fan
The above might get evaluated 100s of times a day and not make an actual change to the fan. Is that just part of the overhead of the hub or does it know the previous state of thing and not reevaluate until it is a change?
Thanks, the virtual switch is interesting. At least with that approach, the hub traffic is between the rule and the software switch. In my case, it is sending extra ZWave traffic over my network - which is likely worse than the virtual switch. Appreciate the thought!
It's easy enough to add a conditional to the rule to check if the fan is off before issuing the command to switch it on, and vice versa further down the rule. That would at least reduce the radio traffic (assuming it was a zigbee or z-wave device). The rule itself, as defined here, is very light and really won't load the hub much at all.
It is easy to add that conditional statement.. I 100% agree. However with the new KISS method that is encouraged by Bruce, we are rethinking rules to avoid conditionals like this. And make things less needlessly complex. So I guess what I am looking for is an example of what a rule that involves a greater than/less than is supposed to look like from a KISS standpoint.
