Now, I would like to extend the functionality a bit.
Within the timeframe when the light is on, it could be that someone is manually switching off the light. However, this switch is in the same sensor area and therefore the automation is triggered again as there is a movement within the reach of this sensor (PIR) and light turns on again.
How can I ignore any breach within - let’s say 15 seconds after switching off the light - to avoid this automation is switching on the light again?
Timer helpers are my weapon of choice for all instances where I want manual control over what happens. That is because you can test them and alter them any time you like. In this case you could simply start a manual override timer and test here if the timer is active.
Something like: when light is switched off manually, set by default the helper with the current time + 15 seconds and use this helper in my automation where the condition should validate if current time >= helper time before switching on the light. Is that what you mean?
Can helpers store time? I actually have a minimum of experience with helpers, although I see 53 helpers in my current configuration (created not that I was aware )
The consequence will be that I have to create many automations (for the amount of PIR sensors, in case 26) to set this helper each time the switch is being used…
Is there also an alternative possible? Like for instance, at the current automation at the When clause checking if the light.x has been turned off (either manual or even this automation) then wait for 15 seconds… as the mode of the automation is set to “single”, it should not be restarted when a new breach occurs within 15 seconds…
You could add a delay at the end of the automation to prevent it from firing again. It will end up to be a huge pain if you are still there, the motion detector failed to see it, you wave but it ignores you during the delay.
I think it’s not that simple… the trigger “off” waits for 20 minutes and then turn off the light. The manual switch is somewhere in between those 20 minutes. Meanwhile, when the sensor is breached again I have noticed every time the automation is triggered again so the light is turned on automatically.
According to the documentation (I have the feeling, but it’s not literally said) that the for is not really keeping the automation into its proces for those 20 minutes, waiting to pass. It feels like the automation is finishing its part when going from “breach” to “normal” within a few seconds and the automation is becoming available again for a new trigger, but if nothing happened after 20 minutes it’s doing its last part according to what has been defined for “off” at actions. That may clarify why a new breach turns on the light again, even while waiting 20 minutes to pass from past cycle. Actually, the 20 minutes are overwritten after a new “breach” and getting into “normal” after a few seconds again and it will finish its part after another 20 minutes to perform the “off” at actions. Basically, this extension of time is working fine and has been tested.
So, I actually thought the automation is waiting for 20 minutes before really switching off and not being available within this time frame. Intentionally setting the automation mode to single presuming the automation to wait for 20 minutes, it basically results in a restart (similar to mode “restart”) as the automation becomes available after a few seconds when the sensor goes from “breach” to “normal”.
I said put a delay at the end, not a for. A delay is a separate action to wait a specific time. That will wait and keep the automation active. Combined with single mode, the action won’t trigger again during the delay.
- delay:
minutes: 20
Note that a delay does not survive a restart of HA. A timer can be set to survive a restart using the option in its settings.
My current automation functions with an accumulative time effect. So, normally when the sensor is breached it’s on for 20 minutes. However, when it’s for instance breached again after the first breach, let’s say after 10 minutes, the light will be on for 10+20 = 30 minutes.
Would this work by applying your delay? As you said, a “delay” is a separate action which will wait in its current automation. As it’s in mode “single”, it won’t be interrupted to start and wait for 20 minutes again.
The automation you posted will go off as soon as there is 20 min continuous no breach following a breach. It will do that regardless what happened in between. It has nothing to do with the duration of the ‘breach’. So I have a hard time mapping that to your description if prolonged on time.
The only reason I mentioned the delay is because you asked for it. My original advise to use a timer for manual overrides stands. That is because you can start it, prolong it, stop it, test it, display it and do whenever you want without creating long running automations.
Using a delay at the end of a single mode automation is kind of a hacky way to disable the automation for a while. It works, it is easy, but it has its limits. And because you combined on and off automations in one more complex automaation, it will temporarily disable both.
Personally I’d rater have separate automations for different actions, because while the number of automations increase, the automations themselves become way simpler and easier to read. You can loose the or in the conditions and the choose because the triggers already chose for you. The automation for on has different triggers, conditions and actions than the one for off, so the reason to put those together are very faint.
Long running automations are possible, but are kind of going against the design principles of an event driven system, which as Home Assistant is. That is why for behaves the way it does - it perfectly fits withing the event driven approach. Delay is fine for short waits, but I would not use them for anything else.
alias: Light - Dinner Room on
triggers:
- trigger: state
entity_id:
- sensor.pir_eetkamer
to:
- Breach
- Alarm
conditions:
- condition: state
entity_id: sun.sun
state: below_horizon
- condition: not
conditions:
- condition: state
entity_id: timer.manual_override
state: active
actions:
- action: light.turn_on
metadata: {}
data: {}
target:
entity_id: light.dining_room_light_diner_table_182
mode: single
alias: Light - Dinner Room off
triggers:
- trigger: state
entity_id:
- sensor.pir_eetkamer
to: Normal
for:
minutes: 20
conditions: []
actions:
- action: light.turn_off
target:
entity_id: light.dining_room_light_diner_table_182
mode: single
Maybe I have a simple solution as the basis works perfect…
If there is a breach, it normally turns on the light. It only checks if the sun is below_horizon.
This I should extend by checking if the light was off for the past 15 seconds. So, if it was just on and manually switched off, then breached it should not do anything for 15 seconds.
I’m not sure how I can implement this. Maybe the for statement with a minus ;-)?
Any experience?
It would look like this:
conditions:
- condition: or
conditions:
- condition: and
conditions:
- condition: trigger
id: "on"
- condition: state
entity_id: sun.sun
state: below_horizon
- condition: state
entity_id: light.dining_room_light_diner_table_182
state: "off"
for:
hours: 0
minutes: -15
seconds: 0
- condition: trigger
id: "off"
I just edited in the automations I would use in my previous post. You just need to think of the automation that starts the override timer. If the button is a separate entity in HA, I would have that trigger the override timer. You could also look for light off while ‘breached’.
In your example, the minutes should be positive. It would still prevent lights turning on for a period of time when there was no manual override. Say you leave the room don’t touch the off button, come back 20+10 mins later, you are in the conditions to ignore turning on.
What do you mean? Are you referring to another post from you as you haven’t edited the code in this post…
A negative number in the for doesn’t work I have noticed.
The light is just an entity with prefix “light.”, I don’t have an entity switch. (the entity is derived from Fibaro with many Z-wave switches). So, I can’t check if the switch has been manually touched. Nevertheless as they are almost the same, I can check the light if it has been turned off (I don’t know the distinction if this was done by the switch or the automation).
I think for going towards the solution, I need a Helper for this challenge and I need to create an additional automation checking the light when turned off and set this helper. This is very unfortunate when trying to keep things compact.
If I understand you correctly, the Helper as mentioned here would fix this? Do you see any alternative to avoid creating a helper and an additional automation?
Compact is a matter of opinion, because you need ids in triggers, ors and chooses to put everything in one automation. the more complex the behaviour, the more complex your compact automation becomes until you can no longer see what is what in your compact automation (which gets longer and longer).
I think you added this later in a modification. Sorry, I haven’t seen
I will look into it… thanks.
I presume your entity_id: timer.manual override is the new Helper you have created. Wow, when creating a Helper it has a timer as well and it’s easy to set for 15 seconds!
Where do you set the timer when the light is manually switched off? Do you intend to make a separate automation which is triggered when light is off and set the timer (for 15s)?
I couldn’t write the automation because I did not know if you had a button entity then. But I would write an automation that if the light turns off while motion is detected (or maybe even better: motion is not normal for more than xx mins) then the override timer is started.
And that is where the power comes from: having a separate automation to determine if the override should be active gives you flexibility as well as simple automations.
alias: Light - Dinner Room override
triggers:
- trigger: state
entity_id: light.dining_room_light_diner_table_182
to: "off"
conditions:
- condition: not
conditions:
- condition: state
entity_id: sensor.philips_sml002_lqi
state: Normal
for:
minutes: 20
actions:
- action: timer.start
target:
entity_id: timer.manual_override
The for 20 minutes is to rule out the automatic off after 20 mins. You could also do other things instead such as check if the auto off automation has just run. This is just one example how you could detect manual action. Wether this works depends on if you expect motion to detect when the button is used.
Thanks @Edwin_D, I have implemented 3 automations from you:
Light - Dinner Room on
Light - Dinner Room off
Light - Dinner Room override
Unfortunately, the behaviour is similar as what I had. When breached again it’s turned on most of the times (so, sometimes it does what it needs to do but within the 15 seconds it’s turned on again when breached several times). I need more time testing it, specifically to test the timer which is set by the automation. I need a bit more (free available) time and I will come back about it.
To anticipate already a bit to the test, I have the feeling something goes wrong with my sensor. The alarm PIR goes on (it has a red LED and is easy to monitor) and it takes around 2 seconds before going off again. If manually switched before going off it could be too quick. However, waiting the PIR to go off and then manually switch off it normally results in turning on the light again by the automation…
So, as said. I will do further testing… I will report to you.
)
