Time to leave the light on after last motion is detected problem

Configuration
1

Based on the blueprint, I created an automation that controls the lighting. The trigger is a motion sensor. The problem is that the parameter Time to leave the light on after last motion is detected set to 5 min does not switch off after this time period at all. It switches off after 2 min. I absolutely do not understand why this is happening. Please help and explain. Where is the error?

alias: Toilet motion
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.ikea_tradfri_motion_sensor_motion
    from: "off"
    to: "on"
condition: []
action:
  - if:
      - condition: state
        entity_id: schedule.nighttime
        state: "off"
    then:
      - alias: Turn on the light
        data: {}
        action: switch.turn_on
        target:
          entity_id: switch.sonoff_zbminil2_1_switch
  - alias: Wait until there is no motion from device
    wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.ikea_tradfri_motion_sensor_motion
        from: "on"
        to: "off"
    timeout:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 0
  - alias: Time to leave the light on after last motion is detected
    delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - alias: Turn off the light
    data: {}
    action: switch.turn_off
    target:
      entity_id: switch.sonoff_zbminil2_1_switch
mode: restart
max_exceeded: silent
````Preformatted text`
2

It looks like the statement to wait until motion is off has a timeout of 0, so it does not wait at all. that means, the light now turns off 5 mins after it turned on. Personally I’d not use wait for triggers for this, but use one automation for on and another for off. But blueprints need to put everything in one place, so they are usually more complicated then needed if you write the automations yourself.

3

All right, but why 2 min instead of 5 min set?

4

Because motion lasted the other 3 minutes?

5

You’re right! I didn’t take that into account. Thanks for a hint.
Separate automations are all right but I’d rather have them somehow combined. Looking with your fresh eyes, what is to be modified in the script provided?

6

Either put in a long timeout, or look at this one. It does not have the schedule, but you can copy that into the condition part and you are done:

One caviat though, the schedule should only apply to on I guess, of it might not turn off id the schedule changes inbetween. Which brings me. back to using separate automations, because the templates would not be needed, the trigger, conditions and actions for both are different, so putting it all in one automation makes it complex.

The blueprint you use has the disadvantage the light won’t turn off if you restart HA inbetween. The example I pointed to does not suffer from it, nor would two automations.

Personally, I prefer to have two simple automations that I understand over having one complex automation that behaves in ways I cannot explain.

7

Of course, you are right. I have taken your comments into account and made a completely new automation that is significantly simpler than the one based on blueprint. You could say it combines the advantages of both approaches. It works well and as expected. Please take a look and comment as I may have missed something.

alias: Hallway motion
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.lumi_motion_sensor_2_motion
condition: []
action:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ switch_target|length > 0 and command==\"on\"}}"
        sequence:
          - if:
              - condition: state
                entity_id: schedule.nighttime
                state: "off"
            then:
              - target:
                  entity_id:
                    - switch.sonoff_1000b3110f
                action: switch.turn_on
                data: {}
      - conditions:
          - condition: template
            value_template: "{{ switch_target|length > 0 and command==\"off\"}}"
        sequence:
          - delay:
              hours: 0
              minutes: 3
              seconds: 0
              milliseconds: 0
          - target:
              entity_id:
                - switch.sonoff_1000b3110f
            action: switch.turn_off
            data: {}
mode: restart
max_exceeded: silent
variables:
  switch_target:
    entity_id: switch.sonoff_zbminil2_1_switch
  command: "{{ trigger.to_state.state }}"
8

T.b.h. I do not think it is any easier to understand and there are things in there I completely do not understand, such as using variables for no good reason testing switch_target|length > 0 while that never changes, using template test when there’s no need, … I could go on. Is this something ChatGPT came up with or did you?

9

The following example turns on the switch when motion is detected but only if the nighttime schedule is off. It turns off the switch after there has been no motion reported for 5 continuous minutes.

alias: Hallway motion
description: ""
trigger:
  - platform: state
    entity_id: binary_sensor.lumi_motion_sensor_2_motion
    from: 'off'
    to: 'on'
    variables:
      is_true: "{{ is_state('schedule.nighttime', 'off') }}"
  - platform: state
    entity_id: binary_sensor.lumi_motion_sensor_2_motion
    from: 'on'
    to: 'off'
    for:
      minutes: 5
    variables:
      is_true: "{{ true }}"
condition:
  - condition: template
    value_template: "{{ is_true }}"
action:
  - action: 'switch.turn_{{ trigger.to_state.state }}'
    target:
      entity_id: switch.sonoff_zbminil2_1_switch
2 Likes
10

Thanks for the minimalist and transparent solution proposal. How do I make it work also if the light activation is manual and not by sensor condition? Unfortunately, I don’t know how to modify your script.

11

On the contrary. The reason is good. Without it, the light will not turn off if it is switched on manually.

Imagine that I am not using ChatGPT. However, as my knowledge is limited and I make mistakes, I look to the forum for inspiration and guidance as there are far more experienced people here. And even if I did use, is that a reason to be ashamed?

12

Can you explain how it works?

If this is switch_target

variables:
  switch_target:
    entity_id: switch.sonoff_zbminil2_1_switch

Then I don’t see how the length of its value can ever be zero. So the following test will always be true and never false (thereby making it an unnecessary test).

switch_target|length > 0
13

You are right. Another example of my strongly moderate knowledge. What instead?

14

Do you want the automation to not turn off the light if it was turned on manually?

The key to make it work is knowing when the switch is turned on manually as opposed to automatically (i.e. by the automation).

  • Some switches report an event when their rocker button is depressed. Detecting this event is the most reliable indicator of manual operation. However, not all switches produce such an event (you’ll need to check your specific switch’s capabilities).

  • Another way is via what is known as “trigger context”. When a trigger, like a State Trigger, is triggered, it produces a trigger object. The trigger object has various properties. For example, you used it in your automation here: trigger.to_state.state. One of the properties is “context” and its value provides some insight into what was responsible for changing the switch’s state (an automation versus manually). An example of checking the context’s three properties to confirm manual operation is posted here.

  • Yet another way is to use a “flag”, meaning that the automation sets an indicator, like an input_boolean, to on whenever it turns on the switch and sets it to off whenever it turns off the switch. If the the switch is on but the input_boolean is off then it means the automation wasn’t responsible for turning it on so it was probably turned on by something else (possibly manually). Personally, I feel the previous two methods are more reliable indicators of automatic/manual operation.

If your switch produces events, go with that. Otherwise it’ll be via the context property.

15

The opposite. I want to turn off the light the same way for both manual and sensor triggering it on.

16

Here’s one way to achieve that. The switch is turned off after 5 minutes of being on (regardless of how it was originally turned on).

alias: Hallway motion
description: ""
trigger:
  - platform: state
    entity_id: binary_sensor.lumi_motion_sensor_2_motion
    from: 'off'
    to: 'on'
    variables:
      is_true: "{{ is_state('schedule.nighttime', 'off') }}"
      mode: 'on'
  - platform: state
    entity_id: switch.sonoff_zbminil2_1_switch
    from: 'off'
    to: 'on'
    for:
      minutes: 5
    variables:
      is_true: "{{ true }}"
      mode: 'off'
condition:
  - condition: template
    value_template: "{{ is_true }}"
action:
  - action: 'switch.turn_{{ mode }}'
    target:
      entity_id: switch.sonoff_zbminil2_1_switch
17

This is exactly what it was all about. Thanks a lot!

1 Like
18

You should not be ashamed for lack of knowledge or experience. You are also free to use ChatGPT for your own use. But be aware it is very, very unreliable. That is fine if you can recognise when it is hallucinating, but if you lack knowledge and experience, how would you know? So then it is a waste of time, and you won’t learn anything from it.

For me, helping out people, in my spare time, free of cost, it is very relevant. I like to help people lean. That works if you think about it, try something, make mistakes, and ask for help. I love to do that. It does not matter what your experience is, it does not matter you make mistakes. You thought about it before you asked. That is all I care about.

But ChatGPT, despite common belief, does not think about it. It spurts out something that looks interesting, but often makes little sense. But trying to understand it takes time for me. I assume it is something some one has thought about, but it is not. In the end, pretty much none of what ChatGPT warrants mistrust, and weeding out the errors is tedious. And no one learns a thing. It is the opposite of why I want to help.

And then the error ridden example ends up here on the forum. People mistake it for something that is close to working, but it likely isn’t. And people like you get confused even more, or other AI uses it to train.

So to be perfectly honest, I am very annoyed if I find out I spent time correcting an AI. There’s also a policy on this forum about the use of AI:

I also care about honesty. So if you honestly wrote it yourself, I’m inclined to help. It you’re honest about using AI, I can choose not to invest time in understanding the yaml, maybe write something new.

19

There’s no reason to be (very) annoyed.

1 Like