{{ repeat.item }} not correctly passed to script

Configuration
,
1

Hi there!
I experience a strange phenomenon while executing a for each loop in an automation.
I have the following yaml, which I want to use, for turning off the candles of my advent wreath (german: Adventskranz) via a script (which send IR codes to the candles):

repeat:
  for_each:
    - candle_1_off
    - candle_2_off
    - candle_3_off
    - candle_4_off
  sequence:
    - action: notify.mobile_app_iphone_von_michi
      metadata: {}
      data:
        message: "{{ repeat.item }}"
      enabled: true
    - action: script.ir_blaster
      metadata: {}
      data:
        ir_blaster: esz_ir_blaster
        command: "{{ repeat.item }}"
      enabled: true

The action notify.mobile_app_iphone_von_michi is just for debugging purposes.
The variable repeat.item in the action script.ir_blaster is not passed correctly to the script. However, it works with the same syntax of "{{ repeat.item }}" in the notify action.
The botifications are always sent with the corresponding content from repeat.item:

Bildschirmfoto 2025-12-14 um 11.11.42
Bildschirmfoto 2025-12-14 um 11.11.421179×1148 60.4 KB

When I manually set the value of command instead of using the variable, the script gets executed correctly and the IR command will be sent.

    - action: script.ir_blaster
      metadata: {}
      data:
        ir_blaster: esz_ir_blaster
        command: "candle_1_off"
      enabled: true

I also tried without quotation marks and with only single ones.

    - action: script.ir_blaster
      metadata: {}
      data:
        ir_blaster: esz_ir_blaster
        command: {{ repeat.item }}
      enabled: true

    - action: script.ir_blaster
      metadata: {}
      data:
        ir_blaster: esz_ir_blaster
        command: '{{ repeat.item }}'
      enabled: true

But neither of those worked either.

Does someone know why this is the case? I would appreciate any advice or tips.

2

You probably need a delay in there unless your ir_blaster script is running in queued mode.

1 Like
3

And even so, Some IR blasters might return as soon as they received a command. The command itself might take as long as a couple of seconds. Sending the next one straight away could lead to either being aborted.

Usually a smartphone camera can show the IR blaster light, so you can see how long it transmits. Experiment with the delays to see how short delays can be.

2 Likes
4

And even so, Some IR blasters might return as soon as they received a command. The command itself might take as long as a couple of seconds. Sending the next one straight away could lead to either being aborted.

Usually a smartphone camera can show the IR blaster light, so you can see how long it transmits. See if it works with long delays, then experiment with the delays to see how short delays can be.

1 Like
5

You can tell if it’s passed to the script correctly by looking at the scripts trace’s changed variables section on the main node.

You’ll see it is passed correctly and you’re likely focused on the wrong problem.

1 Like
6

Thank you guys. I had to add a delay in my IR script. I did some tests and added a delay of 2 seconds, before the commands getting sent.
The IR transmitter was overwhelmed by that many requests.