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
I have fixed the logic.
If you update the blueprint to the latest version, you can leave both luminance sensor and sun elevation blank.
The latest blueprint supports multiple trigger entities and target entities now. You can test it if you are still interested.
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.
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.
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…
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 
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 ?
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
To your last suggestion, last triggered doesn’t work for a few reasons:
- An automation is triggered doesn’t mean it will be executed eventually, given that not all conditions are met.
- 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.
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:
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:
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:
- 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.
- 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… 
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
Unfortunately my switch is a (ZigBee) remote with programmable buttons. There´s no physical switch or “light state” I can detect and use. So I´m going to live with my current workaround for a while.
But what about
? There´s a bug in the blueprint, isn´t it?
I don’t have Adaptive Lighting installed. But from the integration’s description, it’s not compatible with this blueprint. This blueprint monitors target entity’s state. So you are right, if other automation is changing the light’s brightness, this blueprint may not work. I will think about a solution if possible.
Regarding the original issue you mentioned, you can create a helper entity to mock the physical switch. Basically you need to create a input_boolean Input Boolean - Home Assistant, then use your zigbee remote to toggle this input_boolean. Then in the blueprint, use this as blocker_entity.
1 Like
Finally I understand what the blocker entities are made for 
Same result but automation can stay active. Works! I used
timeout_blocker_entity: input_boolean.light_manual
timeout_blocker_entity_state: 'on'
But I still don´t get it: what is the target_entity_state: '' ((Optional) Target Entity Desired State) for? Because it simply is NOT working as described in the blueprint:
→ That just don´t work. If it would work, I would not need to have the blocking entity. So I still believe something´s not working as intended/described/designed.
That would be awesome! Would reduce the complexity around the blueprint a lot (and I don´t think my usecase is that special, so others will benefit from such a solution too) 
I will think about a solution for this
1 Like
Sorry to bother you once again, but as I´m using this great blueprint more and more for different things in my home, I not only run into limitations or discover bugs but also imagine optimizations/feature enhancements, some by little to no cost. Here´s one:
Could you add the option to support (select/enter/use) multiple illuminance sensors?
I already experimented with a group but illuminance sensors are not supported according to domain list at Group - Home Assistant and therefore group value was “unknown”. And a second automation is neither smart nor trouble-free. So:
I have a valid use case for this and you have already implemented the basic feature for other parts of the blueprint, e. g. (OPTIONAL) Alternate Trigger Timeout. This could look like…
A) …when keeping the current structure:
-
(Optional) Illuminance Sensor: sensor.illuminance1,sensor.illuminance2 -
(Optional) Illuminance Below: value1,value2
B) …after merging (Optional) Illuminance Sensor and (Optional) Illuminance Below to one field (like already done with (OPTIONAL) Alternate Trigger Timeout):
- sensor.illuminance1,value1;sensor.illuminance2,value2
→ The automation should work, if ANY of the listed illuminance sensors provided is below the corresponding value (sensor.illuminance1 below value1, sensor.illuminance2 below value2 and so on). 
I´d be happy to test that!
You could also make a template sensor to combine your sensors by picking the one with the lowest value.
Nice 
But a) every sensor has its own cutoff value so just going for the lower one is not sufficient and b) why not have it in the blueprint so more people can use it (much more handy without templating and stuff) 
Gotcha, but I didn’t say it shouldn’t be added. I was offering an alternative (albeit a bit different). I understand your main use case and it seems entirely valid. 
You also mentioned groups and to me it seems the only way groups could work is if there is some rule to combine/fuse sensors (min, max, avg) — should the HA team see a need to implement such a feature for groups. I was thinking about this when I made my previous post.