Home assistant add-on is broken

[baal86]

The home assistant add-on is broken at the moment. I added this GitHub repo to my add-on repositories in a home assistant OS install. The add-on does not show up in the store as usual. I run multiple custom add-ons from GitHub and they still work.

The line image: ghcr.io/fignew/marstack:0.2.2 in config,yaml appears the be the initial problem. If I temporarily remove it, the add-on shows up in the store and I can start a local build of the docker image. This then fails because the supervisor does not like the symlinks for Dockerfile and icon.png.

I stopped trying to fix it for now since I don't have a lot of experience with docker unfortunately.

[mail2ms]

The home assistant add-on is broken at the moment.

Unfortunately I have the same problem...
Just for testing purposes I'm running MarstACK on a separate second machine... That works.
But for a permanent solution I need to integrate it in my Home Assistant.

Would be great if this can be fixed.

[fignew]

Thanks for opening this issue. I never finished setting this up as a Home Assistant Addon. I will resume working on that to make it easier for people to use.

I have been working on other aspects of MarstACK including Jupiter C support, and some other improvements which I'll also make public soon.

[baal86]

Great! looking forward to it. If it is known to need some extra work I might sit down and try to fix it. That’s in case I will run it on the same raspi as home assistant and not on a separate device that can then directly take care of the DNS man in the middle without messing with the rest of my network.

[baal86]

OK, I did a bit of a deep dive. Played around it in this little fork of mine: https://github.com/baal86/MarstACK. (don't use! It's nasty) I discovered:

• I could not get the pre built image going. Only local build.
• Home assistant Docker build will only reference files in the ha_addon folder. So everything needs to be inside that. Symlinks are not allowed either. The fork hacks the structure so that it build as an add-on.
• Home assistant does not allow exposing an add-on on port 80. Only non-privileged ports or through ingress. Both options useless for the purposes of MarstACK.

So I fear running it on HA OS will not be possible.

[hoferbeck]

@baal86 I also tried to get the Home Assistant app running https://github.com/hoferbeck/MarstACK

As I'm also running the Nginx add-on on Home Assistant, I used that to expose the MarstACK container to port 80 (example conf).
But it should be also possible to let the container listen on port 8000 and point an external Reverse Proxy to it
I'm simply using the Dockerfile in the root directory and therefore skipping the problems with the symlinks.

Also added the code from #7

[baal86]

Ah, great idea. Yes, the nginx app should be able to expose port 80 since it is an official app. I will try that later.

I would still consider the user experience of the home assistant app to be broken as it is right now. Does anyone know how hard it is to get an app into the home assistant app registry officially since that would solve the issue with a bit of work on our side to streamline the image? Or are there legal concerns with the reverse engineering bit of Marstack? (not legal everywhere? Certainly fine in the EU)

Personally I am currently lucky to run old firmware on the batteries that don’t need to phone home constantly but a low effort way to install would be nice. Just pulling the Marstack and DNSmasq (needs 1-liner config) apps on HA and then changing DHCP in the router would be sweet.

[hoferbeck]

I wouldn't call it broken. For example, for hm2mqtt the same steps are needed to add the repo, and it's pretty easy via this link:
A nice-to-have that is missing at the moment is support for the custom options.

I also don't think there are legal issues, as the "reverse engineering" is simply listening to the network traffic and checking what happened, since the traffic to the "real" eu.hamedata.com is via port 80 (unencrypted).

[baal86]

Hmm. Ok I was not referring to the fact that you have to add a GitHub repo to the app “store”. That’s pretty common. If that works nicely now it’s great progress already!

Don’t get me wrong, it’s perfectly usable, just thinking if configuration can be improved for the user to keep the number of “extra steps” to a minimum. Trying to reduce the points of failure as well where my family is out of internet because of me.

Extra step number 1 is dns redirect. That’s absolutely mandatory. In good routers you can just set it per domain but ISP routers (Fritz box!) don’t support it so you need DNSmasq and do a blanket redirect. That’s another point of failure. (DNS now dependent on HA running)

Extra step number 2 is what I want to brainstorm now. In an ideal world the container would just expose port 80. For that the adding would need to become official. The current alternative is nginx which is needs to be configured separately.

In the end it’s just semantics. Maybe the addon currently does not fulfil what’s promises “on the box”? So we could document the use of nginx clearly? Still interested what the way to make an addon official is …