Hey there. I have fairly limited knowledge, but trying to get this to turn on/off a switch located in a bedroom when a group of other switches turn on/off. It used to work in an older version of HA, but i think something has changed, not sure what. I have updated to latest blueprint.
which version of homeassistant are you using?
I am using my blueprint with the latest homeassistant with no problem
Awesome thanks for the reponse Kevin. This hasn’t been working for a good six months. Current HA version installed 2023.2.2. Could it be something wrong with the groups? The automation always turns the switch on when a another switch is turned on, but whereas it used to also turn the switch off, now the switch just stays on??
Stopped working with the old blueprint on an updated HA, just updated blueprint but still the same behaviour. This is the current test where switch.ah1 (is a switch group created in devices, Helpers Group, Switch group) and switch.2
id: ‘1683345131402’
alias: ah1
description: ‘’
use_blueprint:
path: kevinxw/state_based_entity_control.yaml
input:
trigger_entity: switch.ah1
target_entity: switch.2
trigger_entity_state_off: ‘On’
target_entity_state: Trigger Entity States
Could someone that has successfully used the trigger timeout provide any pointers to me, I can’t seem to use an input text helper to work at all.
In case anyone reads this, for me the blueprint did not accept an input text helper in the Trigger Timeout field (even though the dropdown menu implies that it should) and it only accepted hard coded text in this field in the automation.
For my own use case I edited the blueprint and reconfigured the Trigger Timeout to accept an input number helper and it’s now working for me.
This blueprint really is my “all in one” weapon for many things meanwhile, mostly light automations. Unfortunately, I can not implement this use-case:
-
Trigger entity(motion sensor) is at desired state
-
(Optional) Illuminance Belowis also true
→ it got dark meanwhile, while people still constantly trigger the trigger entity which stays on)
Unfortunately, the target entity (light) stays off, as the decrease of illuminance is not discovered as trigger.
Using a dumb switch or living with annoyed people is not a (smart) option.
Any smart way to work around that? I want to solve this within one automation (ideally by being able to use the illuminance sensor as second trigger, but based on a range of values instead of a fixed on/off state), based on this blueprint.
I tried to set both the motion sensor and illuminance sensor as trigger entity (trigger_entity: binary_sensor.motion|sensor.illuminance) and use trigger_entity_state: true|5|4|3|2|1|0 - which gave an error and rendered the whole automation faulty.
Can you try put trigger_entity: binary_sensor.motion,sensor.illuminance instead? i.e. replace | with ,
Well, while syntactically correct (in a way which does not force the automation to render faulty), the automation immediately stops working with
trigger_entity: binary_sensor.motion,sensor.illuminance
trigger_entity_state: on|5|4|3|2|1|0
# Also tried the syntax of the next line alternatively to the pipes above
trigger_entity_state: on,5,4,3,2,1,0
Light now stays off even when motion sensor is triggered (same when illuminance sensor triggers). Automation fails. Automation debug section gives
So:
- doesn’t work. Don’t know why, would need a bit of automation debug skills (“template condition”)
- Even if it would work, the automation is triggered very very often (like it did already during the tests above) - as every illuminance sensor change triggers the automation. A “normal” hand-made automation would only trigger if also the appropriate brightness has been reached, e. g. with
trigger:
- platform: numeric_state
entity_id: sensor.illuminance
below: 6
I am very sure both things can be fixed by changing the blueprint itself. If another non-binary trigger entity (“secondary_trigger”) is set, the automation trigger needs to be combined with the numeric_value (threshold). That would really supercharge this automation.
Any other thing I can test to help this blueprint support this scenario?
I may got some time to work this. But I need to think through how to do things properly.
In the last a few versions HA has supported allowing us to specify multiple condition as blueprint parameters, which means we do not need to have this trigger_entity and trigger_entity_state thing. It’s much more flexible to allow users to specify multiple triggers, e.g. trigger by motion and illuminance as you have suggested.
However, this kind of flexibility also means more user inputs are required (users have to specify the whole conditions block vs users only need to input the entity name today). So I need to figure out how to keep the blueprint concise as well.
I will update in this post once I made some progress.
1 Like
Thank you very much for the update. That’s great news basically. 
Maybe it doesn’t need to stay concise - what about a plan B - having an “expert switch” or “advanced mode” or sth. like that. That way once updated the blueprint would work as before for all existing users and those wanting to take advantage of the new features can simply do so.
Anyway that’s “just” the frontend thing, for me it’s crucial it is working in the backend. Being able to continue using this “one for all weapon tool” blueprint 
for most of my automation use cases instead of going back doing everything manually because the blueprint can’t handle things (like multiple triggers).
Is it possible to use an attribute value of another entity as the Blocking and/or Timeout Blocking entity/state? In my case my I am hoping to use the “current” attribute of another automation; which has a value of either 1 if the automation is currently running or 0 if the automation is not currently running.
I’ve been using many automations based on this blueprint in a dual trigger type setup to auto control lights for many months now. To do this I used the previous suggestion of combining the state of both a door sensor and a motion sensor into a input text helper and this mostly works well, however my zwave door sensors tend to just die while still reporting to zwavejs that they are asleep and have 100% battery. This results in the false values of the door sensor going into my input text helper (like the door being closed when really it is open) and causes my lights to turn off prematurely while the room is still occupied.
My thought here is if I have two separate automations for door and motion to control the light, but have the automations not step on each other based on one or the other already running. Also open to other suggestions if there is a better approach I am not thinking of. Thanks!
Any update on this @kevinxw ?
Here’s the original post:
Now in winter time this issue becomes even more tricky with lights not turning on… 
I really really really don’t want to migrate away from this great blueprint, doing everything manually would be such a pain (2nd trigger: illuminance).
I am still working on it, unfortunately I got very limited time recently. I have a prototype, but I am still verifying it.
1 Like
I am working on a version with more flexible conditions, that may be helpful to you.
Thank you. Do you need some help in testing? Please let me know if I can support you in any way.
Supporting entities instead of / in addition to fixed numbers
This bug seems to be unsolved until today:
…and a workaround (confirmed working):
==> Can the blueprint (template evaluation part) not just take care of this out of the box?
Because when applying the workaround (YAML mode)…
illuminance_below: "{{ states('input_number.light_abc_threshold') | int }}"
the UI only gives this, which is way to dangerous once one forgets about that templating hack and overrides stuff using the UI this way (accidentally breaking an automation):
Original full question
A completely other question - one I’m not sure someone talked about in this 123 posts long thread already:
I was trying to use an input_number entity for (Optional) Illuminance Below. That did not work (light stayed off). Once I put in a fixed number again, the automation works again.
→ Do fields like (Optional) Illuminance Below support entities?
The blueprint itself seems to want a number in the first place:
illuminance_below:
...
default:
selector:
number:
where e. g. the (Optional) Illuminance Sensor accepts (and works perfectly) with entities:
illuminance_sensor:
...
default:
selector:
entity:
Would it work if I change the selector from number to entity? Or is this just for the UI and the functional magic is done in the complex template part?
→ Answered by myself: I was/am still using a blueprint version from 2021-04-02, where this is used - and it doesn’t work…
illuminance_below:
...
default:
selector:
entity:
domain: input_number
So you actually removed that in newer versions of the blueprint… how can one use an input_number entity for this?
Use-case:
I have a use-case where the value of that (Optional) Illuminance Below changes based on physical circumstances. The value of my input_number helper entity is automatically and dynamically adjusted, so it would be perfect for the blueprint to simply use that (instead of me needing to change that value in the automation manually).
Hello,
I have the following in mind:
My fan is supposed to come on at 8:30 a.m. When a window is opened, the fan is supposed to go off and come on again when it is closed. But all of this only happens when I’m at home. The fan should then turn off again at 5:30 p.m. until the next day.
Anyone have an idea how I can do this with the blueprint?
Thank you very much
Hi again @kevinxw , another half year has passed.
Are you able to finally implement this?
No response at all for such a long time strongly indicates this great blueprint is unmaintained / dead.