Hi,
I constantly need to open Hassio twice, the first time it always gives me “Unable to connect te Home Assistant” --> RETRY and then when I retry it the second time it opens…
Can this be NginX related? I’m loging in with: https:…duckdns.org
Also all my automations trigger twice, I do not know if this is related?
Does this sound familiar to anyone?
Running Hassio 85.1 on RPi 3, with lovelace and NginX
I have the same log-in problem. Also using NGINx/DuckDNS
Same here.
Started getting some odd behaviour with nginx on 0.85.1. I have a proxy pass to my Kodi instance that no longer allows me to test a connection with a token (I use IFTTT to control Kodi) and I get a 404 error but Kodi commands still work through my google home. No idea how it’s still working…
It could be related to your NGINX configuration.
Does you NGINX configuration feature the following line:
proxy_http_version 1.1;
If not you may be using HTTP/2 which does not support protocol upgrade when using websockets.
Hi Florian,
Thanks for your reply.
This is my congiguration in my Hassio addon.
I dont have the line you suggest.
Where should I put it?
And what should “active” be? In my addon config its true, but now in the Home Assistant
detail page it says (bold) false?
{
"domain": "xxxxx.duckdns.org",
"certfile": "fullchain.pem",
"keyfile": "privkey.pem",
"hsts": "max-age=31536000; includeSubDomains",
"customize": {
"active": true,
"default": "nginx_proxy_default*.conf",
"servers": "nginx_proxy/*.conf"
}
}The hass.io add-on already uses this configuration internally (line 59) so you are fine and don’t have to add anything.
By setting active to true additional configuration files will be used, usually allowing you to alter/override/append the default configuration. You should set this to false if you do not use it. Don’t forget to restart the add-on after saving the option.
Since I don’t use that add-on myself I’m not able to help you with it, but I expect the add-on is already optimized to be used with home assistant (since it was built specifically for it).
I definitely would test if active: false already solves your problem. If not someone else from this community might be able to share his experience with this add-on.
When I look in NginX logs there is now this error:
2019/01/15 22:47:15 [error] 23#23: *82 connect() failed (111: Connection refused) while connecting to upstream, client: ::ffff:192.168.178.1, server: xxxxx.duckdns.org, request: "GET /api/websocket HTTP/1.1", upstream: "http://172.30.32.1:8123/api/websocket",
I’ve seen this entry also, it feels as though something in 0.85.1 has broken the nginx addon somehow, yet it still works.
Strange, I will keep investigating but I am not sure where to look.
Also all my automations keep coming up twice in my logbook.
This one is also not working anymore all of a suddon
(it should turn all the lights off at 23.45 but they are still on right now ;( )
23:45
[Alle lampen uit om kwart voor twaalf](https://xxxxx.duckdns.org/logbook#) has been triggered
23:45
[Alle lampen uit om kwart voor twaalf](https://xxxxx.duckdns.org/logbook#) has been triggeredDid you ever find a solution to this? I’m seeing the same issue.
No I did not found a solution, I still need to hit RETRY to open hassio.
The strange thing is that it is not happening all of the time…
I am using a desktop and a mobile phone simultaneously,
on my desktop I made a shortcut to https://xxxxx.duckdns.org/lovelace/0
On my mobile phone I added hassio to my homescreen.
I’ve just switched to Caddy Server instead of nginx. 10 lines of config (and 3 of that is for custom SSL cert handling). So far no double login issues, and it does seem a bit snappier.
Thanks for your reply!
Can you let us know in a few days when you have tried Caddy a little bit longer if it still does the trick?
If so, I will also change to Caddy.
In my case should it be something like this and where do I need to put this lines?
In configuration.yaml?
Is it possible to share your Caddy config?
xxxxx.duckdns.org {
proxy / localhost:8123 {
websocket
transparent
"ssl": true,
"certfile": "fullchain.pem",
"keyfile": "privkey.pem",
}
}
It’s still working fine - I haven’t had the issue I had with nginx.
My config is a little more complex because I use cloudflare in front of home assistant. I suggest following the docs at https://caddyserver.com/tutorial/caddyfile - assuming you’re fine to have a new cert, I’d also suggest not including the lines you have about ssl, certfile or keyfile, and just let caddy generate a new letsencrypt cert itself.
The config lives in a Caddyfile, not in any of your home assistant config files.
Caddy hasn’t solved the problem - occasionally I still hit this issue
I worked out the reason why these errors were appearing…
2019/06/02 06:31:53 [error] 8204#8204: *14 connect() failed (111: Connection refused) while connecting to upstream, client: ::ffff:192.168.10.1, server: mydynhost.ddns.net, request: "
GET /api/config HTTP/1.1", upstream: "http://[::1]:8123/api/config", host: "mydynhost.ddns.net:11111"
in my sites-enabled/default config file I was referencing the Hass instance by LOCALHOST. Changing to 127.0.0.1 solved the issue. Localhost resolves to an IPv6 address when responding to an incoming IPv6 from my iphone etc. By setting to 127.0.0.1 ensures we go to the IPv4 instance of HA. (as HA doesn’t do dual stack at present)
location / {
proxy_pass http://127.0.0.1:8123;
proxy_set_header Host $host;
proxy_redirect http:// https://;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}