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)

Blueprints Exchange
, ,
21

Bug in newer versions:
Nope, does not work with latest version. Needed do go back to the old one. Seems like there´s a bug introduced in any newer version. I don´t care a lot currently, still working on tuning the old one to fulfill all requirements.

Multiple trigger entities:
That´s a workaround you use. Can you update the blueprint to simply allow multiple trigger entities? I know how to basically do this in an automation, but no idea how to adjust your blueprint… :frowning:

Your workaround using group entity has a big downside: what if you want to control more than “just” your garage light? Adding another group entity combining all target entities? Setting up a scene? That´s just too much group entity creation considered that an automation is capable of handling the same. Would really love to see this in your blueprint! :slight_smile:

So the main difference is:

  • you use this blueprint for ACTION - to do something based on presence (indicated by a presence group)
  • i use this blueprint for DETECTION - (one to get information from motion sensor, one from vibration sensor - makes 2 automations) to set a presence helper entity, which triggers a separate manual automation doing different things (more than only switching light on)

By being able to select multiple trigger entities this blueprint would not only fit my purpose, it would also allow a much broader usage of it. Ultimate solution would be to being able to set multiple trigger as well as multiple target entities.

What do you think?

22

OK forget about it, I changed my whole logic and I´m using a group of trigger entities too now.

What I really miss now to replace all my automations based on freakshock88´s blueprint is something he seems to have added after you forked it: a time range condition:

grafik

That´s really the only thing I miss. Can you add this to your blueprint? I really like the broader approach. Time range condition really is the only thing left compared to the original :slight_smile:

23

Regarding the bug, what exactly is not working?

Multiple trigger entities will not be supported due to the limitation of a blueprint. It only support fixed number of trigger entities. Group is the way to go. If you want to turn on/off multiple entities, create a group for that as well. Everything in that group will be turned on/off.

24

Yeah as mentioned I got that and changed my whole setup alreay :slight_smile: Last two cents:

  1. I´ve seen another blueprint where using several entities with as special syntax (don´t remember, either “entity1,entity2” or “entity1|entity2” was used, so it is possible.
  2. If one of that actions to be applied to a group of target entities is not just on/off but e. g. “set temperature to XX °” the group entity thing comes to an end quite quickly. BUT as this blueprint is quite general, one could use a script instead which takes care of such extra tasks.

See 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) - #16 by e-raser that´s what I experienced, but I´ll update and test again. As it seems to work for other users, it might be a me specific issue.

@kevinxw: What about 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) - #22 by e-raser ?

25

I have pushed an update to my blueprint. You can reimport it now. It adds a field letting you specify Execution Time Ranges

26

If you can show me the link of the blueprint that supports multiple trigger entity, I can probably support that as well.

My automations are running fine with the latest version for 1+ months now. I will be happy to debug if you can provide more details (logs and automation yaml etc.)

27

Finally I could update to the latest blueprint version and test it. Summary:

  • runs fine without any issues so far
  • could not test the Execution Time Ranges yet (as I added illuminance sensors meanwhile I tend to not use them for now, but there will be situations I´ll have to rely on time instead of illuminance so it´s great to have this option!)
  • really love the updated Alternate Trigger Timeout syntax, very powerful and easy to use

So far: really love that blueprint. Outperforms all similar I´ve seen here and tested (some for weeks) because I like having all configuration in the automation. Other blueprint authors tend to select entities which bloats the user interface or at least you need to create many helper entities.

Regarding

I can say it wasn´t a blueprint I´ve seen, instead it was a regular syntax in a normal automation (trigger section):
grafik

I´m happy so far and will test the updated blueprint for some while. Thank you so much!

28

I didn’t know home assistant accept this format. It seems very straightforward. I will support multi-entity trigger later.

29

It looks like the automation does not work without any conditions.
For one instance of blueprint I need just a simple motion sensor trigger → light on.
If I add sun elevation parameter the light starts triggering, but without any additional parameters it does nothing

30

I have fixed the logic.
If you update the blueprint to the latest version, you can leave both luminance sensor and sun elevation blank.

31

The latest blueprint supports multiple trigger entities and target entities now. You can test it if you are still interested.

32

I could not test it yet, but thanks in advance!

Meanwhile I encountered a daily issue in using this blueprint. I‘m curious to see if someone smart has an idea on how to fix this:

I use this blueprint to have a motion sensor turning on a light in a room, leaving it on for some time and turning it off. For this my automation looks like:


use_blueprint:
    path: kevinxw/state_based_entity_control.yaml
    input:
      trigger_entity: binary_sensor.motion
      target_entity: light.lamp
      illuminance_sensor: sensor.illuminance
      illuminance_below: '65'
      trigger_timeout: '90'

Works just perfect. BUT: I have an additional switch for manually controlling the light. Sometimes I get in the room - automation turns light on and off after a while. Without triggering the motion sensor again, I turn the light on manually using the switch because sometimes I need the light for a part of the room (where motion sensor is monitoring, that’s desired).

Expected behavior:
light is turned on and stays on.

Actual behavior because somehow this automation is being triggered:
Light turns on BUT ALSO AUTOMATICALLY OFF after the time set in the automation. This also happens when switching the light on using Home Assistant (Lovelace GUI). Motion sensor never is being triggered.

Is this what the blocking entity is made for? How can I adjust this automation so that if the light is being turned on manually (using the switch) it is not being turned off?

In other words: why is the state of my TARGET entity being used for triggering the automation? I only want the automation to trigger when the TRIGGER entity changes state. Bug? Please assist.

33

This is expected. It’s kind of a feature. I want the light to be automatically off even when I manually turned on the light.
If you want to ignore target entity’s state, set “target_entity_state” to empty string.

I wanted to implement the feature that when a person manually turn on the light, leave the light on. However, there is a limitation which I currently do not have any solution. Home assistant doesn’t tell me the source of event when a light is turned on, i.e, I cannot tell if it’s turned on by someone physically touching the switch or if it’s turned on by another automation.

34

I concur with what Kevin said but you do have some options if you are keen for a more manual setup.

I have e.g. a front door light that turns on automatically when someone gets home. It also has a manual switch. When the first automation fires (getting home), it separately starts a timer. When that timer expires, there’s a second automation to turn off that light. This timer won’t start when the light is turned on manually (because there’s no automation on that state change). You’re problem is, of course, that you could forget to turn off that light (generally, maybe not in your case). For that you can have yet another automation to notify you if the light is still on after some time. And so forth…

35

I did for all my automations, but it didn´t change anything unfortunately. Automation still gets triggered and turns off the light, even when I turned it on manually before.

Update: GUI has some issues, why removing the “on” value has not been saved as expected. I had to manually edit in YAML mode. Is this the right value (no value at all)? The help text talks about ‘none’ as value :slightly_smiling_face:

target_entity_state: ''

@parautenbach: That would of course be a solution, a quite smart one. BUT also pretty oldschool, cause creating various automations for controlling e. g. one light is a path I´m coming from. I want everything in ONE automation, which is why I think this blueprint is just perfect for.

I´m still looking for a solution to have my lights NOT turned OFF when I switched them on manually (not by motion sensor used as trigger entity in this blueprint based automation) - by only using this single blueprint automation.

Just an idea: can´t you check the last_triggered time of the blueprint automation? This way you still don´t know why/which way e. g. the light has been turned on, but you know it wasn´t the automation. Should be enough piece of information to make some progress if I don´t miss or mix up something important here - what you think @kevinxw ?

36

Yes, you will have to put it via text editor. GUI will set empty value to default value, which is ‘on’.

Let me know if it works

37

To your last suggestion, last triggered doesn’t work for a few reasons:

  1. An automation is triggered doesn’t mean it will be executed eventually, given that not all conditions are met.
  2. To check last_triggered attribute, you will need to select the automation’s id in the blueprint. Then you will have chick and egg problem.
38

It worked, so there´s ‘’ instead of ‘on’ now for target_entity_state.

BUT the desired effect is not there, in fact the following stated in the description text is just not true based on what I see with all my automations based on this blueprint:
grafik

This is especially a problem because in another room freshly equipped with motion sensor, dimmable bulb and an automation based on this blueprint, the “Adaptive Lighting” integration changes the bulbs brightness every few minutes (within the “(Optional) Trigger Timeout.” value). This leads to the automation being triggered over and over again, starting the timer for turning the target entity off again and again so - kinda deadlock - the light never is being turned off:
grafik

39

Alright, I see. So what would you recommend instead to have my target entities not being turned OFF when they have been turned on manually (e. g. by a physical switch)?

Anything smarter (included in your blueprint) than what parautenbach proposed here?

I only have an idea with many downsides, working around the whole blueprint/automation:
I could simply disable the automation when turning my target entity on with my local hardware switch (switch can use several actions per button event, could look like: 1st turn off automation so light stays on, 2nd turn light on). BUT:

  1. That would only work for this single switch. When turning the light on using e. g. Home Assistant GUI it will be turned off again by the automation.
  2. The switch control will become a bit more complicated (currently I´m toggling the light, so I would need to add something like “if light is off, turn automation off and light on” and “if light is on, turn light off and automation on”.

I implemented that workaround for now for one single room, but I don´t like that own idea… :frowning:

40

I cannot think of anything neat. If you have any second switch other than the light switch itself then it will be easier.
You can just put it in the block entity of existing blueprint, then create an automation which use second switch to turn on/off the light