Home Assist, Google Speakers, Piper or Google Text to Speach (TTS)

Hello everyone,

I hope I am in the right catagory.

After spending considerable time researching and experimenting, I’ve reached a point where I’m seeking your expertise. My setup includes an SSL certificate from LetsEncrypt and a fully qualified domain name (FQDN), not using DuckDNS, all of which are functioning correctly with an up-to-date certificate.

Previously, I had configured Google Text-to-Speech (TTS) to announce specific notifications through my Google speaker. However, after a certain update, the speaker only emits a chime without speaking the notifications. This seems to be triggered by Home Assistant attempting to communicate with the speaker, a behavior I’ve confirmed by observing the chime when toggling the speaker via Google Cast.

My setup includes Google Cast, Google Translate/Text-to-Speech, and I’ve also integrated Piper and Whisper with the Wyoming Protocol recently. Despite these integrations, the issue persists with both Google and Piper TTS services—only a chime sounds, with no speech following.

Despite thorough troubleshooting—including reinstallations, configuring URLs, renewing Google Projects and API keys, and reconnecting my Google Speakers—the issue remains. After triggering an automation, I checked the speaker’s state through developer tools, noting changes in its attributes but no actual speech playback. However, accessing the TTS-generated MP3 file directly through a browser plays the file correctly on my laptop.

Further testing with Home Assistants Google Cast and access to my DLNA servers I confirmed that my speaker can play MP3 files that I have, suggesting the issue might not be with file access or playback capabilities of Home Assistant or the Google Speaker. Sharing and accessing the TTS MP3 file across different networks also worked, ruling out authentication issues and SSL issues. I went as far as testing the MP3 Url on my phone on and off my WiFi network and it worked internally and externally.

At this juncture, I’m at a loss for further troubleshooting steps. I’ve meticulously followed guidance from every relevant article I could find, but the core issue—my Google Speaker not playing the TTS-generated speech mp3 URL files—remains unresolved. I’m open to sharing configurations and trying out any suggestions you might have.

Any assistance or insights would be greatly appreciated. Thank you in advance for your help!

1 Like

I’m by no means an expert - but have you checked whether both the Google Speaker and your Home Assistant instance are on the same subnet?

Yes I have and I can ping them both, and Home Assistant can ping the speaker.

If the issue is with TTS specifically, you could consider using the Chime TTS custom integration as a workaround. It can generate a TTS mp3 file (via the chime_tts.say_url service) which (as you stated ) you can play on the speaker.

I can play MP3, but the MP3 that Piper generated it doesn’t play.

I will try your suggestion it tonight and give feedback

I think Piper creates WAV files, not MP3s - perhaps this is causing the issue with you Google speakers?

from the state of the device after I try get the TTS to work:

device_class: speaker
friendly_name: Rob Room Google Speaker
supported_features: 152463
volume_level: 0.5699999928474426
is_volume_muted: false
media_content_type: music
app_id: CC1AD845
app_name: Default Media Receiver
media_content_id: >-
  https://<censoredFQDN>:8123/api/tts_proxy/25c88e061b3cce4ae39bed9689378cc12f7ef72f_zh-cn_-_tts.piper.mp3
media_position: 0
media_position_updated_at: "2024-02-13T15:52:45.718445+00:00"

definitely MP3

I couldnt find Chime TTS on addon store, add integration or under HACS

Link to Chime TTS on HACS:

Fail - does exactly the same thing.

I’m convinced its not the TTS engine as its the same with google tts, piper and chime tts.

Have you also tried using the chime_tts.say_url service of Chime TTS to generate MP3s for playback on the speaker?

I’ve managed to resolve this interesting issue TTS and wanted to share my solution for the benefit of others experiencing similar challenges. I have not gone into too much details, but if anyone needs more information I will be happy to share…

The core issue stemmed from Google devices on my network persistently using 8.8.8.8 (Google’s DNS) for DNS queries, despite being configured to obtain DNS settings via DHCP. This was problematic for local services, such as Home Assistant, which I access both internally and externally using a domain name with an SSL certificate. When local devices used this domain, the requests were routed externally due to the DNS resolution, bypassing the internal network route, which isn’t ideal.

After discovering that changing the DNS settings directly on the Google devices wasn’t an option (the functionality appears absent or removed in the Google Home app), I opted to address this through my network infrastructure. I decided to implement a solution using my MikroTik router’s firewall capabilities.

The solution involved creating a NAT rule to intercept DNS queries from the Google device to 8.8.8.8 and redirect them to my local DNS server. Here’s the MikroTik command for the NAT rule:

/ip firewall nat add chain=dstnat src-address=10.0.24.2 dst-address=8.8.8.8 action=dst-nat to-addresses=10.0.24.254

In this rule, src-address=10.0.24.2 identifies the Google device (which I assigned a static IP), dst-address=8.8.8.8 targets the DNS queries meant for Google’s DNS, and to-addresses=10.0.24.254 redirects these queries to my local DNS resolver on the MikroTik router. This setup ensures that DNS queries are resolved locally, allowing the device to correctly access internal resources using the domain name.

This workaround effectively forces the Google Speaker to resolve the Fully Qualified Domain Name (FQDN) to a local IP address, enabling it to access and play MP3 files via Text-to-Speech (TTS) as intended.

For those encountering similar routing issues with devices hardcoded to use specific external DNS servers, this approach offers a practical solution. If your router isn’t a MikroTik or doesn’t support such configurations, you might need to consider alternatives, including potentially switching to a MikroTik router for its versatile firewall and NAT capabilities. This strategy worked perfectly for me, resolving the problem at hand.

5 Likes

Thank you very much @cometrulz, worked for me after randomly breaking a few weeks ago!