From a dev point of view there is a huge advantage in having your integration within the core. Aside from it being bundled (which actually means installed on demand), you get testing.
The rules are quite strict meaning every new integration has to have UI config and tests. But once that’s in place, the pytests verify that each new PR works with the full suite of existing integrations. For example if someone breaks something in the core or a dependent integration, a test will fail and the PR will be rejected.
So as a developer you can actually be confident that your integration is still working with the newest HA release even if you’ve not worked on it in the last month. That’s because if someone broke it, it would be failing the tests and their problem to sort not yours.
This has the effect of catching anything that’s still using old deprecated APIs when someone eventually submits the PR to remove them, and that itself pushes the quality and the compatibility of all integrations. You shouldn’t generally find scenarios like ‘this core integration is broken now in the latest HA release because the developer didn’t update to the new API in time’. Rather if something its being neglected it gets officially dropped (or more often replaced by something better).
I think the wider community might underestimate the work that goes in when large organizations (e.g. apple, google) maintain big APIs with published feature sets that have official version releases. Their tools + appstore prechecks ensure that incompatible programs aren’t offered to users. Both for using API features that the user doesn’t have yet, or using API features that are deprecated and now dropped.
Or put another way, the non-HACS experience protects the user from incompatibility problems, without requiring significant developer work on API version backwards compatibility.
Having said that I do see that the list of integrations is only growing, and needs some way of scaling the maintenance.
I think that HACS will hardly be incorporated into the HA core, it would include several possible bugs in the system from custom integrations.
But I think it would be a good balance to have a way to install HACS through the interface already included in the Home Assistant core, maybe showing some description that the user has to “agree” to install HACS that makes it aware that it will include things not validated by the Home Assistant developers.
I know the average user (and from reading the forums) don’t look at their logs, but HA warns you about every custom component installed with a message in that vein, including for HACS.
Totally, I would be livid if my custom integration got subsumed into core without my approval. While I wouldn’t be able to stop it because of the license, the probability of my continuing to work on it would likely drop to zero.
Wow, the discussion derailed quite a bit. That said, I learned a lot. Let me summarize:
Apparently, the widely used term “add on” has a special meaning in the context of HA.
Not integrating HACS into HA Core was a deliberate choice, and people seem very passionate about defending that choice.
People in the HA community don’t seem to be used to product thinking. I didn’t mean to be mean to someone when I said that a developer’s personal preferences should be subordinate to the user experience, but apparently people took this as an insult. My apologies, it was not intended that way! (And as someone suggested correctly: in a corporate setting, an individual developer’s preferences are indeed subordinate to the user experience, even broader: to any aspect of the product.)
It seems some people thought I was suggesting that the HA Core team should take on the maintenance of all third party add-ons integrations and cards and integrate them into the HA source code. That was not what I meant.
44% of HA installations have HACS installed. So there is a large group of HA users that somehow need the possibility to easily install and keep up to date third party integrations, cards and themes.
That said, I have a couple of suggestions:
Taking a generic term (“add ons”) and giving that a special meaning in the context of a project, doesn’t seem like the best solution. May I suggest to give what is currently called “add on” in the context of HA a more specific name? Something like “HA Supervisor Add-on”?
I still think it should be possible to make the installation of third party integrations, cards and themes a lot easier, while also making it clear that the HA Core team can’t support third party software. This can be done by:
Clearly marking integrations, cards and other parts that are part of HA Core. E.g. by giving them some sort of “HA approved” icon, and/or by prepending or appending the name with something like “HA Core”.
Abundantly use the word “third party” in any area where third party software can be installed or configured.
Create one single “store” for “HA Supervisor Add-ons”, 3rd party integrations, themes and custom cards. An and user does not care that one thing is based on Docker, while another thing is just a piece of HTML with some JavaScript and a third thing is a piece of Python code that will be run inside HA.
Don’t assume users read logs. If users need to be warned, do so via the UI.
Again, apologies if I insulted anyone. Honestly, I’m just thinking how HA could be improved.
Or maybe you could use the well established jargon associated with this particular project.
This isn’t a toy like Homekit. It is a sophisticated highly configurable home automation server. Of course you have to read logs if you want to monitor the state of your system.
I’m really baffled how some people are seemingly unable (or unwilling?) to think from the users’ perspective. HA is a product! It is open source (that’s great!) but it is also maintained by a company that is making a profit from offering cloud services and selling hardware, both related to HA. That’s all totally fine. But we should not think that HA is just someones pet project and that we should live with whatever that dev thinks is best. To the contrary: this whole “Month of WTH” was started to find ideas about how to improve HA!
Thus, it is very disappointing to me that resistance it he only thing I get as an answer to my idea. Feels like: “Hey, tell us what you think we should do to improve. But please, only tell us what we want to hear, so we can execute the plans we already had.”
I am also aware that this has been asked for before and both the HACS and HA developers have clearly stated they do not have any interest in pursuing it.
I have not made any comment on the merit of your suggestion, I’m just telling you that based on this knowledge it is not going to happen.
Well, maybe they need to re-evaluate their stance? 44% of HA installs has HACS installed. And it has be brought up before that it seems weird that something like HACS is not part of the standard install. There’s nothing wrong with acknowledging that one needs to adjust his point of view on a certain topic. I do understand the concerns about add-ons third party things breaking stuff and posing a support burden on the core team. I also have made some suggestions on how to prevent that. I’d love to have a discussion about those suggestions and what other things might be possible, instead of just saying “not gonna happen”, based on statements from the past.
Hahahahaha! The whole world is using the term “add-on” to describe the generic concept of a piece of software (possibly from a third party) that extends the capabilities of another piece of software. HA chooses to use the term “add-on” for a very specific type of additional software. And people that accidentally use the term “add-on” in the way it is used outside of HA are corrected in a not very friendly way.
I (and others!) identify that this is confusing and come up with an idea to make this more clear. And now you say that I am requesting “everyone else” to conform to “my naming needs”. That’s really funny!
I don’t think you understand the idea of the “Month of WTH”. The idea is not to alienate HA users by correcting them and dismissing all their useful ideas!
Instead of discussing HACS in standard installation or not maybe the best solution is something else.
Let us look at the problem and the pros and cons.
HACS is a custom integration which makes it easy to install and maintain other custom integrations. It is one of the greatest things in the Home Assistant world. The problem that HACS solves is that it is a manual process of creating directories and copying files to the right locations plus additional steps to install it afterwards. The problem is that HACS itself is difficult to install for users that are not already with basic Linux administration.
The proposer of this WTH suggests that HACS is made part of the default shipped installations.
We know that the author of HACS does not want this and this naturally has to be respected. Otherwise you end up with someone taking HACS with brute force and then it will no longer be maintained. That is a loose-loose game
I fully understand why the both the HACS author and many of the custom integration authors prefer to remain independent. There are huge advantages with that. First the author remains in full control and does not have to ask Paulus and his favorite disciples for permission. You can write the documentation the way you want, you can decide which unit tests to write etc etc. Second, you can release fixes and features whenever you want. You are not forced into a monthly development cycle and you do not have to ask a high priesthood for permission to add new features.
The disadvantages are the same. Just turn the same arguments into negative language. Maybe you prefer that things are controlled and tested and follows a certain standard.
So the problem to solve is that HACS is difficult to install. Maybe the best solution is one that puts into Home Assistant the ability to easier install a custom component. Not a complete HACS solution but a way to install HACS or any other custom component by pasting a URL that points to an install script on Github and runs it. Just making it a bit easier for the average user. That would be a win-win
And it keeps track of updates for you. I was quite happy manually installing third party integrations and frontend cards but keeping track of their updates was a nightmare.