Google Home TTS has stopped working

Configuration
21

Doesn’t work on my end. My base_url has always been my external url. Has been for years. I don’t think this is the culprit.

22

Same here - my base_url has always been set to https://mydomain.ddns.net

Curiously, I had a look in my /tts subfolder this morning and notice that some google-translate mp3 files are still getting generated there from time to time (but very rarely). The last one was created on October 11th. Another three on August 4th, and quite alot on July 27th. Before September I was running a much older version of HA Core. TTS has never worked at any of those times.
If I manually send a TTS request to a speaker today it doesn’t create anything in the tts folder.
I’m curious to know why the location of the requests that the TTS feature is attempting is /api/tts_proxy, when they seem to be created in a completely different folder.

1 Like
23

Thanks! Allowing the incoming traffic is the solution. In my case, I am using an https external url for my HA. Changing the configuration from base_url to external_url makes it work!

24

If I try to change base_url to external_url in my tts: section I get:

Invalid config for [tts.google_translate]: [external_url] is an invalid option for [tts.google_translate]. Check: tts.google_translate->external_url. (See ?, line ?).

???

25

So oddly enough, after further investigation, I’m pretty sure this is some weird DNS caching issue that’s going on.

Currently I’m running pihole on the same system as home assistant. If I change the DNS servers of the the system and wait long enough, I can somehow get the TTS to work. Shortly there after it quits, again, stating that it can’t find the address. Even if the (DDNS) address is my IP.

I’ve tried hairpinning and i’m not able to make it work correctly, just yet, and attempting to redirect hardcoded google DNS causes the network to come crashing down (requires further investigation).

I’m half tempted to spin up an HA instance on another system that isn’t running pihole and see what happens. I’m thinking, in my case, that both being on the same system is causing the issue.

edit: Not sure why this is marked as solution. It shouldn’t be

26

Not sure if things changed after the recent HA update. Now config shows “base_url” with my external url. This is what I have now:

tts:
  - platform: google_translate
    service_name: google_translate_say
    language: "en-us"
    cache: true
    cache_dir: /tmp/tts
    time_memory: 300
    base_url: ***removed for privacy***
1 Like
27

I had the same issue after a power cut… Turned out I was setting the internal url with the ip address that was no longer being by my HA instance. I changed the IP setting for my internal URL and its all working again.

My log file:
’

I suspect the same would be true for the external error for alessandro.bardi
’
https://xxxxxxx.duckdns.org/api/tts_proxy/f1f11c062b66b160e53f80d22cf3388f7a1e7fc9_it_-_google_translate.mp3 from external_url (https://xxxxxx.duckdns.org). Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address
’

I suspect that in the external case the public IP was change by the ISP and it just needs to be updated.

28

I suspect that in the external case the public IP was change by the ISP and it just needs to be updated.

When using ddns services this shouldn’t matter at all, plus when using ssl the url needs to match the hostname and certificate (per the wiki).

Honestly, running your instance via IP address is a bit of a ticking time bomb, and no reason to do so unless its actually your static IP.