If extra light is needed in the kitchen during the day the high lights are used. The other lights don’t really provide enough extra light during the day to bother with.
OK. But if someone does turn them on I assume you would probably still want the to turn them off with no motion? That shouldn’t be a daylight dependent thing, it should just always happen unless there’s a specific reason you don’t want it to.
Is there any particular reason you don’t want to split them? Automations are free - you don’t need to conserve them! Seriously though, sometimes it’s just better to do separate automations and IMHO this is one of them. Silly me I did forget to put the switch state conditions in which would make what I’m saying make more sense I guess.
I edited my previous comment with the new conditions. They prevent the automations from firing if the switch is already on or off. Just for shits an giggles try them out. I believe they will do exactly what you were looking for.
I really don’t know why you guys want two automatons for this. I use the same code for many motion controlled lights and a single automation works perfectly.
This automation turns a light on and keeps it on as long as there is motion, turns the light off after the set period. Never fails.
alias: 'Passage downlights auto'
mode: restart
trigger:
- platform: state
entity_id: binary_sensor.passage_ms6_motion
from: 'off'
to: 'on'
- platform: state
entity_id: binary_sensor.paradox_z5_living_pir
to: 'on'
condition:
condition: or
conditions:
- condition: template
value_template: "{{ states('sensor.passage_ms6_illuminance') | int < states('input_number.passage_min_lux') | int }}"
- condition: state
entity_id: light.passage_lights
state: 'on'
action:
- service: light.turn_on
data_template:
entity_id: light.passage_lights
brightness_pct: "{{ state_attr('switch.adaptive_lighting_passage', 'brightness_pct') | int }}"
rgb_color: "{{ state_attr('switch.adaptive_lighting_passage', 'rgb_color') }}"
white_value: 0
- delay: '00:0{{ states.input_number.passage_lights_auto_off_time.state | int }}:00'
- service: light.turn_off
entity_id: light.passage_lights
I have the same code for a heap of lights and they always work the way I intended, from a single automation.
What is the delay ,were do you “state” the time ?? sorry can you explain
- delay: '00:0{{ states.input_number.passage_lights_auto_off_time.state | int }}:00'
That looks like it would be an input_number helper called passage_lights_auto_off_time and it must be between 1 min and 9 minutes. So if it was set to say 6 minutes, this template would resolve like this:
delay: '00:06:00'
It should however be using the more error friendly format of:
delay: '00:0{{ states('input_number.passage_lights_auto_off_time') | int(1) }}:00'
which ensures the state does actually resolve (eg on Home Assistant startup) and if it can’t be converted to an int, it is resolved to 1
1 Like
Exactly. I do this for all my delays so they can be adjusted via the front end rather than having them hard-coded to a specific value.
The only way an input number would not resolve is if that component didn’t load at boot for some reason, or the input number config was removed. It hasn’t ever been an issue for me so far.
For you - sure.
But for other people who come across this thread, people new to writing automations, I felt it necessary to make this point for them. Especially since errors in converting states to int or float, now causes actual errors, rather than just warnings.