This is going to happen anyways, merging the both lists isn’t going to fix it. It will just confuse people more. “what one do I install?” “why isn’t the first one named Zwave working?” “oh I should have clicked the second one?”
2 Likes
I disagree 
But I think we are too far apart that it makes sense to discuss it further.
If you had a list and the list contained
Network UPS Tools
NUT
Zwave
Zwave JS
Mosquitto Broker
MQTT
Frigate
Would you know what to install if you wanted to install Zwave? What about Frigate?
2 Likes
Well, one adds functionality to your machine/OS and the other adds functionality to HA. It’s kind of like how you go to the System App Store to install new software on your computer, and go to the Chrome Web Store to get new plugins/extensions for your browser (which is itself an app). Same idea, and nobody worries about combining these lists, mostly because the names make more sense.
As noted on its own site, HACS does not include add-ons. There is a completely separate repository of community-supported add-ons, the majority of which you’ll notice have absolutely nothing to do with HA functionality, but which people might want to install on a server that has spare cpu cycles to perform additional tasks. If you’re only referring to updates, then credit HA’s use of update entities to provide a centralized method of version control across all device firmwares, integrations, and add-ons. It’s a great feature!
I believe they absolutely need to be in two different places, because they are so fundamentally different, and because non-supervised users can’t even use add-ons, they understand how to add these apps themselves. But I also believe the user experience could be improved.
You’re right that it’s not clear where to look first, as new users can’t be expected to know whether a device/integration needs an add-on/server or not… and since everything is listed under Integrations, it makes sense to start there — except integrations requiring add-ons/servers need that installed first, so does the Integration setup explain that? Some (though unfortunately not all) integrations will even be auto-discovered after add-on setup (see: Matter & Wyoming). And other (though unfortunately not all) add-ons that aren’t auto-discovered can automatically configure the Integration after setup (see: OTBR, ZwaveJS). But the rest need a way to alert users (who don’t read the docs) that they’ll have to manually add and configure the Integration once the add-on with the same name is setup (see: NUT). Certainly it would be nice if you went to add an integration and it had friendlier workflow to explain when an add-on/server is required, maybe with buttons for “I need the Add-on” (for supervised installs), “I already have [server name] set up”, or “I need more help” link to the docs. (I’m not a HAOS user, maybe it already does this?)
Sorry guys, but as mentioned before, I see no point in me argumentering any further.
You have a car and you have a phone. To use your phone in the car, you need a mount. The car and phone are each devices in their own right, and the one can by used fully without needing the other.
Your car is HA.
Your phone is e.g. the MQTT add-on.
The mount is the integration.
Add-ons are applications completely in their own right (typically), often used for other purposes that has no relationship to HA.
This might be confusing for a couple of minutes for a new user, but since it’s documented and explained well, I see no point in creating more confusion.
You seem to deliberately labouring the point, even though you understand the difference.
I totally agree with that. I’m glad to know what is an integration and what an add-on and the way to integrate them. Two several processes for this are ok and understandable, imo.
so long
Pc
Coundn’t agree more. While this distinction might make sense from a developer point of view it makes absolutely no sense as a user. Gets even funnier when you install HACS and thus add a THIRD place where you can go and search/download/install stuff from.
You want HA to do something it currently dosen’t? → There should be ONE single point where one can search for that and install it. One could still differentiate what it is you are installing and where it comes from with e.g. tags and by offering the choice of what parts to install and explaining what they are good for, but the current situations is truly ridiculous and just an unecessary threshold for people getting into HA.
1 Like
Just to be clear, please answer this question here:
Please let me know if you are confused on what to add with the questions at hand.
Are you asking me?
I asked both of you.
Bonus points if you can also provide an answer for installing NUT.
1 Like
Seeing just this list I wouldn’t know what to install no matter if they are in one or two places. But seeing all of them in one list at least tells me what I have to educate myself about, if i wanted to find out. As I said: Tags and explanations could help here.
Ideally there should be one single button saying e.g. “Frigate” and clicking it would educate me what it is and guide me through the install process by e.g. asking me “do you want to install frigate as a stand-alone network application or do you want it accessible from within Home Assistant?” just like e.g. a Windows Installer will ask you wether it should install e.g. a missing framework that is needed to run the GUI of a software within Windows.
From a user perspective whether Frigate is a integration, add-on or whatever the heck doesn’t matter - you just want Frigate to work.
And NUT: Bonus points indeed, if anyone could finally tell me how to get this working. I’ve been trying for months by now! Just having a single install that in the process scans the network and offers you what UPS’s it finds would be great. But instead you get an add-on and a integration that both need cryptic manual configuration!
Some HA developers and stakeholders seem to be, sorry for the expression, a bit narrow-minded. This might be because they tend to focus mostly on the technical side of things and have a rather conservative approach to the user interface, often lacking an understanding of basic UI/UX concepts.
What I’m trying to say is that for an average non-techie user, there’s no need to understand the difference between ‘integrations’ and ‘add-ons,’ just because one runs in the same address space as HA and the other runs in a separate container.
But if the target audience is techies, I’d understand why things are the way they are.
1 Like
Very well put. If this mindset doesn’t change HA will never live up to its potential of being the gold-standard of home automation.
1 Like
That’s the thing, you are thinking from the perspective of just home assistant. Here’s some facts about frigate (And many of these integrations).
-
Frigate requires MQTT Broker, MQTT Integration and Frigate integration, and Frigate Addon. That’s 4 things in the list that are needed. All with configurations. I accidentally omitted the frigate integration.
-
The only 2 things that are required for installation on the home assistant machine are the Frigate integration and the MQTT integration (both are technically optional, one or the other). The other 2 required softwares can be ran on separate servers. There’s no way HA will know what your intentions are.
Lastly, we currently do this with Zwave. All you need to do is install the zwave integration and it will automatically install addon based on a wizard. Guess what happens right now? People do not read the wizard. There are hundreds of posts on these forums because poeple just blindly check options (that have descriptions) without reading the descriptions. They end up getting into a support situation where things are messed up. The point I’m making, we tried this and it does not work well. Just wander over to the zwave section and look at all the posts where the zstick isn’t communicating, a large majority of these posts are because users double installed things because they did not follow the wizard and read the prompts.
Yes there is. Please understand that only 2 installation method has addons. The other 2 installation methods do not. Making a curated list with both will not work for these other installation methods because addons literally do not exist in that context.
So not only has this failed in practice (with zwave), combining the lists and wizards will be an development/upkeep heavy process. All for something that in will not help the situation.
3 Likes
UPS’s don’t connect to NUT over the network (some do, but it requires a NIC card on your UPS) and the NUT software is what would be finding your UPS.
If you have the NUT software running on your network, HA already automatically discovers it.
What stands out to me with your comments is that you currently lack the understanding that the NUT software needs to be running on your network. The addon just adds the software to into HAOS. HA will discover it regardless if it’s coming from the addon or if it’s coming from an external computer on your network.
Id say it proves my point: Any average user is lacking this knowledge. And an average user doensn’t want to have to understand anything about what NUT is and where it has to run. You just want to plug your UPS’s USB cable into you machine and have its entities show up in HA. End of story.
When building software the design process always has to start from the average users perspective, never from the dev side. That’s why product owners exist.
We do not control NUT. You understand that right? It’s a separate software that HA cannot automate.
These guys write NUT https://networkupstools.org/.
Not only that, but the addon is custom. Meaning we have even less control over how it behaves.
2 Likes
I personally understand that fully. But the average non-techie user does not.
Mind you I have worked as a Product Owner and understand how frustrating it is to dumb down software / UI / UX to make it work for all the non-techies out there. But the non-techies pose 99% of the potential user base and excluding them by design just makes sure that a product will NEVER EVER suceed commercially.
1 Like
There is an important distinction - if an add-on doesn’t work, HA is not (in most cases) responsible for fixing it. If an integration doesn’t work, it is.
Conflating the two would likely lead to frequent bug reports that are not HA’s responsibility. If the user is not techy, I would say it is even more important they understand that they are separate applications and to not blame the HA devs if something goes wrong with an addon.
1 Like