This is the correct way to fix the issue. Nothing else needs to be done. Insert the base_url with the LAN IP (change to https if you’re using SSL internally) of HomeAssistant.
1 Like
Correct. If my router supported loopback, I probably wouldn’t need NGINX.
However, I like that NGINX keeps the SSL business separate from Home Assistant.
If you have https://.... and ssl certificates in your http: section of config, all access to home Assistant is forced to use ssl.
If you’re using https and your router does not support NAT loopback, Google will Not be able to access the address if you use the duckDNS address OR not be able to validate the certificate if using the IP address.
You only need to go the NGINX route if your router does not support NAT loopback… AND you want external ssl
1 Like
So, since I access HA from outside only via VPN (I don’t like ports to be opened to the outside!), NGINX is not needed, right?
My other question is, when I connect thru VPN and HA does not have SSL active, the traffic to the internet is encrypted because of the VPN or is clear?
Sorry for little OT…
Thanks
You can leave ssl off completely (no https:// or ssl certificates in the http: section), leaving home assistant unencrypted. as your VPN secures the connection. Then just use http://IP_ADDRESS:8123 in the tts config
Ok, thanks
even without the base_url in the tts config, it works, if no SSL is active
ideal! it’s the SSL and lack of loopback that causes most of the problems!
When I try this config, I see this error log with a http 404 and I can’t get to https://translate.google.com/translate_tts in my browser either(but https://translate.google.com does work). Does this TTS google_translate still work ?
2019-08-03 13:56:59 ERROR (MainThread) [homeassistant.components.google_translate.tts] Error 404 on load URL https://translate.google.com/translate_tts?ie=UTF-8&tl=en&q=&tk=270938.164768&total=1&idx=0&client=tw-ob&textlen=0
2019-08-03 13:56:59 ERROR (MainThread) [homeassistant.components.tts] Error on init TTS: No TTS from google_translate for ''
platform: google doesn’t exists anymore…
Correct it’s been updated to google_translate
You guys need to start reading the changelogs (release notices) before updating your HA.
here is the solution for most of you:
- Open your automation.yalm with notepad++ (or any other)
- Highlight any “tts.google_say”
- Press “Ctrl H” (on notepad++)
- Replace with “tts.google_translate_say”
- Click Replace all
- Go to “Configuration” on your HA webui
- Select “Server Controls”
- Click “Check Config” (if it comes back with error… fix it. you might have misspelled something)
- Click “Reload Automation”
That will fix most of your problems.
Hi! I have a problem related to this.
I had a working configuration with google tts which stopped working after configuring remote access using duckdns. My router does not allow Nat loopback, so google tts in google home mini was not working.
I have installed NginX, configured my domain from duckdns, removed key certs from http in configuration.yaml and added the local http ip to base_url in tts in configuration.yaml.
After reboot tts was finally working from UI. But now I cannot access to Home Assistant using my remote duckdns domain.
Did I miss any step?
you now need to make sure that you’ve got the ports for NGINX forwarded in your router, so 443 and 80 to 443 and 80. Do not open port 8123
1 Like
Thanks for the prompt response. Now I can remotely access to my system and play tts. However I have some questions
I have opened the port 443. But I could not open port 80, I think is blocked or something because im not allowed to include the rule into the router. What is port 80 for? Yet, I’m able to open HA UI using port 8123 when in lan, I don’t really understand it very well.
Since port 8123 is no longer open, now I have to use https://my domain.duckdns.org:443 is that right? I realized that google assistant integration was not properly working. After modifying the port I can use it again.
Thanks again!
It will work without port 80, so leave it without. I can’t remember the settings for the NGINX add-on at the moment, as I’m now using the community NGINX proxy manager instead, but if you connect to http on port 80 nginx proxy can force redirect to https on port 443.
Also, if you’re accessing from outside your network, you shouldn’t need to use the port number, as https automatically assumes 443. So you should be able to just use: https://yours.duckdns.org to access your instance.
If you’re accessing from inside your lan, if you try to connect using the local address and port 443, the ssl certificate does not match the typed address, so it doesn’t work, so you will have to use the local address and port 8123, unless you set up a DNS service on the lan:
If you use the pihole or adguard add-ons, they both have dns rewrite options, so you can configure yours.ducks.org to point to your local ip. but you either have to configure all your devices to use the add-on for dns, or set your router’s dns settings to point to the add-on. If you do manage to do this, you can then access using https://yours.duckdns.org inside your lan. Local address on port 8123 will still be accessible from inside the network as well.
Effectively, using either add-on, if you’re connected to the lan, yours.ducks.org is looked up from the addon’s DNS, which simply points the browser to the local ip. Nginx then receives the request on 443, and serves the http page. Https still works, as it sees the correct address.
I think I may have to do a video on this question, as it keeps popping up!
1 Like
thank you for your video explanation. a few days ago changed my entire config from duckdns/letsencrypt to my own domain and nginx/cloudflare; after that googgle tts stoped working.
this tip fixed it .
tts:
- platform: google_translate
base_url: http://192.168.1.100:8123
that’s right, it will work with a private domain also.
I’m using a private domain which allows ddns. My ddns ip address is updated using a home assistant rest command whenever my public ip changes, then I use the community add-on NGINX proxy manager to keep my ssl cert up to date and manage routing
once again thank you. I have a similar set up, but followed up some advice on using cloudflare. The free tier provides a 15 year ssl. so no hassle with authentication and validation. just create it and put inside your nginx conf.
1 Like