Core: tts.google_translate_say no longer works with Google Home

[i00]

The problem

When I call the service "tts.google_translate_say" GH acknowledges it (makes sound) but no message is played.

Environment

• Home Assistant Core release with the issue: 0.113
• Last working Home Assistant Core release (if known): Been happening for a while
• Operating environment (OS/Container/Supervised/Core): Container
• Integration causing this issue: Text-to-Speech (TTS)
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/tts/

Problem-relevant configuration.yaml

Select "Developer Tools" > "Services"
tts.google_translate_say

cache: 'false'
message: 'hey there'
entity_id: media_player.bedroom_1_display

Traceback/Error logs

Additional information

[hmmbob]

Please provide your actual configuration. Did you set the external_url and base_url settings, as directed by the documentation?

https://www.home-assistant.io/integrations/tts/

[probot-home-assistant[bot]]

google_translate documentation
google_translate source
_{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @awarecan, mind taking a look at this issue as its been labeled with an integration (google_translate) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[rlopez2005]

In my case, (Home Assistant Supervised running in a VirtualBox machine), google TTS works once of every 6 or 7 times i try (I go to media_player and write in the "Text to speak" box and usually doesn't works ( I receive a LOG message: "Error on init TTS: No TTS from google_translate for 'XXXXXXXXX'"... Some times it works (As said once every 6 or 7 times) but delays about 40 to 60 seconds in order to "speak" and then i receive a LOG message: "Timeout for google speech"... and even this isn't o.k. because Google TTS speaks "URL characters" as "hello _twenty percent_ world" instead "hello world".
I Think that all this problems maybe are part of the same problem commented here.
Home assistant can see my "media_player" and i can send and play local mp3 files and external radio stations (In Mp3 format), so seems that HA recognizes the unit.
I also defined "external_url" and "base_url".
Any ideas?
Thanks!

[Mariusthvdb]

for the %20 issue: a fix has been PR'ed by Frenck: https://github.com/home-assistant/core/issues/38339#issuecomment-667106924 and https://github.com/home-assistant/core/pull/38429

[i00]

It used to work until a few versions ago. I didn't actually pay much attention to it when it stopped working.. so I didn't take note of the exact version number.

[Dgomezj]

Hi,

I just updated to version 0.113.3 and Google Home TTS stoped working.

This is the error I'm getting:
2020-08-11 22:18:45 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities media_player.home_dormitori
I restored a backup from previous version (0.112.4) and it works again.

Could this be related to issue #38429?

[Dgomezj]

Hi,

I just updated to version 0.113.3 and Google Home TTS stoped working.

This is the error I'm getting:
2020-08-11 22:18:45 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities media_player.home_dormitori
I restored a backup from previous version (0.112.4) and it works again.

Could this be related to issue #38429?

I found the problem. I had installed "spotcast" from HACS to be able to send Spotify content to Google home.
After removing it, the TTS service started to work again and the Google Home Mini is detected as Media Player.

Note: By installing the last version of Spotcast, everything is working again.

[i00]

@dgomes I am using tts.google_translate_say NOT Spotify!

[i00]

for the %20 issue: a fix has been PR'ed by Frenck: #38339 (comment) and #38429

This is not the issue ... it doesn't say Anything!

[i00]

Please provide your actual configuration. Did you set the external_url and base_url settings, as directed by the documentation?

https://www.home-assistant.io/integrations/tts/

This is not the issue ... the Google Home Hub Actually shows the cast on screen and makes the noise (so it can contact the server)..
Just no voice!

[i00]

Ok ... found the issue ... when I inspect my google home after I try to play it the media_content_id specifies the almost correct URL ... the port number is now missing from it!

[hmmbob]

So when I suggested to inspect external_url and base_url, I handed you the correct solution? Add port number there and issue can be closed :) You're welcome.

[i00]

@hmmbob
Well it used to work a few versions ago without modification ... so why does it require changing now?

[hmmbob]

Because there are changes since "a few versions ago"?

It was mentioned in the change logs.

[i00]

Ok ... I just double checked... and the base url specifies the correct URL that it would work with ... but it does not seem to be using that at all and just uses the local IP address of the thing without the port

[i00]

Sorry just to ask ... it knows it's ip address and port ... so why do I now have to specify it in the base_url?

Before it worked and knew that it was hosted on :8123 (or assumed it) ... but now it assumes it is hosted on port 80 for this without specifying it in the base_url?

This doesn't make sense to me ... if it assumes it (rather than detects), unless you specify the base_url, shouldn't it assume that is on port 8123 since this is HA's default?

[mghinch]

I believe I'm having the same problem as the OP. Casting a message results in:
[homeassistant.components.cast.media_player] Failed to cast media https://192.168.0.202:8123/api/tts_proxy/ecb9c151c312ede762490397b67cf5c4ffc76a9e_en_-_google_translate.mp3 from internal_url (https://192.168.0.202:8123). Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address
The mp3 can be player on via my browser from both the local network and from the public network when using the appropriate FQDN. The cast device (Google Mini) is accessible (it responds correctly to "media_player.volume_set"). I'd be happy to provide more info to attempt to localize the problem (probably to my configuration...)

[hmmbob]

Cast requires a valid SSL certificate, if using SSL. Try skipping SSL by using http://192.168.0.202:8123

[mghinch]

I have a valid ssl certificate from Let's Encrypt and it appears to be properly installed against my HA FQDN. I've triple checked that via a web sslchecker. I don't think it a question of google accessing my site. If it helps (I'm not sure what methods google uses to do this), I have a usable mp3 file that came from google's TTS within my HA instance (i.e., tts/1519ae4eedc50d1cda10b6cd0e79433870382cbe_en_-_google_translate.mp3) that may further confirm.

Looking at the other part of the error message (reachable from the cast device), as mentioned the cast device responds correctly to media_player.volume_set from HA, so I believe it is reachable.

Still looking for ideas on next steps...

[hmmbob]

Yeah, that's what I was trying to say: did you try what I suggested?

Your certificate is valid for your FQDN, not for your IP. Just try removing the s fron https in you internal url, or don't use an internal url and send everything through your external url. That'll only work if "NAT hairpin" is we6t up correctly though.

And it is not about google accessing anything, it is about your cast device trying to reach the audio file on your HA instance which fails because your ssl certificate gets rejected because it is set-up for a FQDN and not an IP address.

Just try my suggestion, please. Remove the s out of https and see if that helps.

[mghinch]

@hmmbob - thanks for your help. OK. Here' what I tried in the last couple hours:

• from browser, tried accessing https://192.168.0.202.....mp3: Browser complains about certificate, saying it is for the FQDN not for 192.168.0.202 (as you said)
• from browser, tried accessing http://192.168.0.202.....mp3: Got ERR_EMPTY_RESPONSE. AFAIK, there is nothing listening on 8123 that can deal with http, only https. But I know apache http, not python http -- can python somehow listen for for both http and https??
• changed my internal DNS so that all traffic to FQDN routes to external IP address. Restarted HA. The error message now cites the FQDN instead of 192 (small victory??). When I use a browser to access that site (i.e., https://FQDN/.....*mp3, it plays correctly, no complaints about cert. The Google Mini still does not play the audio. I get sometimes get a little beep, but not the above mp3 audio
• tried above with and without homeassistant: internal_url set (when set, it uses https://FQDN:8123). In all cases external_url is set to https://FQDN:8123. When internal_url is set, the error message cites the FQDN, when unset it cites the 192 address (where is it getting the 192 address from?)

Any ideas on next steps?

[MyNameIzApple]

I managed to get it working by using my duckdns domain, I simply put the domain in the configuration.yaml file under the base_url, but I have not managed to get it working via a local IP address.

[hmmbob]

@mghinch Fair comment about the https server - I was assuming something else was handling https and certificates for you (such as Traefik or HAProxy or something); my bad. You are right that you can't talk http to a https port.

I know that I've worked around this myself by using https://FQDN:port for both internal_url, external_url and tts base_url (combined with having the correct NAT rules in place on my router). I did not set any additional DNS or something: I just route everything to my external IP/FQDN. That is by the way the same as what @MyNameIzApple suggests - worth a try, but YMMV (it'll depend on the capability of your router to handle "hairpin" situations).

Core of your issue is that your Home speaker cannot get the audio file provided by HA. It is connected (hence the "starting beeps" you can hear), but because of routing or certificate issues it cannot load the audio file.

[mghinch]

@hmmbob - Thanks - the explanation and helping to narrow it down to routing or certificates helps quite a bit. And @MyNameIzApple, it's good to hear a success case. Two follow-on questions. The routing that has to happen is just to get packets from an internal device (Google Mini) directed to FQDN:8123 to resolve that address to the external IP address, and then successfully get those packets to that address:port, right? No port translation, etc... Second, just for the record, a Google Mini accepts Let's Encrypt certs and cert authority (DST Root), right? It's this latter point that seems like the highest probability of problem, since everything else on my network is happy with the routing and certs.

[hmmbob]

Yes, I am using Letsencrypt too. If the certificate is valid, it should be fine.

And as for routing: yes, that is the case. It is the same if you (instead your Google Mini) go to https://FQDN:8123/api/tts_proxy/ecb9c151c312ede762490397b67cf5c4ffc76a9e_en_-_google_translate.mp3 - this should work without accepting any certificate warnings (try with your non standard browser, to prevent caching) and without manually setting a DNS record or so for FQDN on your router or PC.

[mghinch]

OK. Got it, with thanks to @hmmbob. Turns out your original comments about "NAT Hairpin" applied to my recent DNS change that forced all traffic (internal and external) to the external IP address. Once I changed to forcing internal and external http requests to be directed to the external interface additional routing was needed to allow port 8123 from internal sources to be routed. The external ones were already being forwarded through my firewall, but the case of something arriving at the firewall from an internal source that then wanted to get back to an internal destination was not covered at my (externally focused) firewall. Fixed that and everything popped up right away. THANKS ALL.

[i00]

So no answer on this:

Sorry just to ask ... it knows it's ip address and port ... so why do I now have to specify it in the base_url?
... it shouldn't assume the port; it didn't use to assume that you were running HA on 8123

[hmmbob]

That's just how the web protocols work: if you don't specify a port, the stack will connect to the default port for that protocol (80 for http, 443 for https). And because it is the default port, it won't be shown/specified in an URL.

Example: https://google.com actually means https://google.com:443