The latest version of the blueprint was intended to fix this. Have you imported the latest version?
Unfortunately I cannot test or make changes the next few days due to being out of the house for Christmas.
I’ll pick it up after if there are changes required🙂
Thank you very much for the quick reply.
I will update the version now.
I wait anxiously for the further development and wish us all contemplative days.
I made a small change which seems to solve this:
From:
- wait_for_trigger:
platform: state
entity_id: !input motion_sensor
from: "on"
to: "off"
- delay:
minutes: '{{ states[no_motion_wait].state | int }}'
To:
- wait_for_trigger:
platform: state
entity_id: !input motion_sensor
from: "on"
to: "off"
for:
minutes: '{{ states[no_motion_wait].state | int }}'
This is a very small change but I believe the difference is the for in the wait_for_trigger is handled differently then a delay when this script is restarted.
Hope you all have enjoyed your christmas!
I have just retested the blueprint, but I cannot reproduce the described errors of the light turning off after the automation has been retriggered. For me the automation restarts just fine with the lastest version of the blueprint (with the delay in it).
I am able to keep postponing the turning off of the entity by retriggering the motion sensor.
A possible reason for this not happening, is that some motion sensors stay in the ‘on’ state for a long time.
When you try to trigger it when it is still in the ‘on’ state, the automation will not restart and the light will turn off at the originally determined time.
You can only restart the automation by triggering the motion sensor so it’s state goes from ‘off’ to ‘on’. Then again the light should only turn of after a delay that is set when the motion sensor turns to the ‘off’ state again. I have tested retriggering the automation 3-4 times and every time it turns off at exactly x minutes after the motion sensor was last marked as ‘off’.
So in short, the blueprint works exactly as intended for me.
But if you still have problems with the latest version do let me know 
I will test it now. Thanks.
I have one more request:
Can be set so that after some time the lights are dimmed for a predefined time until they are then switched off completely.
However, it should be possible during this dimming phase that the lights are dimmed up again when movement is detected.
Also a suggestion:
For example, if the automation is triggered and the blocker entity is pressed in the middle of this phase, the automation will still completed. It would be nicer if the automation would actually reset to zero.
EDIT
Similar like this: Motion-activated lights with switch override in just eight Node-RED nodes | BonaniTech
and
EDIT2
Working brilliantly with my Xmas Xiaomi Aqara motion sensor and hallway light! Thanks so much - I was just starting to dig in and thought to check the new blueprints contributions and there it was! The only thing I’m missing for total happiness is percent brightness and transition time variables for the target. 
So I’m starting to have a bug now. I am using a simple setup, using a light group for 4 LIFX bulbs, using a ESP motion sensor that was being used previously in node red to do motion lights, I have a blocking entity for turning off the automation, and I’ve set the time to turn the light off after motion to 30 seconds.
My issue is no matter what time delay I set it as (5 seconds, 30 seconds, 5 minutes, etc), the lights will turn off after 3 seconds (which is the time it takes for the motion sensor to detected motion after its cool down). So in other words, the lights detects motion, turns on lights, then after 3 seconds the motion sensor registers that there is no more motion, so it turns the lights back off.
So any ideas, or information thats needed?
I think it’s best not to put this in my blueprint, since I expect this to be a requirement which not a lot of people want. I don’t want to incorporate every niche requirement with additional optional parameters. This makes the blueprint harder to maintain and test.
But you can of course edit the blueprint to add this functionality.
If more people want it I can look into it though.
The blocker entity is there to prevent the target entity from turning on in the first place.
So what do you want to happen if the blocker entity is pressed in the wait time, to immediately turn off the entity?
I’m not sure thats possible, but I can look into it.
To turn on a light with a defined brightness and other attributes, you could define a scene or a script. If I would use separate inputs for all possible light attributes the blueprint becomes a mess. The problem is, in that case the light will not turn off, since turning off a light by the same script or scene that turned it on is not possible, I think.
A possible solution for this is that I define a separate ‘turn-off input’, that when defined is used to turn off this entity. That way you could turn on the entity by the target entity input, and turn off a different entity (like a light or group).
I’ll run some tests with this later.
It seems like in this case the turn off delay is not properly used in your automation.
Can you post the generated automation that you created with this blueprint? And preferably also the input_number definition of your delay value?
Well: We still have the classic wall switches at home that are operated via ZigBee. (I use these: https://www.reddit.com/r/homeautomation/comments/kkhak6/minimalistic_smart_switch_gira_55_design_with/)
If, for example, the switch in the kitchen is switched to “On” after motion has been detected, the light should remain on.
Conversely, if the switch is operated before motion is detected: The automation should be interrupted until the switch is set to “Off” again.
Looks like you are seaching for a Group
That way the automation does not need to handle this and it gets pretty easy.
I understand the usecase now!
The solution I added is a separate turn-off blocking entity.
If you define this (optional) entity, the target entity will not turn off when the state of the turn off entity is ‘on’. This should cover your usecase
Just dropping this here in case its valuable to anyone. I made a pretty similar blueprint (that I won’t share as it’s pretty much a lesser version of this one with some specific conditions that reflect my environment). But one thing I found useful was for the automation to not trigger a predefined scene in the case where I manually selected a different scene (e.g. a specific mood or holiday scene) or manually adjusted some lights. To circumvent this, I added the following choose condition at the top of my action:
- choose:
- conditions:
- condition: state
entity_id: !input light_target
state: "on"
sequence:
- service: scene.create
data:
scene_id: preserve_state
snapshot_entities:
- !input light_target
- service: scene.turn_on
data:
entity_id: scene.preserve_state
This allows the automation to default to a scene depending to the time of day, but in the case manual changes have been made to the scene or another scene has been manually selected, the automation won’t override those choices by returning to the default scene upon detecting new motion.
thank you for this blueprint. I have afew questions/ request:
1- can you make the motion sensor input to select more than one motion sensor?
2-can the blocking entity input be also changed to select more than one entity?
I think that instead of using input you should use slider right at automation part, it is more convenient than example
no_motion_wait:
name: (OPTIONAL) Turn off wait time
description: Time to leave the light on after last motion is detected. If not used entity will not auto turn off. Only works for target_entity types light and switch.
default:
selector:
number:
min: 1
max: 1000
step: 1.0
mode: slider
Not exactly sure what you mean by posting the generated automation or input_number definition for the delay value. But maybe you mean this:
- id: '1609136071584'
alias: Motion Lights - Basement Recessed Lights
description: ''
use_blueprint:
path: freakshock88/motion_illuminance_activated_entity.yaml
input:
motion_sensor: binary_sensor.sensenode_motion
target_entity: light.basement_recessed_lights
blocker_entity: input_boolean.manual_ctrl_basement_recessed_lights
no_motion_wait: '1'
- id: '1609136847697'
alias: Motion Lights - Utility Room Lights
description: ''
use_blueprint:
path: freakshock88/motion_illuminance_activated_entity.yaml
input:
motion_sensor: binary_sensor.wyzesense_basementstairs1
target_entity: light.utility_room
blocker_entity: input_boolean.manual_ctrl_utility_room_light
no_motion_wait: '300'
- id: '1609137276785'
alias: Motion Lights - Guest Room Lights
description: ''
use_blueprint:
path: freakshock88/motion_illuminance_activated_entity.yaml
input:
target_entity: group.guest_room
motion_sensor: binary_sensor.sensenode3_motion
blocker_entity: input_boolean.manual_ctrl_guest_room_lights
no_motion_wait: '900'
There are 3 no_motion_wait inputs, for 3 animations, 1 second, 300 seconds and 900 seconds. For the one that has 1 second, I’ve tried any number here, the lights always turn off after 3 seconds.
I see the problem.
The no_motion_wait input does not support hardcoded values (integers/numbers).
It expects an input_number entity, like I have stated in the documentation (see the Optional entities example YAML section).
You need to create this input_number entity yourself.
This is a choice I have made because I want to be able to change the value dynamically without editing the automation itself.