Update Home Assistant rock-on to latest recommended settings

[FroggyFlox]

As reported by our forum user MainrtNr5, our Home Assistant rock-on needs some updating due to some limitation when using a share not-owned by root:
https://forum.rockstor.com/t/beta-cant-access-certain-rock-on-ui-opensuse-leap-linux-5-3-18-lp152-66-default-4-0-6-0/7706/5

In addition to fixing this (by removing the "uid" instruction in our json definition, we might also stick to the project's defaults as defined in their installation instructions: https://www.home-assistant.io/installation/linux#platform-installation

docker run --init -d \
  --name homeassistant \
  --restart=unless-stopped \
  -v /etc/localtime:/etc/localtime:ro \
  -v /PATH_TO_YOUR_CONFIG:/config \
  --network=host \
  homeassistant/home-assistant:stable

When comparing this to our current settings, two points stand out:

1. We should add the --init flag
2. We might also prefer to use the :stable tag rather than the currently used :latest.

[Hooverdan96]

With respect to the non-root user running/configuration shares, there seems to be an "add-on" option, but it does require a bit of pre-work. Check this out: https://github.com/tribut/homeassistant-docker-venv

The challenge will be that we either need two Rockons (one with above standard settings pointing out the root user dilemma and one with the extended ones that allow for PGID/PUID definition and non-root running of HA) or create the Rockon with the additional settings/exposed fields and create the "advanced" documentation like we have for some of the other ones ... other difference would be that the --init flag would then not be required, as the above script will drive the start of the homerun instance instead of the S6-overlay setup the way I understand it (which is the most recent reason why it needs the root under standard configuration).

Or we stick with the default setup up from HA for now and hope for better security in a future release. The net=host option will remain (like in other Rockon cases) a requirement due to the uPnP nature of some of the services that require it, and docker itself not supporting it out-of-the box.

[phillxnet]

@FroggyFlox & @Hooverdan96
I see our home assistant plugin as up-there with our Plex one. Is there something I can pop in with on this one?

[Hooverdan96]

Haven't thought about this for a while, since I don't use the HomeAssistant Rockon. I'll think about this, given a chance

[FroggyFlox]

Thanks a lot, @phillxnet , for reviving this one; home assistant is definitely an important project to be available so we should figure that one out.

Thanks a lot @Hooverdan96 too with all your crucial input so far.

I see Linuxserver.io has a home assistant image with their usual PID/PGID mapping so I wonder if this one would fix the root/non-root problem.
https://hub.docker.com/r/linuxserver/homeassistant

[phillxnet]

@FroggyFlox Re:

I see Linuxserver.io has a home assistant image with their usual PID/PGID mapping so I wonder if this one would fix the root/non-root problem.
https://hub.docker.com/r/linuxserver/homeassistant

Have just looked and we have the following.

Host vs. Bridge
Home Assistant can discover and automatically configure zeroconf/mDNS and UPnP devices on your network. In order for this to work you must create the container with --net=host.

But as per the likes of Plex this is to be expected really.

I say we take the plunge and move to the linuxserver image on this one. If nothing else but to shield us from some complexities / special treatment etc. I also think that homeassistant being one of the most popular projects on GitHub! is very important to have in our library, and in a working state.

From: https://en.wikipedia.org/wiki/Home_Assistant

GitHub's "State of the Octoverse" in 2019 listed Home Assistant as the tenth biggest open-source project on its platform with 6,300 contributors.[52] In 2020, with 8,162 contributors it was listed second place in the list of Python packages with the most unique contributors.[53]

So along with Plex this could be one of our most important Rock-ons.
Unfortunately I'm not yet a user. But I intent to be soon.

Thought's on official vs linuxserver.io ?

[Hooverdan96]

I always liked the Linux server versions because they try to focus on usability. I would say we go for the Linux server version as they are continuing to update it. And I always favor that you can easily pass a User into it.
My 2 cents.

[Hooverdan96]

@phillxnet @FroggyFlox
Hi, since the last time we interacted on this, I bought a few smart plugs and started using Home Assistant with my hand-rolled json file :). This has been working for a few weeks now, so I figured, I might as well submit it to this issue.

I chose to add it as a new Rockon, so once accepted and/or released, we can deprecate the other one (or leave it in place, if there is still use for it). If you'd rather do a straight-up replace, I can remove the original item (and its entry in the root.json) and push that change as well.
As always, let me know what you think.

[phillxnet]

@Hooverdan96 Re:

I chose to add it as a new Rockon, so once accepted and/or released, we can deprecate the other one (or leave it in place, if there is still use for it).
That seems like the way to go to me. @FroggyFlox is more guardien of this repo thought. But what you've done seems like a nice way to go. This also leaves the way clear for folks to re-add the 'official' one once it's more friendly re root users or whatever. Plus the naming makes this new pr clearer on the docker origin. And we have the same elsewhere which is nice.

I'm keen that we offer only a single version of each project myself. Given we are primarily aimed as being user friendly. And if folks are more knowledgeable they can always drop in their own preferred variant anyway.

Thanks.

[FroggyFlox]

Thanks a lot for keeping up-to-date with this one, @Hooverdan96 ; and my repeated apologies for my lack of reactivity lately...

I agree with you and @phillxnet: I think it's better to deprecate our current (official) one and add your LSIO one as a new Rock-on (as you did). It's easier for us and more transparent for users.

[Hooverdan96]

@FroggyFlox, would this deprecation go into another pull request, or should I take care of it in the one I have going with #303

[FroggyFlox]

@FroggyFlox, would this deprecation go into another pull request, or should I take care of it in the one I have going with #303

Good question... I'm always on the fence on that, but at the moment I would personally lean towards doing the deprecation in #303 as that limits risks of conflicts with root.json, for instance.

[Hooverdan96]

Ok, let's do it that way.