Why shouldn’t new users install custom components, when we think about it? Will HA ever be suitable for “the regular person” if even installing a component for the hardware you use is “too advanced” for people?
1 Like
@teachingbirds actual words were “the first thing they do”. I didn’t see this as advocating a blanket ban. Even for experienced HA enthusiasts there is a still a bit of a learning curve when starting out with HA.
I really enjoyed the clarity of your argumentation.
Lowering the barrier for less tech-savvy users to reach a broader audience should, and in fact is, a goal of Home Assistant. Comfortably managing the specific components users need for their individual home setup should not artificially be limited but extend to external components (via HACS or any other way). I would wish for Home Assistant to not differentiate/discriminate between internal and custom components.
The argument of safety/security/secrecy is a muddy field. Users commonly install all kinds of desktop browser add-ons or smartphone apps. HA is not special.
It is within the user’s freedom to select the tools for their specific needs and their responsibility to evaluate the legitimacy of software offerings. The ecosystem and the community should offer its best support possible to achieve the needed transparency.
Instead of demonizing custom components, I would wish for e.g. automated privilege assessments and a community driven rating system to guide users in their journey.
5 Likes
This is very recognizable!
1 Like
If HA allows using custom components, why it has to be so cumbersome and time-consuming?
Looks like someone found a good solution to this problem (and created HACS) and now so many users appreciate it so much it is one of the most important add-ons/integration/extension/component that improves “QoL” (pick one you think describes it best, because for me, it is still confusing, and I use it interchangeably.) From this perspective, I see OP arguments justified.
I find the tone of this discussion very dismissive and very counterproductive to the idea of “WTH…”
It feels like I am being asked to keep chopping wood using an axe because the chainsaw is not supported. I may get injured using the unsupported device. Put a disclaimer, i.e. “this may break the system, you install it at your own risk or whatever”, it will be enough.
2 Likes
Not sure this analogy works. Your “windows store” is here, the 2200+ integrations you can add to HA out of the box with zero additional work required.
HACS is the equivalent of going outside the windows store and installing some random exe you found off the internet. Windows let’s you do that but first it makes you dig around in settings to disable a few security features. Kind of like how HA makes you work a little bit extra to leave the known supported and secure options you get OOTB.
5 Likes
Thread has run its course IMO.
OP has raised his WTH in relation to HACS. It is clear that HA and HAC’s devs don’t want to include it as a part of HA, and it’s their prerogative to do so.
1 Like
- Everyone is free to submit a WTH.
- Everyone is free to comment on a submitted WTH.
- No one is obligated to agree with a WTH.
“Counter-productive” would be closing the topic immediately after it was stated that the author of HACS (a member of the core development team) isn’t interested in making it an official integration. However, the topic wasn’t closed so everyone continues to be free to express their opinions, pro and con.
5 Likes
OK, fine, bad choice of words. English is not my first language. Discouraging is more fitting…
Anyway, HA needs HACS or a better system of installing, managing and maintaining custom components because without it is near impossible task. Yes, it’s doable when you install a few, but when you have a few dozen, then it’s a different ball game.
Besides, why does it have to be cumbersome…
I agree. And I’m one of the persons that lost their senses a bit in the discussion. I apologize for that!
I’m happy to see that, after the dust settled down a bit, some valuable arguments were added to the discussion.
There are concerns about security and about support. I think the real problem is that all those third party plug-ins installed manually or via HACS can run unrestricted and basically have the same rights in the system as the core HA process. I guess that’s the real reason the devs don’t want to add a native solution for installing third party stuff.
This can be solved, but that’s non-trivial and probably a lot of work. It involves creating a “sand box” with a clearly defined API where those third party plug-ins can run with limited privileges.
2 Likes
You go outside the windows store to install all the time. Most people have chrome if nothing else, and the norm is installing of the internet. I don’t have to dig around and disable anything to do that, you can do it out of the box in windows, and the risk is higher.
1 Like
How would that be different than the current situation. I mean HA allows you to install custom components manually? Shouldn’t that be a user responsibility? It is now anyway, I don’t see any difference. There are warnings in the logs and there could also be a disclaimer:
“You are installing at you own risk. This is a security risk, etc.”
This might be ok for our current technical user base but won’t be suitable for the future less technical users. The argument about don’t install them if you don’t want doesn’t work in countries outside of the USA and Europe as many of the components for these areas take a long time if ever to become part of the core. See my previous post.
This thread has actually prompted me to think about custom components a lot more in depth and I am now think that HA probably needs to do more than just have something in the logs. This is a place only technical people will look and the risk is non-technical people.
As HA become more widely used it will become harder to separate a security incident caused by a supported vs custom component.
the hypothetical example I think of is a non technical user follows a random online guide ( one of thousands there are now) that installs a custom component with malicious code. This user will unlikely even understand what they have done. This would likely be viewed as a HA problem by the user and could share their bad experience as a HA problem.
HACS actually resolves some of that in a way as the repositories are usually on GitHub and there is a small hurdle for them to add a file with meta data. If someone reported malicious code in one of these it could be reported through GitHub etc. possibly even a future HACS feature of blacklisting or something. I am not familiar with the inner workings of HACS to know how possible this is.
As HA has a strong security focused and open source it make a conflicting challenge for make it the product more general user friendly.
On one extreme the most secure would be not to allow custom component (I don’t want that).
On the other end is open source philosophy and being able to review code, add, fork etc. this can be secure for technical people who can review the code of the custom component. This is not a general user. I think we need something in between, HACS kind of fills that spot right now.
In summary. I think HA may need as part of the core a community store that has some standards to be met and possibly reporting and blacklisting. Appropriate warning and notifications can be part of it. This would be for the intermediate users of those who need a custom component but are not technical enough to read code.
You can leave the existing method for advanced users and developers etc.
3 Likes
I should clarify that by this I mean the same approach as HACS now applies it with a metadata file etc. It is 100% up to the custom component developer to comply or it doesn’t show up in the store. Possibly with community reporting for non compliance issues etc.
I do not see a sustainable solution where HA/Nabu casa do the checking of custom components. Just managing the portal to them.
3 Likes
I imagine a part of this can be implemented as an automated process. E.g. static code analysis tools could be used. Automated tests. It would make the hurdle to get your extension in the “store” a bit higher, but I don’t think that is a problem.
1 Like
Hello,
(at the beginning on this way my thanks to all voluntarily contributing to HA)
This topic is interesting from my point of view. Here two worlds collide which unfortunately understand too little of the other. Therefore here a definition from me (completely value-free).
Home Assistant (HA) is a software from nerds for nerds (N2N) - not for users. It is a modern version of model railroaders and stamp collectors who put a significant part of their lives into the software and detail aspects. The wonderful thing here is the consequent use of the modern possibilities of sharing the results and the willingness to support others.
In my definition, the Nabu Casa group is a control and coordination entity. The target group is still nerds.
In its current version, HA is not a product for users. Not even in the version without HACS. The fast (monthly) updates and the fixes needed afterwards are too unstable. (Insert: I would like to clearly say here that these lead to many great functionalities that I find extremely helpful). HA is a playground for enthusiasts. No more and no less.
Another clear characteristic is the lack of stability (e.g. backward compatibility) and the associated impossibility to provide a meaningful overall documentation (No Book for HA). (I know that this is written very hard, but the view from outside does not allow a more friendly description).
The discussion that has now been concluded here only cemented the two perspectives from my point of view. That is a great pity. From my point of view, discussions like the one above make a lot of sense because, if they take place without insults etc., they make some participants think. Let’s see what develops from this.
Finally, my thanks to the initiators of the WTH time. It encourages cross-thinking and recapitulation.
Frank
3 Likes
This is not correct.
The Home Assistant development team want it to be as inclusive as possible. It is one of their main aims.
Is it there yet?
No, not really, but significant progress is being made. Look how far automation writing has come, from YAML only to a very capable GUI.
Not sure what is wrong with your system but I’ve been running beta version for years without much issue. Many run the dev version.
There are feedback links at the bottom of every page if you have suggested improvements.
3 Likes
My two cents after being negatively surprised by some of the statements I read:
- MIT does not mean that others have no moral responsibility to respect the creator’s wishes. By even suggesting to go against that dev’s explicit wish means that you do not understand the spirit of open source projects. If the dev decides to no longer maintain it, go commercial or similar, you are free to fork the open project and host it for free also.
If anything, build your own version of auch a repository collector. Don’t just steal it. - The UX of Home Assistant is fine without HACS. I actually think that there is too much focus on it with all the moves away from yaml.
- HACS is a cool and simple way of installing third party components. That would for sure be nice to have in HA core. But it is absolutely no work at all to install HACS yourself.
- You cannot just merge everything out there into core. It makes no sense. The whole way HA is built is for maximum flexibility and versatility. Let people decide what to install. I would even argue that some other components are not needed in HA core, but the devs wanted it in and are maintaining it. So that is also a respectable choice.
Anyway, HACS is cool but it is not needed in HA because of ease of installing it (same actually for the components it helps install).
I have no idea what “users” want or use. And if I am not mistaken, the analytics also would not because I assume many opt out. I turned analytics off also. So unless there is some monitoring I was not aware about, analytics won’t help either.
And personal impression: people who use home assistant probably have some willingness to do things themselves.
Plus, my two biggest fears (to be completly honest) are:
- that HA goes too far into UX and away from yaml and takes away the possibilities to maintain with code even more
- HA goes full business and makes Nabu Casa or similar mandatory
So, respect the devs wishes and have some faith in the users’ willingness to learn something. It will also make the end result so much better if they cannot just clickeldy click (if the community is strong and willing to help!).
4 Likes
Thanks for sharing that view, @tropfen! I really think it is “spot on”.
This is an excellent example about what @tropfen means with his “from nerds to nerds”. Of course HA runs totally fine. But I’ve had cases where things stopped working after an update. I was always easy to fix. But I’m a nerd too. I think “average, non-nerd users” wouldn’t find those fixes easy. If we want HA to be a product for the average user, we should more often ask ourselves: “would an average user think this is easy?”
I never wanted to suggest to do something morally irresponsible. I just wanted to say that, if the original author didn’t want to integrate HACS into HA, there are multiple possibilities:
- It can be he simply doesn’t want to do the effort, but would be fine if someone else did it. (I think bu now it is clear that this is not the case, but I didn’t know that before.)
- If he doesn’t want someone else to do that, it still doesn’t prevent someone else from creating something similar. I think that’s not morally wrong in any way.
This, again, is an example of “from nerds to nerds” thinking. For an average user, editing text files on a remote machine is very difficult!
Of course not. That is not what I suggested, but I noticed that multiple people interpret my message as if I’m suggesting that. I think that’s because you think too much from the current state of things and how that works. There could be ways in the future to have third party software be installed into HA in a nicer way, without the need to merge that third party software into HA Core. As stated in one of my later messages, that probably involves things like sandboxes and is probably not trivial. But it’s also certainly not impossible.
1 Like
It should not be. Visual Studio Code is part of core integrations.
And you can upload via VSC if you want to work locally. So it is basically editor and file explorer in one.
The coding part, yes, not easy (I am a newbie myself, regularly frustrated). But for installing third party components it is just copy and paste 