I have an automation (blueprint actually) that I want to do the following in: When triggered by a specific event, it should start a loop that repeats a certain action over and over until another specific trigger is received. I think I know how to achieve this if I put the loop in a separate script and use script.turn_on, and wait for trigger but I would like to keep the blueprint contained in a single file to make it easier for users.
There's a mention in the documentation that scripts can be embedded in automations but I didn't see any other information about that
#stopping a loop on a trigger within an automation
next niche
Oh, and some additional info: I want this blueprint automation to run in 'queued' mode, so using the 'restart' mode of the automation to achieve breaking off the loop is not an option I would like to use
cold lion
can you not use repeat until CONDITION?
if not then (probably better ways but without knowing the use case its hard to tell) you could use a parallel block and inside:
--you have your repeat action
--and then separately but running in parallel have a wait for trigger which when triggered stops the automation
maybe if you can tell more about the use case can give some ideas.
next niche
With the repeat until, how would the automation know the trigger has fired somewhere during the last loop execution? The parallel thing could work, but it should not stop the whole automation because some stuff needs to be done after the loop is finished
cold lion
what is the trigger?
next niche
The use case is a blueprint for a 5 button Zigbee remote, which also sends events on long presses of the buttons. It sends one ZHA event on press, and one ZHA event on release, those are the triggers. I want to repeat small increases/decreases of brightness and color temperature of lights when the button is being held
cold lion
so on long press event you want to increase/decrease until the button release event fires?
next niche
Yes. With some max nr of repeats to prevent infinite loops if the release event is somehow missed of course
If I put a wait for trigger in parallel with increase action inside the loop, and issue a break command in the parallel part, would that work?
cold lion
a stop stops the whole automation. if you have stuff you need to do after it then it wont run
next niche
There's no break for for loops then? There's something about that in the template documentation but I guess that is only about for loops within a template?
cold lion
you could make a switch helper
when long press event happens it switches it on and when release happens it switches it off
if its on for x seconds it turns it off
then "until switch is off" increase sleep 200ms or something
next niche
If I set a variable release has triggered to true in a parellel loop like I describe above, and use that in a condition inside the loop, does that work with the scope of the variables?
cold lion
that i dont know. I havent used variables that much in automations. I have done state machines that store a state but i do that in a helper
next niche
you could make a switch helper
when long press event happens it switches it on a...
I thought about helpers indeed. I already need one text helper to store the color state of the light, having to make another one is a bit annoying but possible. Is it possible to create helpers from within a blueprint? I would prefer for users to set it up completely from within one file. Each helper means one extra action to make the helper and one extra input in the blueprint, which are two more ways a user can make mistakes.
cold lion
i think its possible yeah. i am pretty sure i have seen a blueprint generate one before but its not something i do on the regular
next niche
Oh, that woudl be cool. Maybe it's for a different thread though
I'll try out the parallel variable trick and see if it works. Thanks for your time!
cold lion
no worries. good luck with it
next niche
I tried a wait for trigger parallel to a repeat-until loop, but as expected, the two parallel loops' evaluations/setting of a variable don't see each other.
next niche
I made it work in the end, using a helper. Key realization was that I could simply use the same helper I already use in other parts of the automation, that run on different triggers. Since the value of the helper is stored in a variable on trigger, I can simply restore it for future use without having to resort to letting users create a ton of helpers.
sequence:
- parallel:
- repeat:
sequence:
- action: light.turn_on
data:
brightness_step_pct: "{{0.25 * col_updown_percentage|float}}"
target:
entity_id: !input light_target
- delay:
milliseconds: 125
until: "{{repeat.index >= 40 or states(input_helper) == 'release_has_triggered' }}"
- sequence:
- wait_for_trigger:
- trigger: event
event_type: zha_event
event_data:
device_id: !input remote_device_id
command: stop
timeout:
seconds: 5
- action: input_text.set_value
target:
entity_id: !input input_helper
data:
value: 'release_has_triggered'
- action: input_text.set_value
target:
entity_id: !input input_helper
data:
value: "{{last_leftright_value}}" ```That's the code I used in the end. It repeatedly increases brightness, every 125 ms, with a quarter of the step you would use for a single press. In parallel, it listens for the release event ('stop'). If that is found, it sets the input helper, which is read every iteration in the 'until' condition.