Thanks a lot!
I couldn’t find anything in the GUI to get a delay in the lights so they turn back off.
But I will get the hang of it, hopefully.
okay wow, I`m just blind… 
Did you get a chance to test it?
Sorry for the delayed answer!
Yes and it works perfect, after I knew how it worked I changed all my automation so they have a timer included. Befor I had a lights on automation and lights off automation, and then for weekend. So there where like 20 Automation and now I have only 7 
Glad to hear it!
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.
For more information about the Solution tag, refer to guideline 21 in the FAQ.
1 Like
There is a problem with the Automation.
The Automation triggers if I walk in the hallway and the motion sensor triggers, the problem is as long as it detecteds motion the hole time the timer doesn’t restart and the lights turn off after 30 seconds, but if it doesnt detected motion for about 5 seconds, the timer restarts (I stopped the time to measure it)
The detection_interval is set 2 seconds of the motion sensor and I checked in Zigbee2mqtt, if the motion detection triggers from off/inkativ to on/aktiv the lights go on perfect like it should, but if then if it triggers very fast like under 1 second form on to off to on ( I waved my hand in front of it), the timer doesn’t restart, but if it is off/inkativ for like 3-4 seconds and the detected motion againt the timer restarts.
Kinda hard to describe whats the problem, but I hope somebody understands what I mean and knows a solution for it. 
Perhaps you can reverse the automation.
So set up a trigger when there i no movement for 30 seconds and make this turn off the lights.
Then have another trigger when there is movement to turn them on.
description: ""
trigger:
- platform: state
entity_id: binary_sensor.0x54ef4410007761a6_occupancy
from: "off"
to: "on"
id: "on"
- platform: state
entity_id:
- binary_sensor.0x54ef4410007761a6_occupancy
from: "on"
to: "off"
id: "off"
for:
hours: 0
minutes: 0
seconds: 30
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: "on"
- condition: numeric_state
entity_id: sensor.0x04cf8cdf3c8a20ff_illuminance_lux
below: 30
sequence:
- service: light.turn_on
target:
entity_id:
- light.0xa49e69fffe94d9a3
- light.0xa49e69fffe9a3355
data: {}
- conditions:
- condition: trigger
id: "off"
sequence:
- service: light.turn_off
target:
entity_id:
- light.0xa49e69fffe94d9a3
- light.0xa49e69fffe9a3355
data: {}
mode: single
1 Like
okay, that sounds good, will try that later! Thanks
Works perfect, Thanks a lot for the help!
When the motion sensor turns on, there’s no need for it to trigger the automation unless the light level is below 30.
If you don’t make that part of the automation’s trigger or condition, and only check the light level in the automation’s action, it means the automation will be executed (and its last_triggered updated) every time motion is detected regardless of the light level.
Here’s one way to restrict execution to only when needed:
alias: example
description: ""
trigger:
- platform: state
entity_id: binary_sensor.0x54ef4410007761a6_occupancy
from: 'off'
to: 'on'
- platform: state
entity_id: binary_sensor.0x54ef4410007761a6_occupancy
from: 'on'
to: 'off'
for:
seconds: 30
condition:
- condition: template
value_template: >
{{ trigger.to_state.state == 'off' or
(trigger.to_state.state == 'on' and
states('sensor.0x04cf8cdf3c8a20ff_illuminance_lux') | float(0) < 30) }}
action:
- service: "light.turn_{{ trigger.to_state.state }}"
target:
entity_id:
- light.0xa49e69fffe94d9a3
- light.0xa49e69fffe9a3355
mode: single
The automation’s condition can be refined even further and only turn the lights off if they are currently on (and turn on only if they are currently off).
condition:
- condition: template
value_template: >
{% set lights_on = ['light.0xa49e69fffe94d9a3', 'light.0xa49e69fffe9a3355']
| map('states') | select('eq', 'on') | count %}
{{ (trigger.to_state.state == 'off' and lights_on > 0) or
(trigger.to_state.state == 'on' and
states('sensor.0x04cf8cdf3c8a20ff_illuminance_lux') | float(0) < 30 and
lights_on < 2) }}
I’m really new to the home assistant, automation and stuff and thats high level for me 
Do I get that right, that the differents between the automation you wrote and the automation hellis wrote is, that yours only starts to trigger if the light level is below 30.
Hellis starts to trigger and then notices, ok light level below 30, no need to go on. and yours doesnt even start befor the light level is below 30.
I guess that helps when you got many automation that its not to much data for the home assisant to handle right?
Work smarter, not harder.
1 Like
Then again… However you code it, the code still needs to check the light level.
There is no or very minor difference when or where you check that.
But as noted before, mine would say it triggered when it actually didn’t turn on any lights.
1 Like
Okay, just wanted to understand the difference between the two automation.
Thanks for the help 
Its placement determines if the automation’s last_triggered is updated and if a trace is produced.
Ideally you want the automation’s last_triggered to be updated, and a trace generated, only if there was a genuine need to execute its actions. In other words, only when the automation does actual work.
One isn’t obligated to structure it that way but then the automation’s last_triggered is updated more frequently, with less meaningful values, plus a lot of worthless traces are created.
Sure… if the automation is an automation you actually care about and need to keep track of.
But for lights in at night?
I usually only put effort where it’s meaningful. But you are right that it updates the last triggered, just as I said just below the part you quoted.
Regardless of an automation’s perceived importance, when it malfunctions one might want to check its recent trace to see what went wrong. This may prove to be impossible if it records traces even when it’s unnecessary. The trace you need to see, at the moment when the malfunction occurred, may have already been discarded because, by default, it only stores the last 5 traces.
100times last-triggered-disk-writes vs 10times is in my opinion meaningful
In that case you shouldn’t have any motion detectors at all since they update and write to your disk.