With 0.110. internal_url and external_url were introduced to the configuration. The screenshot in the blog entry shows the external_url being https:// with a domain name and the internal_url being http:// with an internal IP. In practice, I have found that what the screenshot shows is impossible.
When https is enabled the port hass is bound to will no longer serve unencrypted traffic. Entering https:// with the internal IP address, will cause whatever client connecting to fail with a SSL certificate error because the certificate’s common name will belong to the domain name of the external_url and not the internal IP address.
Unless I am mistaken, with under most circumstances unless you have a wildcard SSL certificate https the internal_url and and external_url will have to be the same.
I suspect so, it broke my tts when internal was set to something internal, http or https. I’ve had to set the internal address to the external address or tts doesnt work, leaving it blank is also no good.
It depends on your setup. It can have value in more complex setups. In general, one does not need to set them, unless there is a specific reason.
The screenshot was taken from my personal system btw (obviously masked my external domain). Nevertheless, in my case, Home Assistant runs without SSL, no HTTPS.
However, I do use an add-on that provides a reverse proxy (NGINX), which adds SSL for the outside world with my duckdns domain.
So in those cases, one can now specific how HA runs locally versus externally.
The problem before, with just base URL, it that that distinction could not be made, which caused a whole other level of problems.
So what to hold on to?
If you run SSL in HA itself, set the external_url, leave internal_url empty. As you don’t have a explicitly different internal URL.
I used TTS to provide feedback on my Alarm functions after they were set. I too noticed that I no longer get any voice notifications via Sonos. I too set the internal_url and external_url as the same since I have SSL access. Still did not work. Left base_url in the TTS configuration and left it out … and on an on. Could you tell me what you did to get TTS functioning again in scripts and/or automations? I’m out of any ideas. Thank you in advance.
I got this resolved by setting the internal URL to http://YourDomainName.org:8123 and setting the base_url in the TTS configuration to the SSL external URL.
I’ve left the outside URL set to my outside address, and removed the inside one (its a bit useless a lot of stuff wont accept self-signed certs internally anyway.
Then as you mentioned above, I then set the base_url: in the tts services. This seemed to work ok.
I agree with you. It makes no sense if you have a certificate, and therefore an external facing URL, to need an internal URL since you cannot do anything with it.; you cannot even access your HA instance internally once you make it public facing.
I have a certificate from Let’s Encrypt and that is viewed as not self-signed. However, until I put in my internal address with the ubiquitous 8123 HA port my TTS did not work even with a base URL set to the external URL in the TTS configuration. HA must do something with the internal URL but I have no knowledge of the internals of the product so cannot venture a guess. I very much appreciate you taking the time to respond. Take care.
I have HTTPS internally and externally but internal is self-signed and the HA android app wont work with that, neither will Google Homes. So I’ve still had to expose an internal HTTP page.
I just wanted to let you know that TTS is broken again on my end. Sonos complains that the connection to my domain is lost. But sometimes it works. I have no idea why.
I cannot get this to work petro. As soon as I set the ip source and dest port to 443 I’m done. Previously I had 443 as a source port and 8123 as the destination port. Nginx claims it is running. Wehn I set the ports back Nginx breaks. Any thoughts? As an FYI my house is set to a static IP; it’s required by my ISP for security… I do not know if the configuration took that into account.
I found this article at konnected.io useful to get this working. It illustrates a good use-case as well. When using SSL motion sensors connected to the konnected board have a 2-3 second response time. Without SSL they are instantaneous.