Execute any service (turn on switch/light/scene/scripts etc., even run another automation) based on any entity's state change (motion sensor, illuminance, sun rise/set)

Import blueprint from here

Introduction

This blueprint is able to execute any home assistant service (typically “turn on”, aka “homeassistant.turn_on”) on any target entity (typically switch/light/scene/script) based on a trigger entity’s state (typically a motion sensor, or a door/window sensor, or any entity with a state, e.g. sun/switch/light/group), then run an alternate home assistant service (typically “turn off”) after the trigger entity is no longer at expected state after given timeout.

It also supports using illuminance sensor and sun elevation as alternative triggers.

If you got confused about what this blueprint does, it basically does what this blueprint Turn on light, switch, scene, script or group based on motion, illuminance, sun (+ more conditions) does (I was inspired by it, kudos to the author!), but in a more generic way and with a few differences:

  • This blueprint is more generic about the action you can execute with target entity as stated above.
  • This blueprint handles home assistant restart. e.g. Your lights that were turned on before the home assistant will be turned off properly after the home assistant restart, following the same no motion (or other trigger entity state change) timeout.
  • This blueprint handles automation changes. e.g. Your lights will be properly turned off after you edited an automation (which restarts all executing automations and resets their action status).
  • This blueprint handles manual turn on/off of target entity. e.g. Your lights will be properly turned off following the same no motion timeout even if you manually turned them on using UI/App, or physical switch.
  • This blueprint supports leveraging sun elevation. This is very useful if you do not have any illuminance sensor, or your illuminance sensor is installed under the light controlled by an automation (once the light is on, the illuminance sensor will no longer return an expected value).
  • This blueprint provide a convenient way to select an alternative timeout in specific time range. In my case, I want the timeout to be longer during dinner time, since my family are mostly sitting still and the motion sensor may miss some of our motions. In some cases, I want the timeout to be shorted after middle night, since I may be just walking down the hallway to go to the bathroom, I don’t want my hallway light stay on for too long.

Use Cases & Examples

Turn on “Hallway Light” when any motion sensor in the “group.kitchen_hallway_motion_sensors” group detected a motion, and when illuminance sensor returned a value below 400. Turn off the light if all motion sensors are cleared for 10 seconds, or if all motion sensors are cleared for 300 seconds when the time is between 6pm and 9:40pm.

alias: Hallway Light
description: ''
use_blueprint:
  path: ql-owo-lp/state_based_entity_control.yaml
  input:
    trigger_entity: group.kitchen_hallway_motion_sensors
    target_entity: switch.kitchen_hallway_light
    illuminance_sensor: sensor.illumination_1
    illuminance_below: '400'
    alt_trigger_timeouts: '18:00:00-21:40:00,300'
    trigger_timeout: '10'

Turn on “Office Light” when “binary_sensor.motion_sensor_1” detected a motion, and when illuminance sensor returned a value below 400 or the Sun elevation is below 9. Turn off the light if the motion sensors are cleared for 15 seconds.

alias: Office Light
description: ''
use_blueprint:
  path: ql-owo-lp/state_based_entity_control.yaml
  input:
    trigger_entity: binary_sensor.motion_sensor_1
    target_entity: group.office_lights
    trigger_timeout: '15'
    illuminance_sensor: sensor.illumination_1
    illuminance_below: '400'
    sun_elevation_below: '9'

Turn on “Closet Light” when closet door is open, and when illuminance sensor returned a value below 400 or the Sun elevation is below 9. Turn off the light if the closet door is closed for 5 seconds.

alias: Closet Light
description: ''
use_blueprint:
  path: ql-owo-lp/state_based_entity_control.yaml
  input:
    trigger_entity: group.closet_door_sensors
    target_entity: group.closet_lights
    trigger_timeout: '5'
    illuminance_sensor: sensor.illumination_1
    illuminance_below: '400'
    sun_elevation_below: '9'

Change log:

  • 2/1/2021: This blueprint supports multiple states and multiple alternate timeouts now. If you are updating to this new version from an older version, and you used the alternate timeout field, you will have to update the automation to follow the new format. The alternate timeout is now merged into one field instead of three fields. See the field documentation for details about the new format.

Enjoy the blueprint!

19 Likes

Looks Great, thanks :slight_smile:

Thank you for this great Blueprint automation.
I have 5 binary sensors for the garage.

  • binary_sensor.wyzesense_1 (internal door sensor)
  • binary_sensor.wyzesense_2 (garage door sensor)
  • binary_sensor.wyzesense_3 (garage door sensor)
  • binary_sensor.wyzesense_4 (motion sensor)
  • binary_sensor.lumi_lumi_sensor_motion_aq2_5_ias_zone (Xiaomi Aqara motion sensor)
    How would you recommend to group the sensors, all in one group or break it into 2/3 groups.
    Basically when I open the interior door to the garage, I would like the lights to turn on and stay on if it continues to sense motion even when the interior door and garage doors are closed.
    I really would appreciate some guidance!

Hi Brian,
My understanding is, you can just group all these door sensors and motion sensors together. The sensor group’s state will stay ‘on’ if any of the entity/sensor in that group is ‘on’.

Looks like this is the blueprint I need. Thank you!
The only thing that seems works not as designed is blocker_entity, blocker_entity_state (and corresponding timeout_blocker_entity and timeout_blocker_entity_state.

If I set only blocker_entity (without blocker_entity_state) automation does not trigger regardless its state. OK, seems that they both should be omitted or set at once.
If I set both blocker_entity and blocker_entity_state to state that should block turning on the light, it does not work, but when I set the opposite state, it works.

I created input_boolean and named it enable I want my automation to work only when enable is set to on.

As described in documentation, I set blocker_entity to my enable entity and corresponding blocker_entity_state value to off (I want to block turning on light when enable is off), but this does not work, but opposite state works - if I set blocker_entity_state to on it turns on my light only when enable is on.

The same applies to timeout_blocker_entity and timeout_blocker_entity_state and turning the light off.

Overall, I made it work as I expected, but not according the documentation.

Hope my explanation is clear.

That indeed is a bug. I do not use this at my home so didn’t find this problem.
I have fixed this in the blueprint. You should see the correct behavior if you reimport the blueprint.

Not sure if I handle this blueprint correct. I have a daylight sensor providing several states (see https://www.home-assistant.io/integrations/deconz/#deconz-daylight-sensor) and I want it to trigger a light to be turned on. Easy so far. BUT:

  • I want that light to stay on, regardless to what state the trigger entity changes after triggering the automation. Therefore I set “trigger timeout” to 0.
  • As the trigger entity has several states I cannot use the blocking entity state.
  1. Timeout doesn´t work. As soon as the trigger entity´s state changes, light is being turned off. :frowning:
    Update: I found a “workaround” to achieve what I´m looking for (don´t turning off the light): I set “Trigger timeout” to “-1”, either I didn´t see this or it´s not part of the documentation (yet). Does this have any side effects? Will the automation still finish, will something run in the background or sth. like that?
  2. Next step/optional: What would I need to set if I want the light to be turned off once the trigger entity enters a specific other state (e. g. sun rises, so turn light off)?

Either the possibilities of this blueprint are gorgeous or the documentation is kinda complicated or it´s me not completely understanding how it works in the first place :smiley:
(Update: I believe a mix of all of that, but that blueprint is reaaaaaally powerful! :+1:)

Update: here we go, homeassistant.log. Does not like my “-1” so what other ways do you recommend?

Logger: homeassistant.components.automation.light_on_licht
Source: helpers/script.py:1138
Integration: Automatisierung ([documentation](https://www.home-assistant.io/integrations/automation), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+automation%22))
First occurred: 19:23:53 (2 occurrences)
Last logged: 19:44:56

Light ON_Licht: Choose at step 1: choice 2: Error rendering Light ON_Licht: Choose at step 1: choice 2 delay template: Time period should be positive

==> “Time period should be positive”…

I confirm the bug is fixed and automation is working as expected now. Thanks

1 Like

This blueprint is specifically for “turning something on once one entity is at given state, then automatically turn it off once it’s not at that state any more after X timeout”.

The timeout must be >= 0. If you want the light to stay on, just put a very large number there. e.g. “24:00:00”, meaning turn the light off after 24 hours (or until the sun rise, which will restart this automation). If you put any negative value, the automation will fail.

Based on your description, this blueprint may not be the best fit. What you need is two simple automation created manually. The first automation should be triggered by state change of “DECONZ DAYLIGHT SENSOR”, the target state should be sunset or whatever you like, action will be turning the light on. The second automation should be using similar trigger, with target state of “sun rise”, and the action will be turning the light off.

If you still prefer using this blueprint, you should use the built-in sun entity. Below is an example. You can tune the sun_elevation_below value to adjust actual light on time.

alias: Light on dusk to dawn
description: ''
use_blueprint:
  path: kevinxw/state_based_entity_control.yaml
  input:
    trigger_entity: sun.sun
    trigger_entity_state: below_horizon
    target_entity: light.your_light_id
    trigger_timeout: '24:00:00'
    sun_elevation_below: '0'

Right, this blueprint is not the perfect solution for my simple scenario, a usual automation does the trick.

FYI: I tried to set the timeout to 24:00:00 but the light was turned off anyway. And very strange: every time I tried to turn it on, it was immediately turned off again. So I think the automation will stay active until the timeout is reached (or HA has been restarted meanwhile I guess) so that´s just a mess.

Again, a simple automation is fine for my scenario. But there´ll be other scenarios where this blueprint will be just perfect, I´ll keep it :slight_smile:

That could be a bug. It shouldn’t turn off immediately.

Try this one:

alias: Light on dusk to dawn
description: ''
use_blueprint:
  path: kevinxw/state_based_entity_control.yaml
  input:
    trigger_entity: sun.sun
    trigger_entity_state: below_horizon
    target_entity: light.your_light_id
    trigger_timeout: '0'
    sun_elevation_below: '0'
    timeout_blocker_entity: sun.sun
    timeout_blocker_entity_state: above_horizon

Great blueprint. Thanks! It would also be very handy to be able to define more than one target entity.

Multiple target entity is not directly supported due to limitation of blueprint (I cannot add input fields dynamically).
But assuming your target entities share the same states, you can group them and use the group as target.
In my case, I have multiple light in my living room, so I just group them then let the automation turn on group.living_room_lights instead.

1 Like

I updated the blueprint and now it supports multiple states. You can import the new blueprint using this address https://github.com/kevinxw/homeassistant/blob/0c97e36c35838a3d7eaadda527b7a3ca04197420/blueprints/state_based_entity_control.yaml
Tell me how it works for you.

Edit: Please use the blueprint URL in the top post. This function has been merged there.

OK, here´s what I´d like to do (and this blueprint seems to be just perfect for it - it just doesn´t work):

1st) I want to use two to three of this blueprint automations to set a “room presence entity” to ON:

  • automation 1: motion triggered
  • automation 2: vibration triggered

Every automation shall set a input_boolean.room_presence to ON when being triggered and turn it OFF after a certain timeout.

2nd) I want to use the input_boolean.room_presence as trigger for turning things like lights etc. on afterwards.

That´s the plan. Here´s reality:

1) Feature request: It seems like trigger_timeout only accepts hard coded values (seconds). Is it possible to also accept entities? I´d like to use a helper entity “input_number.timeout”.

2) Bug report: I discovered a bug. Not sure where exactly, but: with your never blueprint version (after February 2nd) my automation only turns the target entity ON, but never OFF.
This is the log book of the target entity:
grafik
This is the automation:

alias: Presence_Room 1_Trigger Motion
description: Trigger Motion as Input for Presence Status
use_blueprint:
  path: kevinxw/state_based_entity_control.yaml
  input:
    trigger_entity: binary_sensor.motion1
    target_entity: input_boolean.presence_room1
    trigger_timeout: '10'
    target_entity_state: 'on'

When I used your version prior the update from February 2nd the target entity has been turned on and off with respecting a hard coded timeout.

I then saw your update and updated the blueprint. Since then the target entity never gets turned on. I think you might have introduced a bug with your release :frowning:

3) Feature request: Having the option to select multiple trigger entities (one motion, one vibration, maybe one door contact etc.) would greatly enhance the options. In my case it would reduce the amount of same automations to just one.

As I can continue using the old blueprint version, 2) is not a big issue for me.
Can you give an estimation if and when you are gonna implement feature requests (no. 1 and no. 3)?

that would be really great to see! :slight_smile:

Hey, I updated the blueprint several times after Feb 2nd, the latest version is at Feb 26. Sorry I didn’t post update on the forum since there was few replies. Try the latest one using the URL from main post, ideally there should be no problem.

trigger_timeout supports seconds and the official time format “HH:MM:SS”, thus it’s a “input_text”. If you adjust the domain it should work.

For multiple trigger entities, this blueprint supports it. I do not have vibration sensor, but I do have door contact sensors and motion sensors, and I do have an automation combining contact sensors and motion sensors. The trick is to create a group with these sensors. I am not very clear what the group’s status will be if you put a vibration sensor there, you can test it by checking the group’s state in developer tool. For group containing only contact sensors and motion sensors, the group’s status will be just on/off.

I have the following group in groups.yaml

garage_motion_door_sensors:
  name: Garage Sensors
  entities:
    - binary_sensor.motion_sensor_158d00020b8046
    - binary_sensor.motion_sensor_158d000116ca1c
    - binary_sensor.door_window_sensor_158d0001a2289f

And an automation like this:

alias: Garage Light
use_blueprint:
  path: kevinxw/state_based_entity_control.yaml
  input:
    trigger_entity: group.garage_motion_door_sensors
    target_entity: switch.garage_light
    illuminance_sensor: sensor.illumination_7811dcdc2cde
    illuminance_below: '450'
    trigger_timeout: '90'

It turns on light when any of these motion sensors detected something or the door is open, and turns off light when everything goes quiet.

1 Like

Hi Kevin

This is really cool and super-helpful!! I am trying to setup a variation - to make a decison on the sum of 3 values subtracted from another. I have tried to use a Helper but figured your blue print could be the solution.

I am on a remote island in the Bahamas and I have a solar array that have intergated as
sensor.power_solar_production_1_1min

And depending on how much power my kitchen and boats are using, I want to control how much power I send to my chargers. I have 1.8kW, 3.3kW and 6.kW that charge my 15kWh, 30kWh and 75kWh battery packs (all ex-Tesla Model S and 3 from crashes)
My chargers are all controlled through Shelly1 relays.

So I need to calculate

   sensor.power_solar_production_1_1min - sensor.power_kitchen_panel_consumption_6_1min - sensor.power_shore_power_1_7_1min - sensor.power_shore_power_2_8_1min

And then trigger the different charge relays

  switch.18kw_charger_relay
  switch.33kw_charger_relay
  switch.66kw_charger_relay

I realize this is a little nuts and unique - and to top it off I only started using HA three weeks ago so I am stumbling around like a drunken sailor. I don’t want to step on anyone’s toes with stupid questions (I likely have), so please forgive me if this is the completely wrong place to post this question!

Thanks
Wayne

Hey Wayne,
That sounds like an interesting project. However, it’s not a fit for this blueprint. This blueprint is only suitable for binary switches (on <-> off etc.). But I have another blueprint may be helpful to you. I use this blueprint to convert my 30 bucks heater to an air conditioner.

The blueprint is at: https://github.com/kevinxw/homeassistant/blob/61b5859dc866edd43da8f5e7cac244e9fbda00b0/blueprints/control_entity_using_sensor_with_numeric_states.yaml
Its concept is simple, when the temperature returned by a climate sensor is above certain value, it turns off the heater; when the temperature is below certain value, it turns on the heater. But the blueprint does not limit itself to heater. You can use it for any sensor that returns a numeric state. I also use it for adjust my humidifier.

From what I understand, you need to create a custom solar power sensor using template. You can find examples here: https://www.home-assistant.io/integrations/template/, you should put the equation you created above into its value_template, so you can rely on that sensor to output a number.

Then, use the blueprint I mentioned above to create 3 automations, which turns on/off your chargers based on the value returned by the sensor you defined above. e.g., when solar power sensor returns a value below 1800 (I suppose the sensor you created will return watt number), turns on switch.18kw_charger_relay, when it’s above 1805 (give some buffer, otherwise the switch may be flapping), turns off switch.18kw_charger_relay, then in the second automation, do the similar but with 3300 as threshold. Then in the third automation, use 6600 as threshold.

I will be interested to see it working.

Awesome - thanks Kevin. Will give it a shot. Hey, if you are ever around the Abaco’s, you are welcome to stop by - it is really beautiful and also a tech paradise. I have built everything myself - I believe I was the first person in the US to take an entire 75kWh Model 3 battery pack and turn it into solar storage. I “fooled” two Danfoss DLX inverters (4.4kW each) into seeing it as a 400V solar field :smile:

I am still very weak at HAss, but trying to get up to speed quickly.

1 Like