@LostOnline Take a look at Frigate Proxy add on
You can change this up to be your own add on, and icon, and point to services that don’t have SSL, Instead of using an iFrame option in config.yaml
That wouldn’t work for me as I don’t have the ability to use add-ons. If there’s a Docker version I could use that, but if it’s a Proxy it’s the same problem. I don’t want my things to be accessible over the internet directly, a proxy, generally, if for that purpose. Trying to find information about Frigate Proxy seems to indicate that it’s an IP Camera tool, which I have no use for.
I’m not understanding how that is related to the iframe issue
The frigate proxy, is an Nginx server, to point at another internal address that is non SSL
So for example, let’s say you only expose HA to the Internet
You add an iFrame to an internal address. 192.168.0.69
The iframe works when you are on your network, but not when you are outside of it, because clicking that iframe is like you trying to go directly to an IP that isn’t available over the web.
Where as a Nginx setup, like the frigate proxy, adds the side tab like an iframe and makes it so when you are logged into HA, you can access the page, since technically HA is loading the webpage, not you as a client outside your network.
I’ve modified the frigate proxy in my own private repo, for other services I don’t want to expose over the internet, but would like a available to me when I am logged into HA, whether outside or inside my network, but the service is not directly exposed. Like you those other services run http, and HA is https, so it won’t load http resources in an iframe.
In regards to you needing docker, just clone it, and use the dockerfile in the repo to build your image, instead of using it as an add-on, and make a docker-compose that maps the schema fields.
1 Like
That definitely sounds promising. I’m curious, I already have an NGINX proxy running, would it be possibly to add this to my current NGINX instead of running it as a separate one? If so would you be able to point me in the right direction for instructions on doing that?
Curious, I just looked at a couple other HA add-ons & the others all have a Dockerfile as well, which begs the questions, doesn’t that just mean that the versions that can run Add-ons are essentially running a literal Docker environment internally?
If so shouldn’t it be possible to run ANY addon as a Docker Container?
Assuming that is the case, why does Home Assistant make it so hard? why not just have them as a hassio/addon Repo? that would make it easier for them to be added internally as well as making it so that those running Docker could do so as well…
1 Like
Yes, HAOS and supervised can run addons, and both are running docker to run everything, HA, the supervisor, hassio-audio, hassio-dns, hassio-cli, hassio-observer and all the addons.
1 Like
Because they do more than just run a dockerised app, and you require the supervisor to, well, supervise them. see here Developing an add-on | Home Assistant Developer Docs
The Supervisor is definitely not required to run them, they run as a Docker container. Literally.
The supervisor is essentially a dumbed down simpleton version of a Docker Stack Manager like Portainer & a fancy catalogue browser.
& since, per @Deckoz2302’s explanation, it appears possible to manually add it as a regular docker container & still get it to work in Home Assistant then the Supervisor isn’t needed, it just makes it easier, I assume by adding the panels, frames, components, entities, etc from the addons instead of needing to do this manually.
Like I know the DuckDNS addon acts like the DuckDNS Docker Container, keeping the DDNS updated with the current NAT IP, but it also acts as the Let’s Encrypt agent keeping the SSL updated & instead of getting that information from Environment Variables in the Docker Container, it gets them from Home Assistant somehow.
So, again, lets assume all that is true, as I have yet to have to time to try it myself I will take the words of others as true until I have reason to believe otherwise.
Now for someone who already runs docker containers, who has more experience with Portainer than with Home Assistant (thought they both seem to have the same problem with support liking to address things so that only those who already know things can understand), since they are already containers, why not make it easy for us to use them AS containers & those of us who can easily do so manage them ourselves.
Just give us a way to
- Add the images
- Find the standard configurations
- Add them to Home Assistant (without having to piece together the pieces we can find scattered about to do it ourselves)
If you are running docker anyway, just run the software you want. The way the addons for ha are built and controlled is open.
But they aren’t though. Running the addon gives me a dumbed down version of what I’d get running a full docker container, BUT it gives me access from inside Home Assistant.
Like the DuckDNS one I mentioned. You do your setup of it within Home Assistant, & it does some unexplained openssl process to do the Lets Encrypt SSL cert. The container just does the DDNS update, nothing else, & can only be adjusted by editing the compose.
Or the Frigate Proxy mentioned above. It just runs NginX without all the capabilities of actually running NginX Proxy Manager or even just NginX alone, but it does something that I can’t do with NginX to my knowledge, it gives the ability to create an iFrame-like tab that doesn’t just tell the browser to go to another page, it goes there within the local network without exposing it to the internet,
To get the Frigate version like @Deckoz2302 was mentioning I have to add the files locally, build the image, then setup & run it. With that being the case I’d much rather use my already existing NginX server & just figure out what I need to do to add this if possible. However IF it was available as a Repo I could just run a stack with it because all it would require is for me to write the compose, as opposed to downloading everything, building it, THEN writing the compose & manually repeating the process every time there’s an update… Not the same thing at all
So from the same person who made the Addon there’s a Docker Frigate Container, & it definitely isn’t a Proxy Manager, There’s a Docker HASS Integration but it just sets up the Frigate Container, MQTT, Home Assistant, & a VScode Dev Environment. So it doesn’t look like there’s a Docker Image for the Frigate Proxy, but I think I understand what it is, It’s specifically designed to send the page from the Frigate Docker to the addon, but that still leaves the problem of not having the addon. The integration requires camera sources just to setup, so that doesn’t work.
If you have an example of what you altered to make it work that would be appreciated, as that would make it a lot easier for me, as well as anyone else who wants to try this. If I get it working I’ll most a more user-accessible version somewhere.
I use it as a haos add-on. You can type almost any URL in it and it should work as is, just it says ‘frigate’. So I Literally just
Config.yaml to change the panel label so it doesn’t say frigate and icon and default ports.
Everything under LABEL in the dockerfile.
And a couple of Nginx settings under rootfs/etc/Nginx/ proxy params or server params if I wanted something different for a specific service, like removing x-frame-options because cross site scripting preventing rendering website on another website.
I attempted to set up the Integration but it wouldn’t let me. Can you give me an example of the things changed? ENV Variables are easy enough to overwrite in a Docker-Compose, like if the default logo image is at /etc/www/images/frigate.png you can set a volume mapping in Docker-Compose to take your file /home/docker/frigate/happyface.png:/etc/www/images/frigate.png to replace that. & if it’s pulling the title for the label from the Variable $BUILD_NAME you can set an ENV in Docker BUILD_NAME=Smiley you just need to know what variable needs to be replaced.
Where are you typing the URL?
In the config.yaml? The URL variable there is to a GitHub so it’s set value is not the internal one.
In the Frigate Integration? That one if you put a URL without camera feeds gives a Failed to connect response if it doesn’t have a camera feed
I’m working on making a version that can be customized with ENV variables in Docker. Knowing where the URL you referenced is will be a big step to making it work. Aside from that I’m just still not sure how to add it to Home Assistant.
But I ran into a problem…
You said you customized the Dockerfile correct?
When trying to build from the Dockerfile, even unmodified, I have a problem, possibly because it is missing ENV variables that the Home Assistant Supervisor would have
failed to parse stage name "ghcr.io/hassio-addons/debian-base/:5.1.0": invalid reference format
that’s coming from this line at the begining of the Dockerfile
ghcr.io/hassio-addons/debian-base/${BUILD_ARCH}:5.1.0
I discovered that it needs, in my case amd64 & if I sub that in it works, but if you modified it how did you get around that?
When you install it as an add-on, the configuration page has input for ‘server’ where you can put an IP:port or fqdn:port (no http/s ://)
The things I changed are basically the name of the addon, and my private repo link and icons.
So for something like sonarr, or radarr, it’s changed to sonarr proxy, or radarr proxy. And it’s just loading whatever webpage you input into the ‘server’ option.
Thats all it’s doing, is making it so home assistant is loading the webpage, not you as the client. Its kinda like an iframe, but not. Iframe expect the client to connect to the end server and load the resources.
As far as the dockerfile, I’m using it as an add-on, so when home assistant builds it, it has those dependencies available?
1 Like
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
It’s AMD64 not AND64.
I referred you to the docs earlier, but ingress is documented here, in case you missed it. Presenting your addon | Home Assistant Developer Docs
Ingress is intimately tied to supervisor, which is not to say that there are not other ways to do what you want.
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
1 Like
Not sure how I missed this, because I responded right below it. But this user has an ingress proxy written as well, @LostOnline
2 Likes
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
@LostOnline you may wish to read this thread Is it possible to convert an addon for HA OS to run in a standalone container for HA as a docker?
1 Like
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...
Also, it seems to not be using any resources…
