Only one action in a Choose is working - why?

[Mastiff]

I have an automation that has a choose action that based on the trigger.id will check the dimmer that triggered it and either turn on or off a boolean based on if the light is on or off. It should also start or cancel a timer and send to different MQTT message based on what choose is dictated by the state of the light. The problem is that the boolean works, but nothing else. So it should not be anything with the trigger or the conditions. I have tried to change the sequence of the actions within the choose, but that does nothing. Here is the full automation (I only have two dimmers yet, but I am going to expand it to every dimmer in the house when I get this kink out of it):

alias: Slå av og på de falske bevegelsessensorene i rommene med dimmerhjul
description: ""
triggers:
  - id: i_ytterganga_oppe
    entity_id:
      - light.dimmer_i_yttergang_oppe
    not_from:
      - unavailable
      - unknown
    not_to:
      - unavailable
      - unknown
    trigger: state
  - id: i_trappa_fra_ytterganga_oppe
    entity_id:
      - light.dimmer_i_trapp_fra_yttergang_oppe
    not_from:
      - unavailable
      - unknown
    not_to:
      - unavailable
      - unknown
    trigger: state
conditions:
  - condition: template
    value_template: "{{ not is_state('input_select.'~ trigger.id, 'Manual') }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.id != none }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.parent_id == none }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.user_id == none }}"
actions:
  - action: mqtt.publish
    metadata: {}
    data:
      qos: 0
      retain: false
      topic: eventdatatest
      payload: "{{ trigger.id }}"
    enabled: true
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
    enabled: true
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ is_state('light.dimmer_'~ trigger.id, 'on') }}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              qos: 0
              retain: false
              topic: eventdatatestpaa
              payload: Deaktiverer bevegelsesstyrt lys
            enabled: true
          - action: input_boolean.turn_on
            metadata: {}
            data: {}
            target:
              entity_id: >-
                {{ 'input_boolean.bryter_for_falsk_bevegelsessensor_'~
                trigger.id }}
          - action: timer.start
            metadata: {}
            target:
              entity_id: >-
                {{ 'timer.sla_pa_igjen_bevegelsesaktivert_lys_etter_en_time_'~
                trigger.id }}
            data: {}
            enabled: true
        alias: Hvis lyset er på etter to sekunder
      - conditions:
          - condition: template
            value_template: "{{ is_state('light.dimmer_'~ trigger.id, 'off') }}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              qos: 0
              retain: false
              topic: eventdatatestav
              payload: Aktiverer bevegelsesstyrt lys igjen
            enabled: true
          - action: input_boolean.turn_off
            metadata: {}
            data: {}
            target:
              entity_id: >-
                {{ 'input_boolean.bryter_for_falsk_bevegelsessensor_'~
                trigger.id }}
          - action: timer.cancel
            metadata: {}
            target:
              entity_id: >-
                {{ 'timer.sla_pa_igjen_bevegelsesaktivert_lys_etter_en_time_'~
                trigger.id }}
            data: {}
            enabled: true
        alias: Hvis lyset er av etter to sekunder
mode: single

At first I thought it was something with the trigger.id, but that works on the boolean. And as long as the action is run at least the MQTT message within the choose should be sent because it does not implement the trigger.id in it, and it works when I fire it manually. The MQTT message before the choose works and sends the correct trigger.id.

[Didgeridrew]

What do the debug traces show?

[Mastiff]

It shows: “Brain fart, you moron!” I had without knowing it another very similar automation activated (I was sure I had deativated it), and that was what turned on and off the boolean. So nothing in the choose worked. And when I knew that I found the error too, there was a spelling error in the name of the trigger ID.

Sorry, I will go and chastise myself severly now, maybe even deny myself any beer tonight. On second thought no, that’s too severe!

[123 (Taras)]

Would you like to see a simplified version of your automation? A version that does not need a choose?

Also, are you using mqtt.publish just to report the progress of the automation’s execution? Because if that is its purpose then I suggest you use notify.persistent_notification which posts messages directly within Home Assistant.

[Mastiff]

@123 Of course I’d apprecaite a simpler version! And the MQTT has just been my goto method of checking if something works for several years, probably close to ten. Then I can run the stuff a few times and see in the Node-RED log what worked and what didn’t on the string of result messages.

[123 (Taras)]

I believe the following example captures the gist of your automation.

Depending on which of two lights is turned on/off, you receive a notification reporting some data and then set the light’s associated Input Boolean on/off and start (if on) or cancel (if off) its associated Timer.

alias: Slå av og på de falske bevegelsessensorene i rommene med dimmerhjul
description: ""
triggers:
  - trigger: state
    entity_id:
      - light.dimmer_i_yttergang_oppe
      - light.dimmer_i_trapp_fra_yttergang_oppe
    not_from:
      - unavailable
      - unknown
    not_to:
      - unavailable
      - unknown
    variables:
      iden: "{{ trigger.entity_id[13:] }}"
      mode: "{{ trigger.to_state.state | bool }}"
conditions:
  - condition: template
    value_template: "{{ not is_state('input_select.'~ iden, 'Manual') }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.id != none }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.parent_id == none }}"
  - condition: template
    value_template: "{{ trigger.to_state.context.user_id == none }}"
actions:
  - action: notify.persistent_notification
    data:
      title: "{{ now() | as_local }}"
      message: >
        Iden: {{ iden }}, Msg: {{ iif(mode, 'Dea', 'A') }}ktiverer bevegelsesstyrt lys {{ iif(mode, 'igjen', '') }}
  - action: input_boolean.turn_{{ trigger.to_state.state }}
    target:
      entity_id: input_boolean.bryter_for_falsk_bevegelsessensor_{{ iden }}
  - action: timer.{{ iif(mode, 'start', 'cancel') }}
    target:
      entity_id: timer.sla_pa_igjen_bevegelsesaktivert_lys_etter_en_time_{{ iden }}
mode: single

[Mastiff]

Thank you very much! I will look at that during the weekend, I have spent a bit too much work time today with this, so I gotta work late… But I’ll let you know how it works!

[Mastiff]

It seems like there is something that doesn’t work as it should. I have been trying with one dimmer, and on trace I see that it stops on the last condition, value_template: '{{ trigger.to_state.context.parent_id == none }}'. Which I can’t understand, because it didn’t stop on that with the previous version, I think.

[123 (Taras)]

@Mastiff

been trying with one dimmer,

I assume your testing procedure involves physically operating the light switch.

@Mastiff

stops on the last condition,
value_template: '{{ trigger.to_state.context.parent_id == none }}'

The example I posted uses the same conditions as your original automation. In theory, it should behave exactly the same way as your original automation.

Your three conditions involving the context object are designed to pass only if the automation was triggered by physical device operation (which is reported as id is not none and parent_id and user_id are both none).

Action	id	parent_id	user_id
Physical	Not Null	Null	Null
Automation	Not Null	Not Null	Null
UI	Not Null	Null	Not Null

According to the table, if parent_id is not none (not null) then the State Trigger detected that the light’s state was changed not by physical operation but by some other means that it categorizes as “Automation”.

My example’s version uses a simplified triggers section. Instead of two State Triggers, one for each light, it uses a single State Trigger that monitors both lights. This modification should not affect how context is reported. However, if you suspect it might, then change it to two State Triggers like in your original automation. Perform the exact same testing and see if the value of parent_id is none or not.

[Mastiff]

Thanks! Yes, I am using my hand to punch the button. But I don’t know if it complicates it that I need to first turn the light off and then on again. Because the light is on when I go into the room, and then I need to turn it off and on again to have it stay on with the automation. Anyway, I will experiment more tomorrow, and I’ll let you know what I find out.

[123 (Taras)]

What other automations do you have that control these two lights?

      - light.dimmer_i_yttergang_oppe
      - light.dimmer_i_trapp_fra_yttergang_oppe

Because any other automation that changes the light’s state will trigger this one (and so the parent_id will not be none).

[Mastiff]

Thanks again for the help! I have the motion sensing light on each of those, but that will never happen at the exactly same time as the button press. At least not in real life. But I found the problem. I suddenly remembered that I had to remove the not_to and not_from in the original automation to make them work. A bit of experimenting with this one, and I found out that it’s the not_to that for some reason messes it up. So this works:

trigger: state
entity_id:
  - light.dimmer_i_yttergang_oppe
  - light.dimmer_i_trappa_fra_yttergang_oppe
  - light.dimmer_for_taklys_pa_soverom_i_andre
  - light.dimmer_til_spotter_i_taket_pa_badet_oppe
  - light.dimmer_i_soveromsgang_oppe
not_from:
  - unavailable
  - unknown
variables:
  iden: "{{ trigger.entity_id[13:] }}"
  mode: "{{ trigger.to_state.state | bool }}"

I guess that means that if the dimmer goes from anything to unavailable (for instance if there is a power blacout) this will be triggered, right? But that should be such a rare occasion that I think I’ll cope with that. Maybe I could put that condition first in the regular conditions instead? I think this would be correct, but I am not sure:

condition: not
conditions:
  - condition: template
    value_template: "{{ trigger.from_state == unavailable or unknown }}"

It does not block the execution of the action, but I don’t know if it will block it when it changes from unavailable or unknown to on or off.

[123 (Taras)]

@Mastiff

But I found the problem. I suddenly remembered that I had to remove the not_to and not_from in the original automation to make them work.

Why were they included in the version you shared in your first post?

Be advised that their presence has no influence on the value of parent_id when the light’s state changes to on or off.

@Mastiff

I have the motion sensing light on each of those

Is the motion sensor built into the light? What is the light’s brand and model?

---

I suggest you remove all conditions, except for the first one, and add the one shown below. In addition, reduce the triggering options to just an empty to: option.

alias: Slå av og på de falske bevegelsessensorene i rommene med dimmerhjul
description: ""
triggers:
  - trigger: state
    entity_id:
      - light.dimmer_i_yttergang_oppe
      - light.dimmer_i_trapp_fra_yttergang_oppe
      - light.dimmer_for_taklys_pa_soverom_i_andre
      - light.dimmer_til_spotter_i_taket_pa_badet_oppe
      - light.dimmer_i_soveromsgang_oppe
    to:
    variables:
      iden: "{{ trigger.entity_id[13:] }}"
      mode: "{{ trigger.to_state.state | bool }}"
conditions:
  - condition: template
    value_template: "{{ not is_state('input_select.'~ iden, 'Manual') }}"
  - condition: template
    value_template: "{{ has_value(trigger.entity_id) }}"
actions:
  - action: notify.persistent_notification
    data:
      title: "{{ now() | as_local }}"
      message: >
        Iden: {{ iden }}, Msg: {{ iif(mode, 'Dea', 'A') }}ktiverer bevegelsesstyrt lys {{ iif(mode, 'igjen', '') }}
  - action: input_boolean.turn_{{ trigger.to_state.state }}
    target:
      entity_id: input_boolean.bryter_for_falsk_bevegelsessensor_{{ iden }}
  - action: timer.{{ iif(mode, 'start', 'cancel') }}
    target:
      entity_id: timer.sla_pa_igjen_bevegelsesaktivert_lys_etter_en_time_{{ iden }}
mode: single

Perform your tests and report the results.

[Mastiff]

The conditions in the action were in the original automation, but that went through a couple of changes after that post, and I forgot to write them in, sorry.

I’m not really sure why they are there, to be honest. They were in a “context” example automation was only triggered by the physical dimmer, that’s where this started, and I left them in not knowing if they were necessary or not.

The motion sensor is not in the light, they are Fibaro Eye sensors, using the motion activated light brightness blueprint. The lights themselves are HeatIt Z-Wave Dim version 1. I’ll try to experiment with your changed version tomorrow, thanks!

[123 (Taras)]

@Mastiff

The motion sensor is not in the light, they are Fibaro Eye sensors, using the motion activated light brightness blueprint.

That can explain why parent_id was not none and this condition did not pass.

{{ trigger.to_state.context.parent_id == none }}

The blueprint automation, monitoring the motion sensor, is responsible for turning on the light. When it turns on the light, this automation (the one in your first post) correctly indicates that parent_id is not none because the triggering source is “Automation”.

Action	id	parent_id	user_id
Automation	Not Null	Not Null	Null

@Mastiff

I’ll try to experiment with your changed version tomorrow, thanks!

I look forward to seeing the results of the testing.

[Mastiff]

About the automation on the blueprint, if I haven’t misunderstood completely, it only sends on/off once, when the sensor goes from no motion to motion, and again when it goes from motion to no motion. That would noe come in here because the “workflow” with the dimmers will be like this:

1. We go into the room. The motion sensor automation turns on the light when we come in.
2. We press off and then on again on the dimmer. That first turns off the light and then turns it on again and also turns on the boolean for keeping the lights on, and starts the timer to go back to motion sensor controlled lights after an hour.

Yes, the automation to turn on and off the boolean will be ran on the first press that turns off the lights momentary, but that doesn’t affect anything, since the boolean will go to on when the light is turned on again a second or so later. We need to wait a second, because the dimmers have scene controller so that fast presses will be scenes on 2 to 5 presses. But that s not usable for the “motion sensoring light off” that I’m trying to get to work here, because most of the dimmers have stuff on the scenes. And trying to tell my technological Bermuda Triangle A.K.A. wife that “you need to press three times on the bathroom dimmer and four on the home office dimmer to get the light to stay on” is not really something I want to do…

[123 (Taras)]

@Mastiff

We go into the room. The motion sensor automation turns on the light when we come in.

That triggers the automation (displayed in your first post) and its parent_id will be not none which indicates the triggering source was an automation.

@Mastiff

We press off and then on again on the dimmer.

That triggers the automation a second time.

Every change of the light’s state serves to trigger the automation, regardless if the change was made by a person physically pressing the device or by some other automation (or by a person clicking the light in the UI).

---

NOTE

I use a motion-sensing automation to automatically turn on a light and turn it off after a period of time after no motion is detected. To disable it, I have it configured so that I simply need to manually change the light’s brightness. I find that simpler than the “turn off/turn on” procedure you’re using (which was is the same as what I originally used but found to be awkward).

[Mastiff]

The error turned out to be a brain fart, I had the Norwegian “ganga”, “stua”, “badet” and so on in the names of the helpers and “gang”, “stue”, “bad” and so on in the names of the lights and dimmer. The endings -a, -et and -en of a noun in Norway is comparable to the use of the definite article or not in English, so “the hall” versus “hall” and so on. I have tried hard, but I can’t find anybody else to blame than myself.

As for the triggering of the automation, yes, you’re right, when the motion sensor automation turns on the light the it will also triggers this switch automation (meaning the one in this thread) as well, but since it does not pass the conditions for the physical switch, the switch automation does nothing. It just stops. When we then, with the light on, turn it off and on again, this second turn on is done by the physical switch, so this time it does pass the conditions and triggers the boolean and timer action in the switch automation. So the light will stay on until we turn it off again or the timer triggers it after an hour, whatever comes first.

The adjustment of brightness sounds like a good idea, but I think it’s a bit easier to tell others (my wife and visitors) that they only need to turn on and off the light to have it on for an hour. I will try that and if I see the need I’ll take up that brightness idea.

Thanks for your patience and help, everything works the way I wanted it to now!

[Mastiff]

OK, I have one small problem still, more of a “housekeeping” thing. In two of the rooms there are no dimmers, but regular on/off lights. They are not named light.dimmer, but light.lys (“light” in Norwegian). I would guess it possible (and probably simple to ad an action that changes part of the variable iden so light becomes dimmer. That way I don’t have to create a separate automation for those two lights. I have tried to search for that, but I haven’t found out how to do a replace in a variable.

[123 (Taras)]

@Mastiff

Thanks for your patience and help, everything works the way I wanted it to now!

You’re welcome! Glad to hear to it works now.

Please consider marking my post above with the Solution tag. At bare minimum, the example demonstrates that choose is not always required to make decisions in the actions section. The Solution tag will automatically place a check-mark next to the topic’s title which indicates to other users that this topic was solved. It also helps others find answers to similar problems.

@Mastiff

not named light.dimmer, but light.lys

I suggest you change the template for iden to this:

    variables:
      iden: "{{ trigger.entity_id | regex_replace('^light\.(dimmer|lys)_', '') }}"

Proof that it works: