"if-then" vs "Choose" = "Choose" wins

Hi!

I wanted to share this experience with you all, maybe someone have a good explication, but anyway, seems that in this situation, “Choose” wins.

I have an automation which have multiple “if-then” lines, all are similar, for every device, but when I get an error into one “if-then” the automation won’t continue to the next “if-then”, instead it will break the automation.

The line which breaks the automation is this:

  - if:
      - condition: state
        entity_id: variable.computer2
        state: 'on'
    then:
      - choose:
          - conditions:
              - condition: trigger
                id: mute
            sequence:
              - service: notify.eventghost2
                data:
                  message: Computer2 Mute
          - conditions:
              - condition: trigger
                id: unmute
            sequence:
              - service: notify.eventghost2
                data:
                  message: Computer2 UnMute
        default: []

It will break the automation because my secondary computer, it is not really on, it is off and the notify.eventghost2 will get an error when the service will trigger (Failed to call service notify.eventghost2. Unknown error). Because of this, the automation will not continue to the next “if-then”.

In the other hand, “Choose” will do exactly what it should, does not matter if there is an error on the first “Choose” it will continue to the next one, no matter what. The automation will not break.
Similar to the “if-then”, but using “Choose”:

  - choose:
      - conditions:
          - condition: state
            entity_id: variable.computer2
            state: 'on'
        sequence:
          - choose:
              - conditions:
                  - condition: trigger
                    id: mute
                sequence:
                  - service: notify.eventghost2
                    data:
                      message: Computer2 Mute
              - conditions:
                  - condition: trigger
                    id: unmute
                sequence:
                  - service: notify.eventghost2
                    data:
                      message: Computer2 UnMute
            default: []
    default: []

The conclusion: If someone does not know why the automation breaks when using “if-then”, think about “Choose”…

I don’t know if this is the real purpose of “if-then”, I didn’t read the exact documenation, but if is not, seem that this is a bug…

Is that really an entity? If you are using script variables, I would expect something like {{ computer2 }}.

I’m guessing the condition is broken, and if so, wouldn’t you want to know about it instead of silently failing? Then you can either fix the condition so it does what you need or remove it altogether.

The condition it is ok, and yes, variable.computer2 it is an enity, am using hass-variables.
As far as I tested, the only problem is that I get error when I send a notification to eventghost2 with the computer off.

If the computer2 it is on, then the automation it is working good, if is off, not anymore :smiley: But anyway… with “Choose” everything is ok, with “if-then”… nope

If I put this sequence to the end of the automation, everything is ok, because if there is any error in “if-then”, it will be the last condition, which can break, because there is nothing after

I think I still prefer the if behavior, and that the choose behavior is wrong. Scripts should not continue on an error. If you want a script to continue on error, you should normally do it in a parallel execution script. That is what I got from the documentation.

I believe if you put the notification separate (not in an if or choose) the actions below it will also not be executed.

I think I misunderstood what you wrote but now it’s clearer to me (I think).

You’re saying that continue_on_error appears to be false for the if-then (which is actually the default behavior for actions) but true for choose.

Well, I just did that and without notification, the automation will not break… Seems that because of the error of the notification, the automation it is not complete…

I don’t agree with you. Even if there is an error into a sequence, the automation should pass that and go the the next one. Does not have anything to do with the entire automation, the error it is inside the sequence of a “if-then” action. Like @123 said, every action should have “continue_on_error”, this is a normal behavior. Ok, I can agree that the specific action could break, ok, it is normal, but not the entire automation…

Yes, this is what I want to say. For me, at least, with this automation… If I don’t get any error in the “if-then” condition, everything is ok… I have replaced the eventghost notification with a normal persistent notification and everything is running ok. More than that, without any changes, if my secondary computer is on, the automation works good… These things makes me think about a “bug”… Maybe I’m wrong, maybe there is another issue and I don’t know, but as far as this automation, this was my result…

Look how the automation stops after the problematic “if-then” sequence. No other trace


And then, look at this one… All are true, but the only problem is that the Notify to Eventghost, will receive an error, because the computer it is not exactly on, I just fake it to be on… Anyway, this is what I think, because ot the Notify error, the automation it is breaking. I repeat, maybe I’m wrong, but still, why with “Choose” it is working and with “if-then” it is not?

1 Like

Not by my reading of the docs: Script Syntax - Home Assistant (home-assistant.io)

Per the docs, I would consider the “choose” behavior a bug. It may be intentional, or just something around for so long the devs don’t want to break things. The HA devs are not particularly reticent about breaking things for consistency.

Whichever is deemed correct, it should be consistent between both.

1 Like

As explained in my previous post, the default behavior when an action fails is to stop execution (continue_on_error: false is the default). The if-then’ sequence respects this rule. If you want it to continue executing actions then you must explicitly add continue_on_error: true to the action that may fail.

Based on the results of your experiments, it’s the choose that appears to be an exception to the rule. Execution didn’t stop after one of the choose’s options resulted in a failure. It’s behaving as if continue_on_error: true even though that statement wasn’t explicitly included in the automation. :thinking:

I can’t say for sure if that’s a bug but it does make it inconsistent with how if-then behaves. I know that the continue_on_error feature and ‘if-then’ and ‘for_each’ were all implemented well after choose (i.e. they appeared in 2022.5.0). I agree with jerrm’s theory that the developers may have left choose’s behavior untouched in order to avoid a breaking change … or they simply overlooked it and didn’t realize it doesn’t conform to the default continue_on_error: false behavior. :man_shrugging:

Oh, now I understand… so… this is exactly the opposite as I thought. The default is false and you can add true to the continue_on_error.

Can you please tell me where exactly I should insert this into my code? I only get errors…

I done it like this but still, the same behavior

if:
  - condition: state
    entity_id: variable.computer2
    state: 'on'
then:
  - choose:
      - conditions:
          - condition: trigger
            id: mute
        sequence:
          - service: notify.eventghost2
            data:
              message: Computer2 Mute
            continue_on_error: true
      - conditions:
          - condition: trigger
            id: unmute
        sequence:
          - service: notify.eventghost2
            data:
              message: Computer2 UnMute
            continue_on_error: true
    default: []

In that “case” (pun intended) I hope they made the default for continue_on_error true for that action, so you can override with an explicit false.

1 Like

what errors are you getting with that code? I think it looks right to me.