Want to make my first HA routine, but am stuck. Please help. Motion sensor turms on light

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.

Can anyone please advise?

We call those “automations”. :slight_smile: 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

If you ever wanted to consolidate the two automations into one, here’s how:

- id: '9999'
  alias: Motion Activated Sunroom Lamp
  trigger:
  - platform: state
    entity_id: binary_sensor.motion_sensor_158d0003cea5b8    
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.motion_sensor_158d0003cea5b8
    to: 'off'
    for: '00:03:00'
  condition:
  - below: '50'
    condition: numeric_state
    entity_id: sensor.bh1750_illuminance
  action:
  - entity_id: switch.sunroom_rabbit_lamp
    service: "switch.turn_{{ trigger.to_state.state }}"
1 Like

You, my friend, are most kind! :slight_smile:

1 Like

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 ?

The last bit is easy, similar to this

    action:
      - service: light.turn_on
        entity_id: light.passage_lights
      - delay: '00:05:00'
      - service: light.turn_off
        entity_id: light.passage_lights

This should meet your requirements:

- id: '9999'
  alias: Motion Activated Light
  trigger:
  - platform: state
    entity_id: binary_sensor.your_philips_hue_motion_sensor    
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.your_philips_hue_motion_sensor
    to: 'off'
    for: '00:05:00'
  condition:
  - condition: template
    value_template: "{{ now().hour >= 22 or now().hour <= 6 }}"
  action:
  - entity_id: light.your_light
    service: "light.turn_{{ trigger.to_state.state }}"

This turns off the light 5 minutes after no motion is detected.

That’s the best way, as far as I see it.

@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.

That’s easily done with choose.

- id: '9999'
  alias: Motion Activated Light
  trigger:
  - platform: state
    entity_id: binary_sensor.your_philips_hue_motion_sensor    
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.your_philips_hue_motion_sensor
    to: 'off'
    for: '00:05:00'
  action:
  - choose:
    - conditions: "{{ trigger.to_state.state == 'on' and (now().hour >= 22 or now().hour <= 6) }}"
      sequence:
      - service: light.turn_on
        entity_id: light.your_light
    default:
    - condition: template
      value_template: "{{ is_state('light.your_light', 'on') }}"
    - service: light.turn_off
      entity_id: light.your_light

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.

Your automation has an execution path that turns on the light even when it’s already on, then turns it off 5 minutes later.

It can be avoided another way and sparkydave’s example has a peculiar execution path.

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.

If you look at some of the Blueprints for motion-activated lights, they can be quite complex.

Intetesting. I don’t think any of what has been posted so far is complicated.

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):

1 Like