Why are we "non-supervised" users always ignored?

Interestingly, both Whisper and Piper did at least have links to their docker pages when they were first introduced (which gave links to here and here).

I do remember having to search further online to get the right compose script though.

Creating video tutorials takes more time and effort than most people think, and creators have to balance a bunch of factors to maintain monetization, including things like video length and completion rates. Adding content that 80% or more of your audience will skip can tank any hopes generating revenue from a video.

This discussion clearly illustrates my reason for installing HAOS Supervised, X-86 image on an Intel NUC. It’s simple. It works. And most important, I don’t have to learn Docker.

Don’t most add-on developers publish their code on GitHub?

You don’t have to create more video content for the docker stuff.

How much extra effort does it take to add the text for the base docker run command in the description box for the video?

If the effort of researching and creating a write-up is insignificant for someone creating a video unrelated to container or core installs, wouldn’t it be equally as insignificant for someone who is actually going to set up the container etc in question, especially if they are absolved from having to make a video tutorial?

2 Likes

Most of the content creators in the HA content creators program run HAOS. They ask us questions on discord regularly and we rarely get any docker questions. They are all more than capable of learning docker, but I’m not sure any of them care to. I don’t think there’s anything malicious going on here, it’s just not something they are interested in creating.

As far as I can tell, KPeyanski is the only creator who does this type of content. https://peyanski.com/

1 Like

I agree completely, and this is why I tried to stress that my personal expectations do not include guides for my setup.

I can’t speak to anyone else’s reasons on not asking questions in discord, I can only elaborate a bit on mine. Inevitably when asking questions related to my setup I will be asked “why don’t you just {do the more common thing}, it makes {thing} much easier”. This is at least unhelpful, and often is delivered in a derogatory manner. We’re all a little bit tired of helping folks learn something new. When those help channels are designed for folks doing basic things they become unhelpful or exhausting for myself trying to accomplish something weird or new.

This thread is an example.

This is a superficially correct statement. Yes, there is no button I can click to make an Add-On run in my cluster. But Add-Ons are Docker containers with some manifest information. HA is open source. There is a route in there to writing a translation layer between the HA OS management code and, say, a Kubernetes cluster. It is entirely technically feasible to have HA OS manage Add-Ons in a cluster and have it work nearly identically to the current HA OS experience. The code just needs to be written by someone motivated enough.

But if I came into a discord channel and started asking questions about where to get started with implementing that, I fully anticipate the answers to be

You cannot run add-on containers outside of Supervisor

Or

…will actually be significant work, depending on all that is involved.

As someone who has done interesting and weird projects it’s exhausting to have someone tell me what I’m trying to do is hard or not supported. I stopped asking in venues where I can expect that sort of response.

Which brings me back to my original point. I don’t expect amazing guides or a fantastic experience. Some cliffs notes would be very much appreciated though, compared to the nothing that so often is the alternative :slight_smile:

3 Likes

In what way is it superficial? Many add-ons literally require Supervisor, they communicate using the Supervisor API. https://developers.home-assistant.io/docs/add-ons/communication

From your link:

To enable calls to the Supervisor API, add hassio_api: true to the config.yaml file and read the environment variable SUPERVISOR_TOKEN . Now you can use the API over the URL: http://supervisor/

These are a good example of the type of notes I’m interested in seeing. It tells me pretty clearly where to turn something on and where to get related context. It isn’t written for me specifically as an audience, but provides the right information for me to start putting pieces together.

Where a theoretical cluster system would enter is not using network aliases. Instead I would modify HA’s config to expose the supervisor on my cluster network subnet so that other running Docker containers on the network could talk to it. A simple implementation might be forcing the Add-On API on but disallowing HA from controlling container lifecycles, but I digress from the intent of the thread.

That notes page include some statements like

This makes it very easy to communicate with the API without knowing the password, port or any other information about the Home Assistant instance.

Part of the benefits of my cluster system is that I do know that information. It’s part of how the cluster executes the various tasks I’ve told it to run. I know exactly what ports and IP addresses are assigned everywhere as it literally won’t work otherwise. I get all of this information dynamically, and if it ever changes my running systems will be actively informed.

You’ve fallen into the reaction I described above: you are assuming I want or need to use features as explicitly documented to function. Your statement is only superficially true because it assumes the person you’re talking to is limited to those options.

I’m not. I know how to do more.

Clustered systems design is what I do for my day job. I don’t need to “figure out Docker” when I have contributed code to the project and worked with Hashicorp engineers directly on their products.

This exchange is an example of the sort of reason I spend time reading dockerfiles instead of asking in chats. I’m not trying to pick on you specifically here, but your contribution to this thread so far has been “none of this is possible”. Entering into a conversation with a little more imagination about what is possible, rather than restricting yourself to the options available today, makes for a more constructive collaboration.

How could HA support manually running Add-On Docker containers without putting in a ton of development effort to support the small group of people who want to do this?

That’s a much more interesting conversation to me.

2 Likes

This is not the first time we have had threads like this and will not be the last time.

Addons exist because on HAOS you can not just run whatever software you want.

Addons just wrapps existing software.
Probably somewhere around 99% of those all ready publish containers and instructions for you.

  • Trying to force an addon to be run outside its intended purpose will not go well.
  • Suggesting that the addon author should document t docker.

Both those are IMO backwards thinking, it all ready exist, just replace the word “addon” with “docker” in your search.

So guess what, you can run “addons” on docker, you just run the software that add-on wrapped instead.

4 Likes

Sorry, I was not having a discussion with you, it seems you think I was. Otherwise, why would you make up this argument about things I never said? I didn’t even know you existed prior to you calling me out, so I could have made no such assumptions about you.

Feel free to ignore my comments, especially ones that don’t involve you.

Besides the fact that I don’t know what “this” is that you’re even talking about, at least I provided a solution to OP’s original problem. It’s convenient you didn’t bother to quote that.

4 Likes

Lets not forget that the remaining 1% are functionalities that don’t need a container on a normal docker system; samba, ssh, nginx, letsencrypt, remote backups, etc.

2 Likes

Perhaps a real-life example that made me frustrated, is in place?
When I first started to play with the idea to explore “Year-of-the-voice” I visited this page as my first step.
Boy was I disappointed to read the following sentence;
image

So, I gave up after reading one paragraph - cause I don’t run HA-OS! And this says it was a prerequisit! Logically I concluded there and then that Year-of-the-Voice was only for the privileged ones.
Now, I know that this isn’t true at all. After installing Whisper & Piper in external docker containers, and integrating them with HA using the Wyoming Protocol Integration, all manually set-up and configured, I no now that HA-OS is definitely not a prerequisit at all.
Perhaps this is an illustrating example of what I mean by “Ignoring non-supervised and non HA-OS users”. Even the official docs seems to forget that we do exist.

3 Likes

At the time that page was written that statement was true.

Now it’s not, but nobody has taken the time to update the docs - a common problem. Maybe this could be an opportunity for you to submit an edit to address that?

3 Likes

I tried to, but got myself completely lost in the process, so I gave up.
Submitting an edit wasn’t very easy.
Perhaps there’s a How-To guide somewhere?

Every page has a GitHub link. You click that, make the edit and submit the PR. Easy as that.

No, it’s not easy.
I tried clicking the Edit, and I ended up here:
home-assistant.io/source/voice_control/voice_remote_local_assistant.markdown at current · home-assistant/home-assistant.io (github.com)

It seemed to have three alternatives;
Preview (which was readable, but not editable)
Code (which was not readable (gibberish), but perhaps editable - if you know what you’re doing!
Blame (which was where I hoped to find someone to blame)

Well, I’m not really talking about Core installs as those have nothing to do with Docker.

By my statements above I was referring to the process of creating an Add-on that is at least my understanding (reinforced by this statement above: “Starting from an application that already has standalone container and working to an add-on is the usual route.”) that most Add-on authors likely start with a working Docker container and then create the Add-on from there. And having that already working Docker container at least requires a working Docker run command to implement it (or a Docker compose). If that already exists then it’s likely trivial to copy/paste that into the description of the video.

Yeah, it would.

and that’s what those of us who run HA Container installs do. But if the info already exists and it’s easy enough to provide it then why not help another user out?

And TBF I had already stated in a few places that by running the install we do that it’s on us to figure it out. I’m definitely not expecting for someone else to do the work for my benefit. I was just trying to give another point of view on the OP’s position.

if my assumptions are incorrect and that’s not how the process for creating an Add-on goes then my apologies and just completely disregard any of what I’ve said on the subject.

It’s not code, it’s markdown. This is what you edit.

Markdown is human readable text, you just add bullets & paragraphs and the “markdown” formats it so it’s easy to read.

Well, I tried - but I couldn’t edit the code either (which is not code but markdown - that’s why the tab says ‘code’). I was told that I had to be “on a branch” in order to propose changes!?!
I have no idea where the branch is - I don’t even know where the tree is!
And you call this easy!
No wonder there are so many errors in the docs. If you have to take a training course in order to contribute :stuck_out_tongue_closed_eyes: