Hi Kevin, I like what I see in your script here. I’m trying to figure out if I can tweak/modify it for use in such a manner as described below. If you know how to quickly tweak/support I’d greatly appreciate it.
Instead of motion sense triggering (since I don’t have motion sensors yet) I’d like just have the light switches trigger automation (e.g. light switch pressed once it will timeout after blueprint instantiation timeout or alternate timeouts during times of the day).
If the light switch is pressed on, then off, and back on within 3 seconds then I’d like to override the normal light off timeout with a different value (or no timeout)
I noticed your blueprint currently has a 3 second trigger that would probably need changed for #2 to work. Also, I tried making the light switch the trigger and the target and it didn’t seem to work for #1. Perhaps I need some other options in the blueprint for the light to turn off automatically after a timeout?
You can put anything into trigger. A motion sensor is just an entity which will turn itself off after it was on for some time.
Thus, you can create a helper entity to simulate a motion sensor. Just create a toggle entity in helper, then create an automation which will be triggered by the light state. In the condition, when the light state is changed to “on” (make sure the trigger is empty so that you know it’s not turned on by another automation), set the helper’s state to “on”, then set a delay, then set the state to “off”.
Now you can fill the helper entity to trigger. You can do the similar thing for your second requirement: create a helper, then create an automation to set this helper’s state based on your desired actions. Then fill this helper to the block entity of my automation.
Hi I seem to be having issues with the Trigger Timeout where I’m using an input text helper and I’ve tried entering 00:00:30 but the lights are not turning off after the timeout has elapsed. If I manually enter 30 or 00:00:30 in the automation it works fine.
Looking at the trace for the unsuccessful execution I see the following message:
error: offset input_text.trigger_timeout should be format ‘HH:MM’, ‘HH:MM:SS’ or ‘HH:MM:SS.F’
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.
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
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 Below is 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.
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
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
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.
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!
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).