Hass.io 0.75.1 and earlier: No web interface on port 8123, no network connection for docker image "homeassistant"


currently, my HASS.IO instance (running on a Raspberry Pi3 B+) is near to useless. It happend out of the blue, without a configuration or hardware change. I simply had to restart my router, and then restarted my Raspi, too. This happened under 0.74.2. I upgraded to 0.75.1 using the CLI, no change.

To cut the following short: I believe this has something to do with the “homeassistant” docker container’s network connectivity, because of the following symptoms:

  • No web interface on port 8123 (neither locally, nor over the Internet).
  • The rest of the system, including add-ons and their web interfaces (e.g. mopidy) are working fine.
  • I also get output in “home-assistant.log”, showing a normal startup of the system, except
  • No Rest sensors work - HA simply can’t reach them, timing out.

I did some digging around. “docker ps” on the host system (Resin OS) seems to prove for me that the docker container can’t bring up its network connection, while others can:

CONTAINER ID        IMAGE                                         COMMAND                  CREATED             STATUS              PORTS                                            NAMES
648325afa015        homeassistant/raspberrypi3-homeassistant      "/bin/entry.sh pyt..."   33 minutes ago      Up 33 minutes                                                        homeassistant
9931fafe79ce        hassioaddons/node-red-armhf                   "/init"                  5 hours ago         Up 5 hours                                                           addon_a0d7b954_nodered
577f162cc025        bestlibre/armhf-mopidy                        "/run.sh"                5 hours ago         Up 5 hours>6600/tcp,>6680/tcp   addon_53caca22_mopidy
0b75bb8447f1        hassioaddons/appdaemon3-armhf                 "/init"                  5 hours ago         Up 5 hours>5000/tcp,>5050/tcp   addon_a0d7b954_appdaemon3
cadd32585672        homeassistant/armhf-addon-google_assistant    "/run.sh"                5 hours ago         Up 5 hours>9324/tcp                           addon_core_google_assistant
26a100914d8a        homeassistant/armhf-addon-ssh                 "/run.sh"                5 hours ago         Up 5 hours>22/tcp                               addon_core_ssh

Another hint is the container’s behaviour when starting up in debug mode:

core-ssh:~# hassio -d ha start
DEBUG [CmdHomeassistant]: action->'start', endpoint='start', serverOverride->'', GET->'false', options->'', rawjson->'false', filter->''
DEBUG [ExecCommand]: basepath->'homeassistant', endpoint->'start', serverOverride->'', get->'false', Options->'', Filter->'', RawJSON->'false'
DEBUG [GenerateURI]: basepath->'homeassistant', endpoint->'start', serverOverride->''
DEBUG [RestCall]: data->'http://hassio/homeassistant/start', GET->'false', payload->''
DEBUG [RestCall]: ResponseBody->'{"result": "error", "message": null}'
panic: interface conversion: interface is nil, not string

goroutine 1 [running]:
panic(0x2c7050, 0x1070a2a0) /home/travis/.gimme/versions/go1.7.6.linux.amd64/src/runtime/panic.go:500 +0x33c
github.com/home-assistant/hassio-cli/command/helpers.DisplayOutput(0x107e8000, 0x24, 0x200, 0x0) /home/travis/gopath/src/github.com/home-assistant/hassio-cli/command/helpers/common.go:118 +0x3c8
github.com/home-assistant/hassio-cli/command/helpers.ExecCommand(0x2f6f83, 0xd, 0x7ec42e61, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) /home/travis/gopath/src/github.com/home-assistant/hassio-cli/command/helpers/common.go:155 +0x308
github.com/home-assistant/hassio-cli/command.CmdHomeassistant(0x10786420) /home/travis/gopath/src/github.com/home-assistant/hassio-cli/command/homeassistant.go:48 +0x540
github.com/urfave/cli.HandleAction(0x2af768, 0x324b14, 0x10786420, 0x0, 0x0) /home/travis/gopath/src/github.com/urfave/cli/app.go:503 +0xf0
github.com/urfave/cli.Command.Run(0x2f6f83, 0xd, 0x0, 0x0, 0x40bd10, 0x1, 0x1, 0x301e4d, 0x2f, 0x0, ...) /home/travis/gopath/src/github.com/urfave/cli/command.go:165 +0x6b8
github.com/urfave/cli.(*App).Run(0x107708c0, 0x1076a080, 0x4, 0x4, 0x0, 0x0) /home/travis/gopath/src/github.com/urfave/cli/app.go:259 +0x8b0
main.main() /home/travis/gopath/src/github.com/home-assistant/hassio-cli/main.go:22 +0x108

The only hint that I could get from various (otherwise unrelated?) forum posts was the suspicion that this could have something to do with hass.io’s DNS resolution, and (maybe) appArmor. Following this suspicion, I noticed that the homeassistant container (and the only other one affected by this, Code Red) seem to have the first of the following 2 lines configured in /etc/resolv,conf, while all others have the second:

  1. Working: nameserver
  2. Not working: nameserver

Any ideas? Either on how to fix it, or how to find out more?

Short update: I (sort of) got it fixed, but don’t know for sure how. So this is just a possible solution for people experiencing the same. And me asking for them to contribute similar experiences here.

Weirdly enough, this seems to have something to do with the Chromecast discovery. Even when the system (UI) didn’t come up, I noticed a lot of failed chromecast discovery errors in the log. I put this down to the network connection not working (see above). But somehow this must have been effect and cause at the same time.

This is what I figured out so far:

  • Did a clean install with the newest hassOS 1.9. The system came up without problem.
  • Restored my last snapshot, restarted: Same failure a described.
  • Clean install again, and then I added add-ons etc. on by a time, and rebooted every time.

Result: Every time I let the system automatically add chromecast devices (two Google Home, and one Chromcast in my network), the web GUI wouldn’t come up again on the next reboot.

Quick fix: Erasing .storage/core.config_entries (or, for people have more than just chromecast configs there, probably just one entry) resetted the chromecast config, and brought up the system again.

However, currently the system is running well. I put this down to my FireTV 2 stick, where I had an App installed and activated that enabled Chromecast on that device. My current theory is that this halted the hass.io startup process due to incompatible behaviour somehow. Still have to validate that theory when I find the time. But now, having the app on the FireTV deactivated, everything seems back to normal.

Exactly as you mentioned all of a sudden 8123 become unaccessible however I was still able to access to configurator thru 3128.
Deleting the chromecast entry in .storage/core.config_entries fixed the problem.
Thanks a lot!

I found this page by sheer chance! Spent all night until I did. I had upgraded to latest hassio then could’nt get back onto home page. Deleted the Google Cast instance in.storage/core.config and all working again. This is so painful I may go back to Smartthings!! Thanks though