Text-to-Speech (TTS) stops current media playing without resuming it

I am using the tts service to call diverse stuff on my Google Home. The problem is when something is playing on it (Spotify) it gets stopped and I can’t resume it.
I tried placing media_player.media_play_pause service calls before and after the tts service but nothing works.
I need a media_player.turn_on at the beginning to wake up the device (it goes off and the tts.google_say service call won’t wake it).
Am I doing something wrong?

Stupid example

  trigger:
    platform: time
    after: '12:00:00'
  action:
    - service: media_player.turn_on
      entity_id: media_player.google_home
    - service: media_player.media_play_pause
      entity_id: media_player.google_home
    - service: media_player.volume_set
      entity_id: media_player.google_home
      data:
        volume_level: 0.4
    - service: tts.google_say
      entity_id: media_player.google_home
      data:
        message: 'Hello! It is 12 o clock!'
    - delay: 10
    - service: media_player.volume_set
      entity_id: media_player.google_home
      data:
        volume_level: 0.2
    - service: media_player.media_play_pause
      entity_id: media_player.google_home```
1 Like

No, you aren’t wrong. I noticed the same behavior with my sonos player. On the Sonos player I have to use the Sonos controller to switch to the previous media (resume it). I dont think you can accomplish this with an automation.

@pvizeli: Could you implement the following use case:
The TTS component should pause the media play and resume it after the end of the speech. Further it would be advantageous to define a separate volume_set for the tts. I noticed that the volume of tts is to quiet, compared to the same volume set for the played music. Not only the media play should be resumed after speech, also the previous volume set.

I’m also using node-sonos-http-api for tts. This simple http based API for sonos works very well and as described in the use-case above.

1 Like

I noticed this with Kodi, and thought maybe it was Kodi functionality. Good to know more people are having the issue.

I think the play_media function is working as intended. I propose that TTS should not use the play_media function, but instead a new function that can support pause/tts/resume on a per-media player basis.

Ive had the same issue. Just stopped using it for now until I find a solution.

Found this SONOS TTS Script for sonos. Sonos component has the possibility to snapsho and restore.

2 Likes

Same behavior on squeezebox. Stops current playlist and plays TTS, with no recourse to the old playlist.

I guess because different media payers have different behaviors it may be difficult to have a save and resume plalist baked in to the ts component … although there are some clever people out there!

I was toying with using scripts to save playlist, play TTS, then resume the playlist. Playlist saving is not in the squeezebox media player component at this point for HASS, so would be using some squeezebox CLI calls from shell along with the TTS call.

Please share if you create something smart :slight_smile:
I have the same issue with SB and TTS

That is only for Sonos. Other media player won’t accept the command since they won’t have the snapshot feature.

Yes, I know.
That’s why I explicitly wrote about sonos and I mentioned earlier that this probably could not be done with an automation and have to be programmed in the component.

@phileep I cannot seem to get TTS to work on my squeezebox server? I’m running HASS on ubunutu 16.04 in a virtualenv, and I can see the MP3’s getting created in the tts folder, and what “appears” to be passed to the Squeezebox LMS server, but nothing ever plays, and no errors either? below is my TTS section:

 tts:
  - platform: google
    cache: true
    cache_dir: /home/homeassistant/.homeassistant/tts
    time_memory: 300

again, TTS works on a Kodi box, but not my squeezebox. How did you get yours to work?

Thanks

@shep

I have HASS on a RPi 2 running Jessie, squeezebox server is on a NAS.

HASS can see my squeezebox server and treats it as a media player (I have no passwords on the service) - setup for squeezebox in my config.yaml is:

media_player:
  platform: squeezebox
  host: 10.1.1.222
  port: 9090

setup for my tts is:

tts:
  - platform: google

Have used successfully from the services section.

Are you sure you can see and control your squeezebox from your HASS already before trying to hit it with TTS?

@shep
Did you find a solution for this?
Have exactly the same problem.
URL is created for the correct player in LMS, but dead silence.

If I copy the url to browser I can play the tts file without issues.

Ditto here. Never got it to work properly. Tried Google, Yandex, and Voicerss all without success. I see the proper url in the mediaplayer which I tested in a browser and it worked. Just getting silence from my LMS on any player.

What version is your LMS that running on your NAS? Also, are you using SSL with HASS?

I´m running LMS 7.9 on a ReadyNas with Lets Encrypt SSL for HASS.
For what I can read in other threads this is a problem…

I was testing last night on LMS 7.9 running on both Debian and OSX pushing to a Squeezebox Radio. The display within the SBR shows it unable to connect to the HASS URL. I’m running LE SSL as well. I suspected the HTTPS/SSL might be the issue. Seems based on your experience and mine that might be it.

Ironically, HA shows the SBR and after the MP3 is attempted to be streamed and fails, it shows in the Media Player within HA’s UI. If I click play, it works as intended.

Yes :(, more info here:

But @DrJeff got it to work with Squeezeplay

I tested removing the “base_url” definition in configuration.yaml, and it’s working now :slight_smile: I can still reach my HA instance via the HTTPS FQDN I have mapped to my home, so not sure I even needed the “base_url” definition. In any event, test this, I think it will work for you.

Unfortunately this didn´t help for me.
Now the url is internal (192.168…), which might be better, but there is still no sound.
If I copy the url to browser it plays the mp3 just fine.

Tried it with a SB Receiver and Radio, could it be a codec issue?

BTW, are you using Google TTS?
Do you mind sharing your working conf for TTS?