I updated from 22.04.06 to 2022.09.01 and google_tts stopped working, pls help

Configuration
1

i updated today from 22.04.06 to 2022.09.01

my universal media player just sends the media_content_id as payload via mqqt.
this integrated nicely with the google tts service

media_player:

  • platform: universal
    name: UMP
    commands:
    play_media:
    service: mqtt.publish
    data:
    topic: ‘espaudio/announce’
    payload: ‘{{ media_content_id }}’
    qos: 2
    device_class: speaker

media_content_id was the url to play. now it’s something like this if i watch my mqtt broker

media-source://tts/google_translate?message=Helllas+Hellas+!&language=el

no more voice output

what happened? what do i have to change? i can’t find anything at the release notes that helps

how do i get the url format back ?

my playback device does not recognize this format!

2

Rather than give you an answer, I’d suggest an approach that is likely to help you with both this and future issues:

  • If an automation breaks with a new release:

    • check the log messages - what error is given?
      The line number may be off, but the error is usually accurate.
    • Does the release have any breaking changes?
      (in this case, there is a LARGE jump of almost 6 months, so less useful)
    • Consider a separate pre-production / test install of HASS on a VM / RPi.

  • Create a full backup, separately backup key files like automations.yaml, and copy to a separate machine. Then…

  • Create a NEW test automation using the GUI to perform some or all of the problematic actions.
    Study what the automated tools have created - the syntax and service names may have changed.
    Writing complex automations using the GUI isn’t always ideal, but it is a good way of generating correct YAML for testing.

Your code mixes MQTT, media player, and TTS so it’s unclear which area is the problem however:

  • There were changes to the syntax around MQTT sensors (reversed the heirarchy), so this may need rework to publish.
  • Playing an audio file still works for me using media_player.play_media, but with a local saved WAV file.
  • TTS also works via the tts.google_say service.
3

HA notified me of the changes around the mqtt sensors, that was solved quickly and easily

mqtt and the media player does not seem to be the problem here
it still plays my local mp3’s - tested that via an automation as suggested

the problem seems to be the google translate service which instead of the url to the speech-file now gives this

media-source://tts/google_translate?message=Helllas+Hellas+!&language=el

there are no errors in the logs regardings this
i use a docker based installation
tts.google_say brought an error because the tts configuration did not change the service name from google_translate_say, i change that so that error vanished again, but i still get this media-source

i tried to add the notify service as in Notify using TTS - Home Assistant
but that doesn’t change anything, i still get this media-source-url thingy

i have a very minimal tts configuration:

tts:

  • platform: google_translate
    service_name: google_say

notify:

  • platform: tts
    name: umplayer
    tts_service: tts.google_say
    media_player: media_player.ump

what do i need to change to resolve these non-absolute-media-urls?

4

As an example this snippet is from my own working automations to play TTS to a remote Google Next Hub:

# config.yaml
# Google Translate TTS service
# https://www.home-assistant.io/integrations/tts
tts:
  - platform: google_translate
    cache: true
    cache_dir: /tmp/tts
    time_memory: 300
    service_name: google_say



# automations.yaml
  - service: tts.google_say
    data:
      entity_id: media_player.nesthubXXXX
      message: This is a test.
      cache: true
5

you describe basically my system configuration which worked before the update to 2022.9.1

the thread title is now misleading, i found out so far that the change of behavior is in the google_tts service
my opinion, becasue that’s the component which now sends different data
a simple static service call with a static text to give out a speech results in a media-source-url i have given an example above

my whole call chain ist:

  1. a script which takes a text message and a language code, sends them to tts.google_say and a mqtt topic (for text output on a display)
  2. tts sent ( past tense, before the update ) an http-url to the universal media player; now just this weird “media-source://”-url. the cache directory is /config/tts, last file created there is from yesterday, when i created a new automation given an audio response to a new sensor threshold
  3. the ump sends the absolute http-url (past tense) to my “esp32 media players” which play them using esp-audio. yes, this is older than the esphome mediaplayer support, but worked for nearly a year and is totally unrelated to the error

the ump works if given a working http-url

do i have some kind of authentication with google tts? i didn’t had that before…

i tried some urls i crafted by hand
that’s the most recent file created in /docker/ha-config/tts
http://192.168.7.195:8123/api/tts_proxy/bfeb0e015b8ca3ca6e215c3bb26d9c4c33252bcd_de_-_google_translate.mp3
gives INVALID_RESPONSE
http://192.168.7.195:8123/tts/google_translate?message=Helllas+Hellas+!&cache=true&language=el
given 404

i also tried googling this weird kind of url prefix as
“media-source” “tts/google_translate”
https://www.google.com/search?q=“media-source”+“tts%2Fgoogle_translate”
but i find only people with problems, but no solutions
some suspect it has to do with internal url, which i have configured, i do not have an external url.
i only use HA at home inside my private network.

i am on
Home Assistant 2022.9.1
Frontend 20220907.0 - latest
in form of an docker image

is this some kind of developer version which may have bugs ?
this would explain a lot

6

i found here

Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address

my HA is not publicly reachable, was never, will never.
why did it work before the update?

in the same github issue is this part

Rolled back to 2022.2.9 and it works

7

Use the terminal emulator to look in /root/config/tts - HASS calls Google TTS, caches the audio as an MP3, then serves it out locally on the LAN from the cache directory. (Interestingly, cache_dir: /tmp/tts seems to be ignored, perhaps relocated by a container jail).

The same method works to play local MP3 files, although some setup may be needed to create a local directory to store audio (e.g. /media/sounds/sound.wav = media-source://media_source/local/sounds/sound.wav.

ISTR using dev tools to call the Media Player: Play service with a known good local URI to test this with a ChromeCast. IPv6 / mDNS / hostname issues also are worth checking.

The only other factor I’m aware of is if you pay Nabu Casa - if so, access to extra TTS voices is available. I now pay, but thought TTS worked before.

8

i reverted my installation

updating is overrated

9

ok. i got the same problem.
so the only solution is to store MP3 files and let the local tablets and sonos or other media play the local mp3 files? ouch