That’s what it looks like. Google must have changed something since it did work. I think it stopped working shortly after they introduced the Broadcast feature.
Can’t comment there - I don’t own any, and haven’t looked in to the platform. I would have gone with the googles but they weren’t available in the UK when I decided I wanted a voice assistant so I went with Amazon Echo dots instead (on the basis that HA can tie everything together anyway).
Like I say, if there’s any errors coming up from your journalctl output it might give you somewhere to start for a fix, if there’s literally just the line where it sends the audio and then nothing I think you’re a bit stuck tbh.
I have been using a Google Chromecast audio with my HASSIO 0.60 currently running on a RPI3 for TTS features for about 6 weeks with no issue at all. 3 days ago, I installed LetsEncrypt for more security and because I was working on custom Alexa voice control with HASSIO. AS SOON as I enabled LetsEncrypt with no other changes to HASSIO, the TTS feature of the Chromecast Audio stopped working. Just as reported above, It gives the wake up chime, but no TTS read out. I uninstalled LetsEncrypt and the TTS feature began working again. I am not running LetsEncrypt for now, so that I can use TTS. This has become an issue, because I cannot implement my Google Home Mini or custom Alexa commands, because they both require LetsEncrypt to be used. For now I am using Alexa through the emulated Hue function which limits me to On and OFF commands only. On a side note, my Squeezebox does still work with TTS with Encryption enabled.
For tts cache folder
I tried /tmp/tts but the tts mp3 does not get written.
It plays when generated in the frontend google mini media player gui but no mp3.
I have it in /config/tts didn’t make a change on the folder permission. Works now.
I tried your solution and it didn’t work for me. But I just found the reason it is working for you and not for me. I followed the instructions on this page and got it working. This is also the reason that it is broken for everyone else that can’t get it to work. I found the following post on another thread. Here is a link to the post that explains it. Look for the post by “Andres_Arenas_Velez” near the bottom of the page posted on Aug 17th 2017. TTS not working with LetsEncrypt
I enabled NAT Reflection on my router, and it is now working great.
I’m late to the party on this and it’s probably unrelated, but I just moved from hassbian to a Windows PC with VirtualBox /Ubuntu/Docker and lost my TTS. I have been struggling with it for a few days until I just realized that my base_url value was incorrect. A simple thing, but I’d overlooked it.
If you are using SSL certificate or Docker, you may need to add the base_url configuration variable to your http component as follows:
#Example configuration.yaml entry
http:
base_url: example.duckdns.org
The base_url configuration variable was added in 0.35.1, so make sure your Home Assistant version is 0.35.1 or above.
I have NAT reflection enabled
I also have set my base_url to the IP I use to access Hass externally
After a reboot of Hass, I get the Ding and then nothing. The message I sent doesn’t get spoken When I open the Google Home app, and choose the device I tried to cast to, it shows the Stop Casting option. It appears it didn’t receive the casted item and/or thinks it’s still casting. If I click Stop Casting nothing happens.
When I restart Hass, it’s the same pattern as above.
Anyone got any update on this?
I have same issue with my google home and the TTS from Home-Assistant.
First after a reboot i hear a ding then after that nothing happens…
I’m pretty new to this so sorry if it has been answered.
Looks like it is not possible to solve this issue when you use SSL with HA for Google Home devices seen these devices have their DNS settings hardcoded. At least with my internet provider’s router I can’t change DNS settings (which would not solve the Google Home going straight to 8.8.8.8 anyway) and can’t use port mapping on the router either as the rules are only managing outbound to inbound, and not inbound to inbound.
It’s got something to do with NAT reflection / hairpin / loopback I was trying to sort this out yesterday but eventually I gave up. Anyway now you have something to Google, if you get it sorted please let us know. (Hint, some people just enabled NAT hairpin in their router settings and it solved the problem so it’s worth trying that first) - didn’t work for me on my Ubiquiti Edgerouter but you might be lucky!
@aherbjornsen When SSL is switched on (for secure external access without VPN) it’s often necessary to do some port forwarding (443) to get it all working, this port forwarding seems to affect internal devices and stops TTS working on Google Home. Some people find that NAT hairpin works but it didn’t for me.
It has to do with SSL in the sense that the root URL in configuration.yaml must reflect the hostname and not internal IP. Having the hostname set and considering the Google Home has its DNS hardcoded, the GH will resolve the hostname to my external IP, and my router doesn’t allow NAT loopback (or NAT hairpinning).
I don’t remember how I solved this but I’m currently using Google TTS through Chromecast Audio devices with Hass.io on RPi3 and the DuckDNS addon. I have a ASUS RT-AC66U router running Asuswrt-Merlin firmware. I can use https and get TTS notifications.
@n0ir, If you read the title and/or previous messages, you will see that it’s already known to work with Chromecast. The problem is with Google Home devices.