I am trying to use Google TTS on Sonos speakers. The speakers are unable to play the created TTS files as they are trying to connect to the external Home Assistant URL. Everything else works; I can control the Sonos, plan and stop Spotify music and other radio stations from the HA companion app both externally and internally.
About my configuration:
I have a docker install of 2023.11.0, the container is in bridge mode so no port restrictions.
Externally, the URL comes through a reverse proxy that translates the port number (49000 → 8123). Internal clients connect directly using the standard port.
SSL is enabled with certificates from Let’s Encrypt. These are manually created (CN = server.mydomain,com, not DuckDNS) and the server correctly resolves internally and externally with no certificate errors.
I understand TTS previously had a base_url configuration option (https://github.com/home-assistant/core/pull/94905) however that was depreciated in favour of global internal / external URL config.
Questions:
Is there a reason that TTS would direct the Sonos to use external URLs?
I am pretty new to HA so may need a sanity check on this, do internal clients need to be able to access the external URL internally for TTS to work?
So I decided to dump Google go fully internal with TTS. I now have a Coqui docker instance and MaryTTS integration. Even with TTS fully internal (and working fine in the browser) the Sonos was sent to the unreachable external URL.
I came across the following post which referenced the depreciated base_url option. It suggests that the internal URL would be used by default, which would have been my expected behaviour:
Can I ask anyone successfully using Sonos for TTS, do the media files get served from the internal or external URL? I still don’t know if I am chasing a configuration issue, bug or this is expected behaviour.
You linked to my post from 2.5 years ago. Unfortunately HA and TTS has changed enough that my post doesn’t help now.
I do have TTS and Sonos working. When TTS or even a media play command is sent to my Sonos it is sent my external URL. If I remember, Sonos requires HTTPS links in order to play anything sent to it. Sonos will not play HTTP or local network links. My HA is setup with SSL with a certificate signed by Let’s Encrypt. My internal and external URL are the same and I use a DNS redirect in my router the loop back my HTTPS URL to the internal network device which satisfies the Sonos HTTPS requirement.
Thanks for the reply, didn’t realise you would get pinged by me linking your post! I really appreciate the sanity check and will adjust my network and config so both URL’s are accessible. Please correct me if I am wrong; from a functionality standpoint there is no reason to have an internal and external URL that are different? I found references to some devices that don’t have enough power the use HTTPS when communicating to the HA server, but nothing else significant.
I wonder if it is worth me suggesting a change to the documentation on TTS? As a new user it was hard to understand that an external URL had to be accessible internally for an internal service to work. I kind of wish instead of depreciating base_url it had been changed it to something like ‘use_external_url’ with a default of ‘true’.
No worries at all. Unfortunately I’m not well versed enough in SSL or HTTPS to know how to answer. In my personal experience I don’t think there’s any reason to have a different internal and external URL. In fact if I try to access my HA server by its local network address, it fails the connection (because SSL is enabled) and if I try to access it via HTTPS but using the local address, it gives me a certificate mismatch error (as well it should because the certificate is for the FQDN, not the internal address). So I’m pretty much forced to use only an external address. If your router can do hairpin NAT or redirect a FQDN to an internal network location, then just setup HA with an external URL only. I can’t speak on Proxy servers but I think they essentially do the same thing.
I highly suggest your internal and external url to be the same. Your certificate only matches a particular hostname. If you want different urls you certificate will need to be registered to a SAN for the new hostname. It’s easier to just make them the same, then in your internal network use an internal dns to resolve your internal hostname to its internal ip
Yes, already done and that’s what I said above. My internal and external URL are the same and I use a DNS redirect rule in my firewalla to point the external to internal while on my LAN.