I’ve been tying to get hass .io working correctly on my Orange Pi Zero. I tried it on my Orange Pi 3 and it installed and worked straight away.
My Zero handles various network and storage services on my network, so it’s logical to try to install hass .io.
I tried Home Assistant via pip in a venv. It worked fine, but no plugins of course.
Something happened during trying to get hass.io installed. There are two instances running. I checked with the tree view of htop. They are definitely separate.
Querying docker containers it says there is only one running. I guess because they would both have the same name “hassio_supervisor”
I logged into the docker container and found it was the first, incorrect attempt where I followed the wrong tutorial and tried to do it as armv7l architecture. python -m hass was just repeatedly freaking out becuase it couldn’t download what it needed.
I took a punt and stopped a/the docker container. A new instance instantly spawned.
Until I stopped that docker container there was no access to the UI. I can only guess that stopping the container caused the right one to be able to talk on the network.
So there’s my problem.
What I would like to know how to do is remove the incorrect container? I have no idea.
I’m going to make the assumption that hassio works exactly like any other docker app (and I’m pretty sure that’s a safe assumption).
What i would do is to install Portainer so you can have a GUI to manage your Docker images/containers. Hopefully then you can more easily see what you are working with and how to proceed.
I assume too that you uninstalled the original HA in the venv?
I didn’t, but I never set it up to auto start anyway. No sign of it running.
It looked a bit complex for a one off task. I found a thread on here about how to remove hass.io. I followed it and found that there was a confusing duality to things. There was armv7l and armhf stuff. I got rid of all I could, But I couldn’t get rid of the homeassistant and supervisor images. It was complaining about multiple dependencies.
I just ran the install script again, with -m armhf as I did the second time. The first was armv7l
I suspect that it’s also the reasons all plugins are listed as unavailable. I saw the valid architectures for plugins included armhf and armv7 but no armv7l.
We’ll see what happens when it finishes doing its dance and starts the web interface.
It took me a few attempts uninstalling and reinstalling to find the problem. There were lots of hass.io Docker images that I could only see when I did a Docker system prune. Only once everything was purged did the install script actually install a new image instead of just saying it was. This explains the architectural dissonance I was seeing.
This time round I just told it that it was a raspberry pi 3. It’s an armhf image so I figured it may work. It did. I didn’t need to fo any fiddling with restarting the orange pi zero or starting and stopping services. The plugins are actually available now too which is what I was hoping for.