Well, this is exactly the problem! It is too cumbersome to install 3rd party add-ons. That’s the problem we’re talking about here. HACS partly solves it. My idea is that it could be solved in an even better way if the functionality that HACS offers would be integral part of HA Core.
2 Likes
So, apparently, it has been a deliberate choice to make it difficult to install 3rd party add-ons. Because devs are afraid to overload a non-existing support department with questions about those add-ons. 
Let’s consider an example. Browsers. Every browser has the option to install 3rd party add-ons. The companies behind those browsers go through great lengths to make it easy to find and install those add-ons. All browsers have some sort of add-on-store built in.
To me, it is very clear that functionality provided by a browser plug-in is not provided by the browser itself. The very act of clicking that install button makes that clear to me. Sometimes I even need to accept some terms first.
I think this example makes it clear that it is possible to make it easy to install 3rd party add-ons while at the same time making it clear that the add-on is provided by someone else. In other words: I don’t see a reason to have these barriers for installing 3rd party add-ons.
4 Likes
But it’s not cumbersome.
the point is that those are “3rd party”.
They aren’t built-in.
The irony is that there are two completely opposing WTH’s going on right now - one that requests for all third party things to be incorporated into HA so they can be easily installed with the push of a button and the other requesting that there are almost no built-in integrations and they should all be considered to be third-party and developed outside of HA requiring a special way of installing everything.
but the reality is that the way that it’s being done now is a balance of both things and gives the best advantages of both.
2 Likes
no not intentionally. It’s just the nature of things.
HA provided a way to allow users to use third party things that aren’t officially supported by HA and HA wants to make sure that the users who do use those third-party things understand that is the case by not providing a built-in way of doing it and even provide warnings in the logs that the user is responsible for their use and it’s impact on the HA system.
The dev of HACS came up with a way to make it slightly less painful to install those third party things (even tho I think that the main huge advantage of HACS is keeping up with available updates for them since there is already an otherwise fairly easy method of manual installation of them) apart from any built-in method to reinforce that idea.
I’m sure that’s why the devs don’t want it to be built-in.
How would HA differentiate to the user between an officially supported thing and a third party thing that they don’t support if a user can’t even figure out how to install HACS and then install those things via that fairly straightforward method?
And I guess I don’t know how having the HACS integration built-in would make things easier to install aside from the initial install of HACS itself that, once it’s done, usually doesn’t need anything other than updates - which HACS itself provides tracking of.
built-in is still built-in and third party is still third party and they need to be separated otherwise you are going to have tons of more bug reports being submitted to the official HA repo for third party things that HA doesn’t support.
Nothing to discuss, it’s not gonna happen. 
7 Likes
To OP: you have to understand that
- core modules/integrations are integrated into HA builds (there is no plugin system in place)
- core team has no enough resources to maintain foreign modules - those require to be maintained continuously for various reasons (keeping pace with HA, improvements, fixes)
- 3rd party modules cannot be integrated into core in a way which gives freedom comparable toHACS (ie providing newer version whenever their dev wants)
Simply none of the parties wants to merge both ways of development. Each way is different, each one is characterized by different benefits
Personally I would never want 3rd party modules being included into core. Core deployment cycle is too rigid and limiting. 3rd party integrations are often more feature-reach, and their development pace is more faster.
But I have to admit, at beginning of my journey I was also confused by (core) integrations, add-ons store and hacs.
ps. look at another WTH, search for monolith word. Changing architecture described in this WTH could potentially open doors to what you are asking for.
4 Likes
There are no add-ons in HACS
5 Likes
https://www.youtube.com/results?search_query=how+to+install+hacs+home+assistant
Some of those videos have tens of thousands of views meaning there is a need to know about HACS !
And everything that would make installation/setup of HA easier would be a step in the right direction (the learning curve in HA remains steep).
But I understand there are reasons (listed in that thread) that make the native integration of HACS complex 
From the HACS FAQ:
So yea, there’s no add-ons in HACS at all. Just FYI.
As for your WTH, the HA team is only going to ship code that they have tested and reviewed with HA. That stance is very clear. What is in HACS is by definition has not gone through their defined test and review process so its not going to be included in core.
Yes. Extremely. Not having the typical support department actually increases this concern, having one would likely lessen it. Because it means the devs themselves have to triage, approve, assign, fix and verify every issue. There is no frontline support staff like at a large company to weed out the obvious non-issues or redirect people to existing solutions in documentation to ensure only the ones that require dev attention get to them. Or QA department to handle sanity checks and verifications before a fix goes out the door. Everything is entirely on the dev team.
So yep, the dev team is 100% doing everything they can to limit issue influx where they can. To try and make it very clear in the product itself when issues belong in core and when they should be redirected to some other repo. Because despite these best efforts here there are still almost 1600 open issues right in core and another almost 500 in frontend, the two main things HACS modifies. The dev team is absolutely protective of the time and mental health of the members of the organization and is absolutely going to take efforts to avoid increasing their burden. Even if it means people have to go through a few extra steps to get to community contributions.
4 Likes
I think this description is misleading . Add-on is not the established name for HA extension only. An add-on is just an extension. Thus HACS as well as what it provides all are addons. more over, those are HA add-ons.
But those are not addons in terms of HA Add-on store.
So yeah, it’s confusing and not described in detail enough
BTW hacs doesn’t handle integrations only. It provides also cards, themes etc… add-ons 
Right but that’s more misleading because there is actually something called Add-ons in HA and those are definitively not in HACS.
I recognize the need for a generic term because of all the stuff in HACS, that was why I used “custom components” rather then “custom integrations”. The problem with that of course is that advanced users know custom integrations go in the custom_components folder but since that term isn’t actually used anywhere in the HA UI or doc anymore it felt like it fit for me. If not maybe HACS components or plug-ins would be better.
Really I would say any term besides “add-ons” is fine because “add-ons” are a defined thing in HA and they have nothing to do with HACS. Extensions, plug-ins, components, module, etc. There’s so many synonyms for this concept across platforms these days.
2 Likes
yes, it’s obvious. Not for a beginner though.
I think improving HACS docs to be more precise in naming (maybe incl description of what is what) could improve newcomers onboarding
I think you might be forgetting, for example, some of the people in this thread. 
There are many users who put in a lot of time helping other (new) users and hopefully fending off unnecessary issue submissions.
No they aren’t.
Add-ons have a definite meaning in HA.
They are external apps installed and configured solely thru the supervisor system to be able to be installable and maintainable via HA itself. Moreover, a regular docker container providing the exact same functionality as the equivalent add-on (minus the supervisor portion) isn’t an “add-on” either.
third party integrations or frontend plugins are NOT add-ons.
There is a saying…“when in Rome…”
That’s why I use the term “custom things”. That way it doesn’t trample on and confuse the commonly accepted terminology used by HA.
2 Likes
i know. but it’s unfortunate. For newcomer it has nothing but common meaning. Potentially a newcomer might not even know about HA Add-ons Store existence when starting with HACS. at least HACs docs should be very detailed in this matter
I’ve never seen such a term in software description.
I believe it is. see bullet point 6.:
it even gives a link to the accepted definition of the term “add-on” from the HA docs glossary.
I agree but at least there won’t be any confusion between what I’m saying and other previously defined HA related terms.
2 Likes
TBH this sentence (from bullet 6) is really imprecise. It could mean it provides no addons which are to be found in the Store but provides different ones. Snd note it’s in “requirements” section.
When I said “detailed” I mean it literally. Instead of above, bullets should explain existence of HA add-ons Store. It should describe differences between what it provides and how it differs to HACS.
Finally it should introduce unique naming convention in order to avoid any confusion.
I agree it’s not always as easy to start perfect docs from beginning. Just saying what is or might be the source of confusion.
1 Like
I’m sorry but I think you are just being disingenuous here.
It never even mentions the add-on store at all so why would a user think that it provides other add-ons but not the ones thru the add-on store that it doesn’t even mention?
It literally says that it provides “…NO add-ons…”.
yes, because it’s REALLY trying hard to make people understand that it provides “NO add-ons” before they even get to the point of installing HACS.
you mean like this:
I guess I could agree that it might be better to add a blurb to make it more distinct and say something to the effect of “This doesn’t provide add-ons. those are only available thru the HA Supervisor Add-On Store in HA itself”.
But I still think there would be many users who would still not get it.
1 Like
It does track it, just not on the main page. You have to look at the custom_integrations tracking which is a very large json blob:
https://analytics.home-assistant.io/custom_integrations.json
curl -s https://analytics.home-assistant.io/custom_integrations.json | jq '.hacs'
That returns a total of 80,242 installations of the 181,530 which is 44.2% of the HA user base. So not quite 50%.
That being said. I have to side with the developer here. If they don’t want it part of the core for whatever reason, then it shouldn’t be. Besides, it changes enough outside of the standard release cycle that I would hate to see it locked to the release cycle of core.
7 Likes
Don’t forget that many folks setting up HA may not be familiar with Open Source software. Those coming here from a commercial system can’t be expected to understand, at least at first, why some things (such as “the personal interests of a single developer”) are the way they are, and not what they are used to.
More bold conclusions based on speculation. It’s not unique views; it can be the same user watching the video several times. It doesn’t mean everyone ultimately chose to install and/or use it.
FWIW, analytics reports over 181 thousand installations of Home Assistant and that’s based on only the instances that opted in to analytics (my two instances don’t participate).
1 Like