Hi OK I want to make my first Home Assistant routine to just see how well it works. (Maybe it has another name in Home Assistant?) But anyway I’m a little stuck. I want a Tuya smart light to turn on whenever a motion is detected by one of my Philips Hue Motion sensors. But I only want it to happen after a certain hour at night (say 10pm) and to then turn off again after 5 minutes. But I am a bit lost on how to set the time and how to get the light to automatically switch back off again after 5 minutes. The rest before this is simple enough.
We call those “automations”. Welcome aboard, and here’s two examples I use for a lamp on my sunroom. The motion sensor only turns on the lamp if it’s dark outside.
- id: '0001'
alias: Sunroom Lamp ON if Occupancy and Dark
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor_158d0003cea5b8
from: 'off'
to: 'on'
condition:
- below: '50'
condition: numeric_state
entity_id: sensor.bh1750_illuminance
action:
- entity_id: switch.sunroom_rabbit_lamp
service: homeassistant.turn_on
- id: '0002'
alias: Sunroom Lamp OFF if no Occupancy and Dark
trigger:
- platform: state
entity_id: binary_sensor.motion_sensor_158d0003cea5b8
to: 'off'
for: 0:03:00
condition:
- condition: numeric_state
entity_id: sensor.bh1750_illuminance
below: '50'
action:
- entity_id: switch.sunroom_rabbit_lamp
service: homeassistant.turn_off
Won’t that leave the light on all day when the initial motion happened just before dawn and the illuminance went over 50 before the 3 minute timeout is reached ?
@123, doesn’t that create the same problem as your other combined automation, by leaving the light on all day when motion happened between 5:55 and 6:00, as the off trigger doesn’t make it through the condition anymore ?
For completion, here is my full automation which you could easily modify to use the 10pm time condition rather than my lux based condition. It works perfectly.
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_luminance') | int < states('input_number.passage_min_lux') | int }}"
- condition: state
entity_id: light.passage_lights
state: 'on'
action:
- service: light.turn_on
entity_id: light.passage_lights
- delay: '00:0{{ states.input_number.passage_lights_auto_off_time.state | int }}:00'
- service: light.turn_off
entity_id: light.passage_lights
I’ve used input_numbers for the lux and time settings so that they can be adjusted via the front end without needing to change any code.
Your failure scenario assumes motion occurs moments before the condition’s time range ends (BTW, you didn’t specify the end of the range, just “after 10 PM”, so I assumed it ends at 6:00 and you can change that to whatever you prefer). The same ‘edge case’ can happen if the condition uses light level (and motion occurs just before the light level increases above the threshold value).
The only way to guarantee the light is turned off is to exclude it from the condition. In other words, the time range applies for turning on the light but not for turning it off.
The condition after default isn’t mandatory but it avoid needlessly commanding the light off if it’s already off.
EDIT
For completeness, a similar condition can be added prior to turning on the light. It should turn on the light only if it’s currently off. I use this technique throughout my automations to avoid creating needless traffic, namely avoiding turning on things that are already on.
I’m not the OP so I didn’t specify anything. I just pointed out that your automation examples will suffer this failure mode under the given circumstances. They can be avoided using an approach like @sparkydave did, with an explicit delay.
Which shows how easily unpredictable corner cases can arise even for seemingly simple automations.
That’s why my version works. The lux level does of course go up once the lights are on (hence I have a condition allowing a ‘retrigger’ to work if the lights are already on) but since the ‘off’ command is part of the original action, it still turns off.
Yes, this covers the scenario when a person is still in the room walking around, such that it retriggers the automation to essentially restart the ‘delay off’ command. Without that ‘light is already on’ condition, the automation would not continue since the light being on has increased the lux level above the threshold. This way the off command is retained once the person leaves the room.
It can be avoided in lots of different ways. The point here is to keep it simple. If you think about it, it’s ironic to even have a discussion about something that should be this simple. The OPs use case is pretty much the very basics of home automation and should be easy to setup with a few clicks. The fact that even something so simple is complicated in HA and spawns discussions about best practices and corner cases is very telling.
Developer bias. No, it’s not very complex for someone who ‘already knows’. The YAML posted in this thread alone would be pretty much an instant turn off for anyone trying HA and who isn’t a techie. And wasn’t HA trying to reach more of the non-tech crowd last I checked ? Anyway, this is going offtopic I guess.
Maybe blueprints are a way forward for situations like this.
If the implication is that I think it isn’t complicated because I am a developer, then allow me to clarify that I am not a developer.
Agreed.
Blueprints were introduced as a means of allowing a broader audience to create automation logic by simply ‘filling out a form’.
Naturally, the users who create the Blueprints will have discussions that are likely to be opaque to anyone who has never even created an automation or script (let alone a Blueprint).
In this case, the OP has requested an automation. However, if the OP is overwhelmed by any of what has been posted so far then I suggest they explore the many existing Blueprints for motion-activated lighting. Here’s one (there are others):