I have an IKEA VALLHORN motion sensor in my home office. I want the office light to come on during the working day if the illuminance sensor on the VALLHORN drops below 2 lux for more than a minute, but only if I am actually in the office.
Fine. I set When office VALLHORN Illuminance is below 2 for 1:00 in the “when” section, and If office VALLHORN Occupancy changes to Detected for 10 seconds in the “And If” section. And this works… until the light level drops below 2 lux for 1 minute when I am not in the office.
In this scenario, the trigger event fired when the “and if” condition was false, so nothing happens. But I want the light to come on when I come back in to the office if it was already below 2 lux for 1 minute.
Putting both triggers in the When section won’t work, because it fires when any trigger becomes true.
It seems I need two identical rules, one with “if the light level drops” in the trigger section and with “if the presence sensor detects someone” in the conditions section, and a second copy of the rule with “if the presence sensor detects someone” in the trigger section and with “if the light level is below 2 lux for 1 minute” in the conditions section. If I want to change the action, or any common conditions, I now need to edit both rules.
This is not friendly! I can add building blocks to the conditions and actions sections — I should be able to add one to the triggers section too, so that I can put both these conditions in an AND block and the trigger will fire as soon as they are both true at the same time.
In your specific case, try putting the Occupancy changes to Detected for 10 seconds as the WHEN clause, and the Illuminance is below 2 for 1:00 as the AND IF clause.
EDIT: If I am understanding you correctly, the real trigger should be whether or not a person is in the room. If there is a person, then check the luminance and turn on the lights… Your current logic is reversed.
You need two triggers and two conditions that are both essentially the same.
Trigger 1: Whenever someone enters the room
Trigger 2: Whenever < 2 lux for 1 minute
Triggers are basically ORs. The automation will fire when either of them happens.
Condition 1: Someone is in the room
Condition 2: < 2 lux for at least 1 minute
Conditions are ANDs. They must both be true for the automation to continue.
The first condition will always be true when the first trigger fires and only sometimes true when the second trigger fires. The opposite applies for the second condition.
You’ve created an automation that runs when a specific event happens - and you’ve set it to fire when the lux changes. If the lux doesn’t change, an event isn’t fired and your automation doesn’t run. Whatever you put in for the “when” section will get watched for changes.
If you change up the logic, you should be able to get it working. What you’d likely want is to trigger whenever occupancy changes, then have a condition of if the lux is a certain range/value.
You are right that there must be triggers to trigger the conditions check. But the triggers do not need to be something that the users have to handle every time. Consider template sensors based on state of entities where HA will automatically handle triggering the sensor whether the entities state change. You don’t have to set triggers to do that.
I keep thinking about this. There were some similar WTHs, and the more I think about this, the more sense it makes to me.
The only thing missing then would be the ability to define actions to be done once the conditions change from fulfilled to not fulfilled. This would simplify construction of many common automations.
So let me give you an example. I want the light to be on when it’s dark, but only between 6 am and 11 pm, and only if either motion is detected or some specific other light is on. Whenever the conditions are no longer met, I want to turn the light off.
So, currently we would have to set up triggers for sunset and sunrise, for 6 am and 11 pm, for motion detector state and for the other light state. And then actually skip the conditions and instead do if statements for them to handle both turning on and off in one automation. Alternatively have 2 similar automations with similar triggers and a mirror of conditions. Either way, a bit complicated and with repeated logic.
Now imagine if HA automatically tracks triggers and we can just set it up like this:
Conditions: between sunrise and sunset, between 6 am and 11 pm, (motion detected OR another light on)
Actions when conditions met: turn on the light
Actions when conditions no longer met: turn off the light.
Am I crazy to think this makes sense and might not even be that very difficult to implement? Just automatically add triggers for anything in conditions and let us to define actions also for when conditions check changes from true to false.
The “need” to define triggers and conditions separately in the “automations-only” way of doing it is to provide maximum flexibility — whilst there is a use case as described in this WTH, there are plenty of use cases where the granular approach is needed to implement different logic.
Perhaps a solution would be to allow for helpers like my template binary sensor above to be more easily created in a UI like the automations building-block design, as part of a trigger “type” — I recognise that although my solution above is conceptually simple, it requires good knowledge of Jinja templating.
Right, that would work, but it separated the logic and the automation, which I would personally much prefer not doing. It makes it harder to debug issues.
And just to be clear, I’m not suggesting there should be no way to add triggers manually like now. I’m suggesting an option (that would be turned on by default) to have HA handle triggers automatically. Make the triggers section optional, so to speak.
The only bizarre thing is that I can set a duration requirement on the “< 2 lux” trigger, but not on the condition — there isn’t a field for that in the UI for Entity > Numeric State, though there is for Entity > State
Not quite — generally, I am already at my desk when the light level drops and I want the bulb to turn on. But if the light level drops when I am making coffee in another room, I still want the bulb to turn on when I get back. So I do need to cover both cases.
You can get around this by creating a template binary sensor that tests that lux < 2 and then using a regular entity state condition rather than a numeric condition.
