core: Home Assistant UI not starting fully in 0.83
Home Assistant release with the issue: 0.83
Last working Home Assistant release (if known): 0.82.1
Operating environment (Hass.io/Docker/Windows/etc.): Raspberry PI with Home Assistant installed in a virtual Python environment
Component/platform:
Description of problem:
I upgraded a working 0.82.1 Home Assistant to 0.83 and can no longer access the UI using Nginx. Existing Nginx configuration worked fine before the upgrade and I did not change any configurations in Nginx or Home Assistant, I just upgraded Home Assistant. Home Assistant does not log any errors and seems to start OK. Nginx shows 502 bad gateway, see full Nginx log in additional information.
Edit: It seems that Home Assistant does not start fully and the issue is not with Nginx at all. Starting Home Assistant in the virtual environment I can see that the port 8123 is not beeing used, but the log file does not indicate any errors.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
http:
base_url: ha.thishasbeenreplaced.com:443
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- ::1
trusted_networks:
- 127.0.0.1
- 192.168.0.0/24
- ::1
- fd00::/8
ip_ban_enabled: true
login_attempts_threshold: 5
Traceback (if applicable):
Additional information: Nginx configuration:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
# Update this line to be your domain
server_name ha.thishasbeenreplaced.com;
# These shouldn't need to be changed
listen [::]:80 default_server ipv6only=off;
return 301 https://$host$request_uri;
}
server {
# Update this line to be your domain
server_name ha.thishasbeenreplaced.com;
# Ensure these lines point to your SSL certificate and key
ssl_certificate /etc/letsencrypt/live/ha.thishasbeenreplaced.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ha.thishasbeenreplaced.com/privkey.pem;
# Use these lines instead if you created a self-signed certificate
# ssl_certificate /etc/nginx/ssl/cert.pem;
# ssl_certificate_key /etc/nginx/ssl/key.pem;
# Ensure this line points to your dhparams file
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
# These shouldn't need to be changed
listen [::]:443 default_server ipv6only=off; # if your nginx version is >= 1.9.5 you can also add the "http2" flag here
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
proxy_buffering off;
location / {
proxy_pass http://localhost: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;
}
}
Nginx logs:
2018/11/29 22:27:21 [error] 5054#5054: *188 connect() failed (111: Connection refused) while connecting to upstream, client: ::ffff:192.168.0.150, server: ha.thishasbeenreplaced.com, request: "GET /api/states HTTP/1.1", upstream: "http://127.0.0.1:8123/api/states", host: "ha.thishasbeenreplaced.com"
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 6
- Comments: 28 (12 by maintainers)
@timstanley1985 Thanks for the info.
After upgrade configuration.yaml from:
to:
Home-Assistant works again.
@azuwis This is the correct answer. The issue appears to be two-pronged:
Thank you first of all for all the hard work. Here comes what I hope some feedback that would not be taken as an insult.
If so many of us failed to understand that the owntracks configuration syntax were to break the startup of HASS and cause the upgrade process to fail — In many cases without any WARNING or ERROR at all in the logfile. I would like to state that the “breaking change” was not clearly written for us already using owntracks. I was myself clueless for quite a few hours hence there were nothing to point me in any directions of the error it self.
So no, it was not made clear as a breaking change. How ever, further down the rest amongst the changes there is a statement of configuration change.
Again, its easy to to sit here, not being part of the development team and though a hizzy fizz… I know there is soo much hard work behind each release. I would really be appreciative for a more clear “breaking change” statement for similar changes next time.
Thanks! ❤️
At least for me, I can confirm that it doesn’t appear to be listening on 8123 when using the docker image:
I had this problem and it turned out to be due to the breaking change to Owntracks in 0.83. Once i removed Owntracks from my config Home Assistant loaded normally. You have to use config flow to set up Owntracks now… but that is another issue as my two mqtt owntrack devices aren’t showing up 😦
There hasn’t been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
owntracks is not the only problem. Many things got messed up after this 0.83.1 upgrade. Vera plugin (lights not responding), Phone localization when using waze of google maps… Finally I reverted back to 0.82.1
If you remove your owntracks configuration from your config, and upgrade to 0.83.1, it will load Ha normally, then you can integrate owntracks again. worked for me!!