How to time this dynamically exact, opposed to hard coded

Configuration
1

in my alarm automations, I use this repeat-until sequence:

        repeat:
          sequence:
            - service: tts.google_say #tts.cloud_say
              data:
                language: >
                  {{states('input_select.intercom_language')|lower}}
                entity_id: *alarm_players
                message: >
                  {% set language = states('input_select.intercom_language') %}
                  {% if language == 'En' %} {{message_en}}
                  {% elif language == 'Nl' %} {{message_nl}}
                  {% else %} {{message_en}}
                  {% endif %}
            - delay:
                seconds: 7
            - service: script.play_alarm_sound
              data:
                player: *alarm_players
            - delay: 10

          until: >
            {{is_state('alarm_control_panel.ha_rpi4_alarm','disarmed')}}

the first delay of 7 seconds, suffices in testing the config, but might be too short, when the message gets longer because of the triggering offenders :wink: Anyways, it is a bit too long already, and I would wish the alarm sound to really attach to the notification. Scaring their socks off so to say.

Was thinking of wait_templating this for the alarm_players to be ‘idle’, but that might be too complex, since they are

      - service: media_player.volume_set
        data:
          entity_id: &alarm_players
            - media_player.googlehome_library
            - media_player.googlehome_hub
            - media_player.googlehome_hall
            - media_player.googlehome_master_bedroom

and I don’t think we can easily template that into the wait_template? Of course I could hack that to 1 of the alarm_players and use

{{is_state('media_player.googlehome_hall','idle')}}

odd thing is, when playing the tts.google_say service, the media_player isnt changing its state, and the
next service script.play_alarm_sound starts playing too soon for the google_say to even begin.
Forcing me to fall back to the hard_coded delay.

Anyone with a golden suggestion?

thanks for having a look!

2

What about grouping the alarm players and testing that for “not playing” in the wait template?

3

Thanks Tom, and yes, I’ve given that some thought too, (aamof, I had the group before the anchor…) but the issue seems to be that the first state change isn’t picked up quickly enough, so the google_say service is already taken over by the play_alarm_sound service.

what I hacked up would be a delay of 1 second (in which the state would hopefully change into ‘playing’ alright), then wait for the wait_template, and continue.

but had to finally use even 3:

            - delay: 3
            - wait_template: >
                {{is_state('media_player.googlehome_library','idle')}}

Still this feels so inelegant…

4

If the problem is the flip-flop between states, then you need two wait_templates, the first one to wait for it to be playing, and the second to wait for it to be subsequently idle.

5

ha, yes, you mean like:

            - wait_template: >
                {{is_state('media_player.googlehome_library','playing')}}
            - wait_template: >
                {{is_state('media_player.googlehome_library','idle')}}

edit:

this works for the first run, but doesnt work in the repeat, it keeps repeating the play_alarm_sound service…