I need to draw upon the vast brain trust of this site to aid me with a Rule I'm attempting to write...
I have 2 sensors outside which I am able to obtain illumination values. It is my desire to write a rule that will handle the situation whereby a storm comes through (when Mode = Day) which would trigger a rule based on the 2 sensor illumination values which are <= value X, to turn on a couple of interior lights. Then when the same 2 sensors values are > X, turn off the interior lights.
The issues I see are:
Do I create 1 or 2 Rules?
It my understanding that I can't use the illumination values in my trigger because they would be OR and not AND.
If #2 is correct, then if I use "change" as the trigger would this cause a overload of my HE7?
As always, I'm open to a different approach as I'm most interested in the result than how I get there.
@bravenel is probably going to yell at me for using *changed* as a trigger, but here is how I would do it. One rule with both the on and off conditions:
This isn't a complete solution, but may at least answer one of your questions:
EDIT: Had my trigger conditions around the wrong way, > instead of <...
Triggers:
Illumination of Sensor A < X
OR
Illumination of Sensor B < X
Actions:
IF (Illumination of Sensor A < X AND Illumination of Sensor B < X)
Turn on the Light(s)
There is more to do here, handling multiple triggering of the rule, turning off the lights, etc. Thinking a wait at the end may be useful to turn the lights off, not sure if you can wait on two conditions...
You need to trigger of either sensor becoming <= X, and then test first thing in the rule if both are <= X or not (as well as testing for Day mode).
If both are <= x, turn on the lights. Then do a Wait for Conditions of both sensors being > X, followed by turning off the lights.
There is no need to used changed for this rule.
Like this:
Trigger Events: sensor 1 < = X OR sensor 2 <= X
Actions
IF(NOT Mode is Day) Exit Rule
IF(Not (sensor 1 <= X AND sensor 2 <=X) THEN
Exit Rule
END-IF
On: interior lights
Wait for Conditions: sensor 1 > X AND sensor 2 > X
Off: interior lights
UPDATE: This will fail. If one sensor goes back > X, but not both, after the lights have turned on, they won't turn off because the rule won't get back to the Wait.
Actually, I think @mikee385's rule would work for this. But it does need the test for Day mode at the beginning.
I think you will be hard pressed to find lux sensors that update frequently enough that “changed” will impact the performance of your hub in a noticeable way. Worst case scenario the rule will be evaluated ~every 7 mins during the day and not at night. Check you logs to confirm how frequently lux changes for each.
Not unless your temperature sensors are reporting every 1/2 second or quicker. Most temperature sensors report only when there is a change in temperature, and not frequently at all. This won't present a significant load on the hub.
I have a slightly different approach to the same end...
I have a mode called "cloudy" that is then used to trigger a bunch of things, including a scene for cloudy day. But I also use it to change the behavior of some of the motion lighting apps. For instance, I may not need that back hall light to come on with motion during the day, but on a cloudy day I do. I also use variables for the upper and lower limit so I can change them from a dashboard without messing with the rule.
Yeah it is convenient. One gotcha though - if you have stuff that happens when the mode changes to day, it may happen several times as the light changes. Like an Echo Speaks greeting that says "good morning," for instance. You may end up triggering that multiple times as the mode shifts from day to cloudy and back to day. It took me a couple days to figure out why my air conditioner schedule got all messed up! I also do not use the away mode, and that behaves differently - not sure how it would play out.
I was going to mention that modes are typically something you want to use where the whole house may need to operate differently, not just one set of lights. Perhaps a switch to indicate the state of the sky might be more appropriate?
Yes exactly. There's a fair amount of maintenance overhead associated with using modes the way I suggest. But it does make many tasks, particularly motion lighting tasks, easier.
That is true, it probably still comes back to the scale I would imagine... If you have a number of lights across the house that need to behave differently, then fair enough, but if it is just a small subset, that may introduce more effort elsewhere to account for it. In the end it's whatever works for the individual circumstances.
