Delay's ignored in automations and scripts.. how can I have a delay?!

Configuration
,
1

I’m trying to automate sending IR codes to my TV and surround sound setup.
I can send each command on its own just fine, but to send a sequence I need a short delay between each or the devices being controlled miss IR codes.

To turn my TV to its surround sound output, for example, I’d like to:
send Tools
wait
send Enter
wait
send Down
wait
send Enter

something like this in yaml:

  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.irblaster_tv_tools
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 450
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.irblaster_tv_ok_enter
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 450
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.irblaster_tv_down
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 450
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.irblaster_tv_ok_enter
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 450

Whatever I set the delays to, in ms or seconds, they seem to be ignored whether they’re in an automation or an automation’s calling the same thing in a script.
Logbook entries confirm the delays aren’t between the times commands are sent, it’s one immediately after the other.
Then the TV doesn’t keep up and misses IR codes so it ends up in a mess.

Is delay not the right thing to use? If it is, how should I be using it or why might it not be working as is?

TIA!

2

I’m not sure what is happening with yours, but here’s one of mine that definitely is working with delays (for comparison)

alias: Restart stalled Solax
description: ""
mode: single
triggers:
  - value_template: >-
      {{ (as_timestamp(now())|float(0) -
      as_timestamp(states.sensor.solax_rtc.last_changed))|float(0) > 120 }}
    trigger: template
conditions: []
actions:
  - target:
      entity_id: switch.solax_inverter
    data: {}
    enabled: true
    action: switch.turn_off
  - delay:
      hours: 0
      minutes: 0
      seconds: 30
      milliseconds: 0
    enabled: true
  - target:
      entity_id: switch.solax_inverter
    data: {}
    enabled: true
    action: switch.turn_on
  - delay:
      hours: 0
      minutes: 0
      seconds: 30
      milliseconds: 0
    enabled: true
  - data:
      device_id: c2d08b22d9aaf24a7660c195f0853312
    action: unifi.reconnect_client
  - delay:
      hours: 0
      minutes: 1
      seconds: 0
      milliseconds: 0
  - target:
      entity_id: sensor.solax_active_power_target
    data: {}
    action: homeassistant.reload_config_entry
  - data:
      title: Recovered locked up Solax Integration
      message: Solax Reconnected
      data:
        ttl: 0
        priority: high
    action: notify.mobile_app_pixel_8_pro
3

This might sound really condescending but I have done this many times myself.
Did you save the automation?

You can check the actual output on the IR blaster with a camera and set them to send each command with a few seconds in delay.
See if it does wait or it’s just one long stream from the IR diode

4

Thank you both.
It looks like im not using it wrong

I’m definitely saving the automation and/or script.

The gadget im using to send IR codes has an activity LED that’s on as it sends codes. I can see it flutter on/off, without the delays between codes.
The timing of logbook entries shows the same.

It seems to be ignoring the delays, whether they’re in an automation or the automations calling a script. WTH?

5

Look at your automation/script trace, I’d be willing to bet it’s honoring the delays. When in traces, click the 3 dots and click download trace. Then post the trace here, I can point out the time delays between each action if you can’t find them yourself.

6

There might be more to it than was evident initially…
If it’s just a list of command, delay, command, then the delays do seem to work (and are mentioned in the trace).
But, if the first step is ‘turn the TV power boolean on’, then things fall apart.
I have aseperate automation fire when the booleans turned on, which pings the TV and sends its power IR code if it doesnt get a reply. That seems to work just fine when I manually switch the boolean.

I guessed it might be the timing of when that tv power boolean/automation is running.
Trace showed the delays were in the surround script were happening, but in-line with the tv power automation-thanks again @petro
So I’ve just copied the relevant bits of the TV power automation into my surround sound script, so it all runs in the one… and it works.

Is there a way to keep that ‘ping the TV and turn it on if its off’ automation seperate, but have it run in-line with this surround automation, to save duplicating it?

7

Move it to a script so you can call it from either automation. Then you can call it via the blocking method, which is by using action: script.my_script_name. The alternative (action: script.turn_on) is non-blocking and therefore will call the script and immediately move to the next step without waiting for that called script to finish.

8

That should do it. Thanks all

1 Like