WTH is there no option to resume media after a TTS announcement

Month of "What the heck?!"
1

For some spoken notifications I recently switched back from an unofficial Google Home Broadcast function, to Home Assistant’s built-in TTS feature. While that works great, it would be even better if it did not cancel and replace the music that was playing before it, but just resumed it afterwards, like the broadcast function did.

I’ve found some awesome, but quite complicated scripts that allow me to do this, but think that this would be a really helpful feature to be in HA itself. A tts-call with resume: true as a variable for example would make this a lot easier.

2

It would be nice if the music kept playing but the volume “ducks” while the announcement occurs.

You get that feature with Google Homes and Chromecasts. I really like how it keeps audio flowing.

12 Likes
4

Playing two things at a time may require support from your hardware, as what home assistant basically does is tell your hardware (e.g. Sonos) which source to play. If the given hardware can’t play two sources at the same time (or does not support that in their API), it needs to stop playing music (temporarily) to play the TTS mp3.

2 Likes
5

FWIW, the media_player.play_media service call has an announce option.

Screenshot_20221004-102555~2
Screenshot_20221004-102555~21071×677 54.5 KB

However, it only works for devices that support this capability and that have been implemented in the device’s integration. I believe the option currently only supports Google Home/Chromecast.

Currently, the TTS integration doesn’t support an announce option. EDIT I was mistaken. TheFes explains in a later post that the TTS integration’s tts.google_translate_say spawns a call to media_player.play_media with announce: true. Therefore the TTS integration implicitly supports the announce feature.

7 Likes
6

While two things at a time would be the best outcome, I understand that that requires support from the media player. I’m perfectly happy with a one-after-the-other solution that just continues the media that was playing before the announcement.

1 Like
7

From what I understand from the creator of the script and automation that resumes media automatically after a tts-message, the announce parameter is used in tts-calls in home assistant. That is how his automation knows when to trigger.

8

That script employs the announce option of the media_player.play_media service call.

9

I use it in my Google Home resume script, but that is not the script you linked to.

10

No, I use it in another script, well actually an automation, which will trigger my script in case the announce flag is set

1 Like
11

Where in that script is it using the TTS integration?

12

Not, unless the TTS integration is used as an action.
In the automation also linked there I use the service call media_player.play_media as trigger and I check for announce: true

13

If you review my original post, I mentioned that announce performs the requested function but is currently only supported by the media_player integration, via the media_player.play_media service call. The option is not supported by the TTS integration.

Then duncank claimed your script uses announce in “tts-calls”. That appears to be a misinterpretation on duncank’s part because your script doesn’t employ the TTS integration; it uses the media_player integration because it’s currently the only one that supports announce.

If TTS did support announce then we could do this:

service: tts.google_translate_say
data:
  entity_id: media_player.floor
  message: "May the force be with you."
  announce: true

EDIT

I wasn’t aware that the TTS integration’s tts.google_translate_say spawns a call to media_player.play_media with announce: true. Therefore the TTS integration implicitly support the announce feature. Thanks to TheFes for explaining this to me.

1 Like
14

If you listen to service call events you will notice that a tts service call will issue a media_player.play_media service call which will send the tts message to the media player. This service call will have announce: true

# tts service call
event_type: call_service
data:
  domain: tts
  service: google_cloud_say
  service_data:
    entity_id: media_player.vlc_telnet
    message: This is a test
origin: LOCAL
time_fired: "2022-10-04T15:54:07.023438+00:00"
context:
  id: 01GEHV8M9EPN5KS8KY28C3BFWZ
  parent_id: null
  user_id: 24c8260fb51f4fb995e5aeaaaa3edd1b

# media_player service call
event_type: call_service
data:
  domain: media_player
  service: play_media
  service_data:
    entity_id:
      - media_player.vlc_telnet
    media_content_id: media-source://tts/google_cloud?message=This+is+a+test
    media_content_type: music
    announce: true
origin: LOCAL
time_fired: "2022-10-04T15:54:07.032844+00:00"
context:
  id: 01GEHV8M9EPN5KS8KY28C3BFWZ
  parent_id: null
  user_id: 24c8260fb51f4fb995e5aeaaaa3edd1b
15

Duncank claimed your script uses the announce option in “tts-calls”, implying the TTS integration was used. However, that’s not possible because the announce option isn’t supported by the TTS integration.

Therefore your script, and correct me if I’m wrong (because I don’t have the time to review hundreds of lines of script code) goes through the usual procedure of creating/restoring a snapshot plus some clever bit of listening for a service call event.

What it’s not doing is this (because it doesn’t exist):

service: tts.google_translate_say
data:
  entity_id: media_player.kitchen
  message: "Today is John's birthday."
  announce: true # this option would make it easy

EDIT

The TTS integration’s tts.google_translate_say spawns a call to media_player.play_media with announce: true. Therefore an explicit announce option isn’t needed; it’s employed implicitly.

16

No, you are totally missing my point.
The anounce: true option is not needed on the TTS Servicd call
ALL TTS messages are already sent to the receiving entity with anounce: true

Check for yourself by listening to the call_service event and sending a TTS message.
You will first see the event that the TTS service call is issued, but after that you will see a media_player.play_media service call with announce: true

1 Like
17

Thanks for clearing that up, I appreciate it; I didn’t know it did that. :man_facepalming:

I can confirm that calling tts.google_translate_say spawns a call to media_player.play_media with announce: true.

While performing the test, I discovered that my Chromecast-compatible device (a non-Google device that behaves like a Google Home Mini) doesn’t produce the desired result with the announce option; it never resumes playing the original music.

First experiment

  1. I asked Google Assistant to play Jazz. It picked some free Google YouTube Jazz channel and starting playing music on the device.
  2. Then I used Developer Tools > Services to execute tts.google_translate_say to speak to the device.
  3. The music stopped, the message was spoken, the music did not resume.

Second experiment

  1. I used Developer Tools > Services to execute media_player.play_media, without announce, to play a local music file to the device.
  2. While the device was playing the song, I used Developer Tools > Services to execute tts.google_translate_say to speak to the device.
  3. The original music stopped, the message was spoken, the music did not resume.

Third experiment

  1. I used Developer Tools > Services to execute media_player.play_media, without announce, to play a local music file to the device.
  2. While it was playing the song, I used Developer Tools > Services to execute media_player.play_media, with announce: true, to play a short local music file.
  3. The original music stopped, the short music file was played, the original music did not resume.

Not sure why it fails to resume music for all three tests (other than to conclude it’s not 100% Chromecast compatible). I don’t have a Google-branded device to perform a comparative test.

FWIW, I repeated the experiment with a Sonos speaker and got the same result but I knew in advance it wouldn’t work because the announce feature is not implemented for the Sonos integration.

4 Likes
18

So maybe the easy way to solve this for other devices which don’t natively support it at the hardware/api level is to provide a default implementation in media_player triggered by a play_media call with announce: true on a media player that doesn’t natively support resuming audio after announcement, which would:

  1. Store the current track/source/whatever, with position information if available.
  2. Pause
  3. Play announcement
  4. Wait for announcement to finish
  5. Resume previously stored media, at the position where it paused, if supported

It’s possible that the media_player interface is too generic/abstract to do this, but in that case we could add it to several of the more popular media player integrations.

I imagine this is more or less how the

work.

19

The music provider service playing on the cast device will have to support it. If you play something with Music Assistant, it will be resumed.

20

I tested the Chromecast device just for the purpose of exploring the announce feature in this topic. Normally I don’t use it for daily operations. Nevertheless, I appreciate the link to Marcel’s Music Assistant (I was aware of it but use other means to play music and announcements).

FWIW, I use a script for playing announcements to Sonos speakers. It sends the text message to a local Windows machine where an application uses SAPI to convert it from text to speech (so TTS conversion isn’t cloud dependent and uses a high quality local service). It informs Home Assistant when the audio file is ready and then Home Assistant plays it on the chosen Sonos speakers. The speakers are snapshotted, paused, re-grouped in the desired manner, the audio file is played, then the snapshot is restored. It also has the ability to avoid re-grouping the speakers if they are already grouped in the desired way. The whole process takes about 2 seconds where most of the time is in re-grouping the speakers.

2 Likes
21

If only that snapshot feature would be possible on cast devices :slight_smile: