Delay before the chime

[ChrisMancini]

I have an odd requirement.

I am using an auto switching amplifier that will detect when it senses a source from an input and switch to that source.

There are two sources going into the amplifier, the first is an Echo Dot and the other is a Sonos AMP (via a Line Out Converter). The issue I am having is there is a slight delay in the switching of sources on the Amplifier. The delay is long enough that the chime is not heard. I was thinking I may be able to get around this limitation by initially delaying the audio via chime_tts using something like this:

  - service: chime_tts.say
    metadata: {}
    data:
      chime_path: "toast"
      end_chime_path: ""
      delay: 450
      final_delay: 0
      tts_playback_speed: 100
      volume_level: .5
      message:
        - type: delay
          length: 5000
        - type: msg
          message: This is a test
    target:
      entity_id: media_player.office

However, the delay is being injected between the chime and the message. I would have thought that when constructing a chord you would define the resulting wav file.

Is this something that could be added to the integration? Maybe with a new field, similar to delay and final_delay?

[nimroddolev]

Hi Chris,

I believe you can achieve this already by using the initial chime as trigger to "wake up" the amplifier, and then use a a message sequence to first add a delay (as long as is needed for the input source switching to complete), then your desired chime followed by the TTS message:

service: chime_tts.say
target:
  entity_id: media_player.office
data:
  chime_path: chirp
  tts_platform: google_translate
  message:
    - type: delay
      length: 5000
    - type: chime
      path: toast
    - type: tts
      message: This is a test

[ChrisMancini]

Grrr...I was so close, that is exactly what I had in mind when I was using the chord, but didn't write it....