TTS Error with Google - configuration is not valid

So this has been working for over a year.
Today, I was adding sensor platform in the config file.
I can save the config, but when I try to restart HA, i am getting an error about something unrelated…TTS

Here is my TTS:

tts:
  - platform: google_translate
    cache: true
    cache_dir: /tts
    service_name: google_say
    base_url: https:myexternalurl.ui.nabu.casa

Here are the sensors I am creating (this may be wrong, but I am working through it)

sensor:
  - platform: average
    name: 'Average Max Pool Temp'
    duration:
      days: 14
    entities:
      - sensor.max_pool_temps_14_days    
      
  - platform: statistics
    name: "Max Pool Temps 14 Days"
    entity_id: sensor.pool_temp
    state_characteristic: value_max
    max_age:
      days: 14

That is the only change I have made, is adding those sensors.

The error I get when I try to restart HA is:

Failed to restart Home Assistant
The system cannot restart because the configuration is not valid: Invalid config for [tts.google_translate]: [base_url] is an invalid option for [tts.google_translate]. Check: tts.google_translate->base_url. (See ?, line ?).

If I remove TTS now, it restarts.

1 Like

so i gave up on the google, and will just use tts.cloud_say
I removed that section from the config file.

using tts.cloud_say:
I am running a test with it because in the automation it is failing.
I am trying to send a test message to my Google Hub on my desk here.
it connects, but nothing plays.
Then I get a quick pop up that says it failed. No other details, no logs.

after some search, I have found that base_url is not used.
not sure why I am now just getting this issue.

Here is my config now:

tts:
  - platform: google_translate
    cache: true
    cache_dir: /tts
    service_name: google_say

Under homeassistant: in the config file, I ahve defined the external url as my casa url.
I have also added an http:/ipaddress:8123 as internal.

Nothing has changed. I click run on the automation, it connects to my google device, but nothing plays.
in the UI, all I get is an unexpected error has occurred.

I have a test automation that I use to test things.
Here i am running each piece individuallly to test.
Using both tts.cloud_ say and google. Both fail the same way.

I resolved this just now.
I made my internal_url under homeassistant: as my casa url, same as external.
Started working.

Hi.
Could you give me more details? What do you mean as:
“homeassistant: as my casa url, same as external.”
???

Thanks.

1 Like

Setting your internal URL to an external one isn’t a solution is it? Perhaps just a workaround?

This is the error appearing in the logs:

2023-07-09 17:21:45.401 ERROR (Thread-9) [homeassistant.components.cast.media_player] Failed to cast media https://**.***.tech/api/tts_proxy/aaf4c61ddcc5e8a2dabede0f3b482cd9aea****_en_-_google_translate.mp3 from internal_url (https://**.***.tech). Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address

External URL is set to use HA Cloud:

image

Just upgraded to 2023.7.2, and this issue still seems to present. Pretty strange?

Same issue here.

same here :frowning:

I just removed the base_url: line in TTS config and restarted.
That fixed the TTS service in my case.

1 Like

That doesn’t work. What did you do to confirm it was working?

Tested automations that have text to speach announcements to google nest mini devices.

I also wanted to jump in here and add to to chorus that this has stopped working.
Commenting out the base_url indeed allows HA to stop complaining when I try to reboot/reload, however automations that I have to have the google mini talk don’t work with the line commented.

tts:
  - platform: google_translate
    cache: true
    cache_dir: /tmp/tts
    time_memory: 300
    #base_url: https://mydomain.duckdns.org
    service_name: google_say

Any luck getting this fixed?
I am having the same issue. I commented out the config file with the below example and my config file compiles without any errors.

tts:
  - platform: google_translate
      #base_url: https://testing.duckdns.org:9999
    service_name: google_say

I tried tts.speak Text-to-speech (TTS) - Home Assistant and that works but I can’t get it it work correctly with node red as I have some more complex automations. I also can not figure how to get it working with templates. Any ideas?

That fixed it for me too. tnx.

1 Like

These constant changes are really going on my nerves. I had to comment out the base_url as well and now, the whole system is not talking to me anylonger… I am really fed up and already considering not to update HA anymore, once I get it back working… For me it was just running fine, all devices and automations were working perfectly… And then this crap again… FCK !! - So is there a working solution to this problem, as I can’t figure out from previous posts, what to do step by step to get the google voice back talking… ?

2 Likes

I’m assuming people who have “fixed” this, are not longer using the Local Network setting under the “Home Assistant URL”?

I’d say thats more a workaround then a fix? Routing all of your local traffic via the internet seems a bit silly to me?

snervante e questa volta sono anche infastidito da queste situazioni che minano il mio lavoro.

Removing the base_url does allow HA to load without error, however the TTS doesn’t actually work without it.

Well, it actually worked when trying to play the media in the web browser where HA is displayed, but it did not work when I attempted to play the media on my google speaker.

Any solution?

The possible reason this won’t work on an internal URL is because it only works over a secure connection. If you have not set up a valid SSL certificate for your internal URL then your media player is likely to reject playing the downloaded audio file.

I have my Home Assistant configured using a domain name I own, and use Cloudflare DNS challenge to generate a valid SSL/TLS certificate then have my router point an internal DNS record to my HA server.

I’ve not tested this yet since this bug was reported, but suspect this might be why the internal URL isn’t working for some.