Thanks for that information. I’ve learned that the BUILD_ARCH & BUILD_FROM are internally getting arguments from a build.yaml file & a config.yaml or config.json file that, unlike traditional Docker, set arguments for the build not just runtime. I’ve still yet to learn how Supervisor gets which argument, but I assume it’s a default set by the version that Supervisor itself uses, so if Supervisor is AND64 it passes that to every $BUILD_ARCH call, & the BUILD_FROM is essentially the same thing, except it has a “if AND64 use this link, if ARMHF use this link, if ARM7 use this one, etc”
From another thread I learned that apparently you’re using a tool called Ingress from the Frigate Proxy add-on & the part that adds the integration. Hopefully I’ll be able to get this to work as a standalone Docker Container
Sorry, typo, AMD64 was intended. Since it happened multiple times it was probably Autocorrupt & I didn’t notice.
You did, but you referenced an entire manual in a statement saying “they do more” & “supervisor supervises” & gave a link that said
Add-ons for Home Assistant allow the user to extend the functionality around Home Assistant. This can be running an application that Home Assistant can integrate with (like an MQTT broker) or to share the configuration via Samba for easy editing from other computers. Add-ons can be configured via the Supervisor panel in Home Assistant.
Under the hood, add-ons are container images published to a container registry like GitHub container registry and Docker Hub. Developers can create GitHub repositories that contain multiple add-ons for easy sharing with the community
Then had a tutorial on making an add-on…
All that in response to “Why not have an add-on repo”… Which didn’t really answer the question.
In another forum I was pretty much told that Ingress (& config/build formatting) is almost solely what separates Supervisor from Docker. & specifically that that Frigate Proxy is utilizing Ingress & when I mentioned someone modifying it to use for a different URL was told essentially that they were just using Ingress from the container.
I’ll look more into it once my next billing cycle starts (as I’m already over my monthly cap this month). But how I do that, or if I will actually be able to with my modest skills, is still TBD. I may try to make an independent supervisor stack to run in regular docker & use a Portainer-like manager so it can run any add-on for a Docker HA, or it was suggested possibly making a Dockerized Ingress agent that could be slapped over a regular Docker Container & essentially give them the thing they lack from a HA side while retaining their superiority otherwise, then all other configuration will just have to be done manually &, so I’m told, it will make the Supervisor unnecessary.
I’m not sure which direction I’ll go, but most likely whichever seems easier or has the least steps requiring things I’m not skilled at. Either way I’ll share the results as either should be appropriate for this thread’s goals
Thanks. That should be helpful if I take that path. But it’s, again, an add-on, so it will still have to be dockerized, but it’s definitely nice to have a cleaner source to reference
This was sounding promising but I can’t get it working. I just end up with a blank screen after clicking ‘open wen ui’
addon log
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-banner.sh: executing...
-----------------------------------------------------------
Add-on: Frigate Proxy
Proxy addon for Frigate
-----------------------------------------------------------
Add-on version: 1.3
You are running the latest version of this add-on.
System: Home Assistant OS 9.4 (amd64 / generic-x86-64)
Home Assistant Core: 2022.12.8
Home Assistant Supervisor: 2022.12.1
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[cont-init.d] 00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing...
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] nginx.sh: executing...
[cont-init.d] nginx.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[14:38:37] INFO: Starting NGinx...
I actually dug into this as well, ever since I migrated to a Docker installation and…actually have found the way to make it work using nginx proxy manager (either add on, or seperate docker). Here is how it works:
In NGINXProxy manager, you start with creating your proxy host as explained in the installation guide here:
After that, you need to create a rule for the location you want to access through https. So go to the “advanced” tab of your proxy host and enter a custom location with this code:
So this basically creates a rule, which forwards all requests to: https://yourdomain.duckdns.org/panelname to your network internal (non secure) http adress. But…since it goes through NGINX it is served as a secure site to the outside world.
Then, in your configuration.yaml you enter the panel_iframe like such.
I have got most things working flawlessly like this, just have a tiny issue left with the Duplicati container in my case, but most things like Zigbee2MQTT, Portainer, Configurator, Vaultwarden etc work flawlessly like this and I can access everything externally.
Hi, I also migrated my installation to docker standalone installation. Can you please share you config, ie. docker-compose file for nginx or give some additional info how you set this up.
Edit: Got it, it does work great. Maybe I latter wrote some my config just for people to find it.
I use dynu for my domain. Set up for ssl is really easy. Just grab ssl key from site and and replace token in a line
dns_dynu_auth_token = YOUR_DYNU_AUTH_TOKEN
I tried to open z2m over nabu casa using iframe and it does work. This is great, this is the thing I wanted to do for a few weeks. Some setups are more complex that others but this setup mention by @Remko is easy and this work great.
Thank you for sharing.
Hi. I applied your code and it is working with esphome and portainer but for frigate container it is not. Could you please help me to solve it? Thank you.
and have full access because you’ve served it. Yes, it’s https: so nobody in the middle can interpret it, but whoever is attached can control whatever was served. Try it by opening a browser that isn’t logged into your instance of HA- put that in the browser. Which you may not care if it’s just your holiday lights or something.
Also, for anyone trying to do this with Logitech Media Server, it won’t work (something about local files).
Yeah @fmon is damn correct. I found out it today also. I may browse my frigate instance even without login into HA. Thats really bad. USE IT ONLY ON YOUR LOCAL SERVER.
Create authentication for the separate containers. For example Portainer or Z2MQTT are easy, they allow you to define a separate login. I don’t expose frigate to the outside, rarely need that webpage, the integration offers all I need.
Accessing that I do just in my internal network with a bookmark in my browser to the local ip:port
I would say name the panel a very long string of random characters similar to a client secret but I think that unless you have cutting-edge encryption running the headers are unencrypted even with https: and might be intercepted.
So I guess we try what @Remko said