Google Home TTS has stopped working

Configuration
9

Same problem here unfortunately. I am on a rather old version 2021.5.4, but its stable for me and supports the functionality I need. I haven’t touch anything from when it worked till now, so strange.

10

You’re not the only one. Mine stopped about a month or so ago and I’ve been tracking down the reason. Pretty convinced its on Google’s side. I’ve tried using their DNS servers, different DDNS names, and whatever else I can think of. The media is accessible from my HA instance since I can curl it their from the command line. Playing the link from a browser on a computer yields usable results.

Its only when the Google home wants to do some TTS that it fails.

11

I wonder if google have change their implementation maybe. I’m pretty new to home assistant, is there anyway we can let the devs know or raise an issue with them? There’s so many things I want to try that involve using TTS, I really want my toastie machine to tell me when the toasties are done! Time is of the essence :wink: critical lunch infrastructure is in peril hahaha.

12

As an alternative to TTS since it’s been broken, I’ve been pre-recording messages using TTS websites, saving them as mp3’s and hosting them on a website for media_playback in HA. Not ideal, but it’s an acceptable workaround for fixed messages

13

This is honestly the best thing. You don’t even have to go that far though.

The service is working just fine, but the device refuses to connect. If you monitor the log you can see the request that isn’t discoverable. If you open that link in a browser on your computer it will most likely play just fine, as is my case. From there just save the file and put it in the media folder on your HA instance. Then call it as you need it. I didn’t want to have to go that route but it’s looking like what I’m going to do. My issue was that I had templates build to say “So and So got to school” and just replace the so and so with whoever, but that just won’t work anymore so I’d have to make individual recordings for everything that was originally templated out.

not ideal, you’re right, but probably the only option.

14

May not be relevant to everyone but I got it working using the firewall rule in:

So it seems my network was to blame not the TTS service! Once I allowed LAN IN traffic from my IOT VLAN to Home Assistant IP it worked straight away.

1 Like
15

Interesting (and good news) that someone at least has got TTS working again. All of my stuff is on a single subnet (no separate VLANs for IOT or anything else), so I guess my problem/solution must be elsewhere… :0(

1 Like
16

I take it back. It works great locally now, thanks for the idea. It played once directly from google TTS then never again, tested quite a lot of times. Still perfect locally though, thanks guys I’m happy!

17

I’m still claiming its a google product issue. I can’t even serve a file located publicly on the internet from my google mini.

I can’t even play locally because it doesn’t know how to find even lan addresses.

Using a different DDNS name yeilds the same result.

Looks like it’s a no go from here on out.

18

I’m not sure if this helps, but I’ve just noticed that when I try to get HA to play a TTS on one of my media players (in this case a Google Home Mini), if I look at the file which it attempting to play it is prefixed with an http: URL - for example:

http://myddns.net:8123/api/tts_proxy/e719714e4a8857bb2650ffee3de59160f5521c13_en_-_google_translate.mp3

I was able to see this in Logitech Media Server, which has my Google Home devices connected to it as media players.

This URL would be unreachable, as my HA server is on an SSL/https URL. So it looks as if HA is giving the wrong URL information to the TTS engine.
Any views on whether this is relevant, and if so how to fix it?

19

If that were the case. Unfortunately it isn’t. Mine serves up a https, as it should, but it claims the URL is unreachable. If you take that same url and open it on a computer elsewhere, even on the same subnet, it is reachable.

Something has changed on the google home, and some awkward DNS thing is afoot that exists now but didn’t exist a few months ago. Nothing on my network has changed so who knows.

I still mess with it from day to day but I haven’t made any progress.

MTA: The TTS service is working because it does download the file to the home assistant instance. The google home is the one having the instance finding it.

20

i changed the base url from my unsecure local ip http://192.168.1.3:8123 to the public secure address https:homeassistant.mydomain.com and it is working again. Docs

---
tts:
  - platform: google_translate
    service_name: google_say
    cache: true
    cache_dir: /tts
    time_memory: 300
    base_url: https://homeassistant.mydomain.com
1 Like
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.