Problem with tts and sonos

hello everyone,

I am a newbie and have the following problem.

Suppose sonos is playing music and I want to interrupt it for a message via tts and then just play music again. I can do this with snapshot and restore! But my problem is that when I forward a longer message via tts, the text is partially deleted. This can be solved by introducing a delay, but then there is the problem that if the text is shorter, I have to wait too long before the music starts playing back.

Does anyone know a solution for this?

Here’s my automation:

alias: Sonos TEKST RSS
sequence:
  - service: sonos.snapshot
    data_template:
      entity_id: '{{speler}}'
  - service: media_player.volume_set
    data_template:
      entity_id: '{{speler}}'
      volume_level: '{{volume}}'
  - service: tts.voicerss_say
    data_template:
      entity_id: '{{speler}}'
      message: '{{ tekst }}'
  - delay: '00:00:05'
  - service: sonos.restore
    data_template:
      entity_id: '{{speler}}'
mode: single

You can use a wait_template instead of a delay.

you’ll have to test it to know what the state is in after the TTS finishes and before it starts playing music again to figure out the template but something like this:

{{ states('media_player.sonos_kitchen') == 'idle' }}

or

{{ states('media_player.sonos_kitchen') == 'paused' }}

that way you won’t need to know how long the message is and it will just wait for the TTS to finish before continuing.

1 Like

Thank you for your response.

I’m going to try it soon.

I already tried with a “wait for trigger”;
but that didn’t work!

Functions perfectly. Thank you

1 Like

Best,

So far this solution worked perfectly.

But now that I’m a bit further in HA, I notice the following problem: “If the text is a bit longer, e.g. 1 minute, the status of the media player goes back to pause, but the text has not yet been read completely”.

Anyone have an idea how I can solve this now?

Thanks for all the responses!

Please try with 2023.5 and skip the snapshot/restore. There’s a new feature that overlays the audio on top of any music currently playing. The tts.voicerss_say service call should be all you need now.

Thank you very much for your response, going to give it a try

Best,
I’ve tried this, but it’s still the same.
Is there another solution for this?
Thank you for your response.

Yes, same here, still an error.
Not right after starting HA, but after a while TTS stop working.

My solution (ugly workaround) is to replace the
lib/python3.11/site-packages/homeassistant/components/sonos
directory with the same directory from the 2023.4.6 release.

Surprisingly, this solution worked flawlessly and did not rely on sonos-websocket at all. Although it may not be the most elegant approach, it successfully restored TTS functionality in my Home Assistant setup.

Please don’t do that, it will definitely break over time. There were fixes to TTS in the point releases. Were you on the latest 2023.5.X?

Yes, I’m always at latest version (I’m even doing beta).
Even if it was said “fixed” in 2023.5.2 (“Bump sonos-websocket to 0.1.1”) it was later removed and re-introduced in 2023.5.3
But it is not solved (yet)

There aren’t existing reports of notification sounds stopping to work, so please create an issue in core with more details.

There is but is now closed

The behaviour is exactly as before.
I’ll post logs there

Agreed. Still not working, is there another report open?

Just did

@Mabaelst, @kartcon good news for me, hoping the same for you, the correction made in sonos-websocket 0.1.2 by @jjlawren has solved my issue.

Hope it will be in 2023.5.5 (or 2023.6.x)

Thank you for your response,
but still don’t quite understand how to solve this. I’m fairly new here and trying to learn a lot.
Can you explain this to me a bit?

You’ll have to wait for next release of HA.
As a professional tinkerer, I have modified some files that shouldn’t be modified to test what will be in the next version.
I was prepared to take the risk of messing up my installation.

Thank you very much for your response,
So if I understand correctly, it will be fixed in the next update?

Using what should be in the next release is solving the problem.
To be sure that it is, look at the release note (2023.6.0 is planned for June 7th)

You should see a line like this one: