How to prevent automation looping/repeating?

Configuration
1

ok, so I’m not sure if it is a real danger, but got me curious, and I want to ask before I’ll lock my installation in the loop [if it is possible ;)].

imagine a scenario:

  1. input_select with light scenes.
  2. automation triggered by time - at specific time conditions turn on specific scene & set the input_select accordingly [for user’s information etc.]
  3. automation triggered by input_select change, so if I choose a scene by hand - it is turned on.

and now, the question:
is it possible, that when time trigger starts and sets the scene & input_select value (2) the input_select-change trigger will start and will try to set the scene again (3)?

given example is simple 3-point simple situation, but I guess I might encounter more complex, when I’ll start to expand it, that’s why I’m asking at the beginning :wink:

2

If your input_select change triggers the scene, why not just have your automation do that, rather than do that AND trigger the scene itself?

3

hmm, good point!
but I had something similar to that - input_boolean with a “tv mode” setting [this mode dims few bulbs, turns off few leds etc], and noticed that not always switching on this boolean by automation, triggers the action. when I switch it by hand - it works, but when switched via automation’s action - sometimes it fails [don’t know why, no issues in the log, I’ve just made peace with that and didn’t bother :wink: but tried not to use this kind of automations].

besides that, I always thought it is better to do something directly - thinking about the shortest way which then minimizes any problems. I guess it doesn’t matter as much if I make the automation that triggers another automation etc.? what’s your experience/thought on that? should I consider making it shorter way, or just chain few automations and don’t overthink?

4

Well, I don’t use this element much if at all, but the following is my thought:

Either a state change event is generated when an automation sets the input_select value, or it isn’t. Depending on which behavior it is, you know whether to just trigger the change in selection, or to do both actions.

If it sometimes is triggered, that’s a bug that should be reported on github.

5

thanks for the answer.
…looks like the question which method is better remains open I guess… :wink:

and right, if I only notice that I can reproduce the situation when the trigger occurs/don’t start when it should - I’ll report. right now I don’t want to start “well, something somewhere doesn’t work” issue [it is possible that the problem was caused by my installation/config/hardware], but anyway, it is OT right now.

6

The docs are ambiguous on this (whether state changes are triggered by programmatic setting of the value).

You should just try it and see. Then there is no question left about “better”. Only one way makes sense, or there is a bug in HA.

A state change should be independent of what caused it. But no guarantees that this is how it should be.

7

What if you have automation 1 that watches the input_select to trigger the scene (state trigger), and automation 2 that sets the input_select at a specific time? Then the input_select would always reflect the most recent scene selected, but eliminate the risk of the looping. Automation 2 would change the input_select, which automation 1 would notice and set the scene.

8

if I understand correctly - @anderson110 wrote just the same thing in the first comment, am I right? :slight_smile:

so looks like it is the way to go if two out of three thought about that :wink:

9

Yes. I just didn’t read closely!

10

Just have the input_boolean have a condition when you turn it on. The condition would check the state of the scene. If the scene is on, don’t turn the scene on. That way, the input_boolean is now on and matches the state without it turning on the scene. If the scene is off, it will turn on the scene.

example:

- alias:
  trigger:
    - platform: state
      entity_id: input_boolean.input1
  condition:
    - condition: template
      value_template: "{{ if is_state('scene.scene1', 'off' }}"
  action:
    - service: scene.turn_on
      entity_id: scene.scene1

The only way this boolean will actually turn on the scene is if the scene is off. So if you have an automation that turns on the scene before hand, hitting this switch will do nothing.

11

but doesn’t that mean, that I’ll need to prepare booleans for all scenes?
maybe I’m wrong with my way of think from the beginning, but I try to minimize unnecessary booleans, switches and all the rest - just to have “clean and simple” configuration files [which are easier to polish/edit later I guess].

anyway - that condition and action combination you wrote, will be helpful in other situation, so thanks nonetheless :slight_smile:

12

Yeah, you’ll have lots of booleans…

I just realized you said input_select. That code would be very similar. Except you would build an or condition to handle all of your input_selects:

- alias:
  trigger:
    - platform: state
      entity_id: input_select.input1
  condition:
      condition: or
      conditions:
        - condition: template
          value_template: "{{ if is_state('scene.scene1', 'off' and is_state('input_select.input1','selection1') }}"
        - condition: template
          value_template: "{{ if is_state('scene.scene2', 'off' and is_state('input_select.input1','selection2') }}"
  action:
    - service: scene.turn_on
      entity_id: >
        {% if is_state("input_select.input1', 'selection1') %}
          {{ 'scene.scene2' }}
        {% elif ..... etc %}
13

ok, two things:

  1. I’m going the way @anderson110 and later @Dolores wrote - long story short: when scene is turned on, the input_select will keep active scenes’ name. time-trigerred [not only, but let’s simplify] automation1 won’t turn on the scene - it only sets the option in input_select, and then automation2 [with data_templated action] will set active scene according to input_select’s chosen option - and this automation2 will be triggered by input_select’s change. so now I guess that your conditions are unnecessary? I guess that if input_select current value is “selection1” and trigerred automation1 sets [tries to set] it’s value as “selection1” - it isn’t considered as “value change” so it won’t trigger automation2, right?
  2. about templating in action - is this format: {{ ‘scene.scene2’ }} necessary? or I can write just scene.scene2? [I’m rewriting all automations, so didn’t tested it yet ;)]
14

  1. I would assume so, but don’t be so sure! You should check the hass.log while in debug and watch the events that appear.

  2. Honestly, I was writing that off the top of my head. {{}} may not be required. I know that they are not needed for integers, floats, strings, and booleans. Now that I think about it, I think you are correct. No quotes, no brackets.

15
  1. sure will keep my eye on that. if something fails, I’ll add conditions you’ve mention and it should be good :slight_smile:
  2. I’m still not-too-fluent in jinja2 templating or yaml itself anyway [right now I think yaml isn’t a best choice], so being correct sounds like a surprise for me :smiley:
1 Like
16

Take a look at the first post in this thread. It has a great example of templating with input selects.

17

jumping a bit late on the wagon, but if you’re worried that changing the option on your input_select keeps calling the same automation you could always add a condition so the automation doesn’t run if it already ran in the last [say] 5 sec?

    - condition: template
      value_template: '{{ (as_timestamp(now()) - as_timestamp(states.automation.[automation name].attributes.last_triggered | default(0)) | int > 5)}}'
1 Like
18

haha, yeah, I was using similar post as a reference - config was shorter, but also about choosing radios etc. :wink: thanks :slight_smile:

19

thanks, that method sure will be helpful with other ideas :slight_smile: good to know.