I get that HACS is custom, and not everyone uses it. But in the past year a few integrations were added from scratch to HA that already had a very solid HACS integration available.
And I also understand that it is the HACS integration’s owner’s responsibility to try and get their integration into HA if they so wish.
But having said all that, when a new integration gets added to HA, there seems to be no (from HA’s side) communication to the existing HACS integration owner. So new integrations get added for LG (granted the core one is made by LG, so it will hopefully get better support than the HACS one), myuplink (solid HACS integration in place with the core one being initially feature limited), nordpool, etc, etc.
And I get that anyone can create a core integration from scratch to add to HA if there is not one already in core (despite there being a HACS one).
But ultimately (and I guess this is the core issue) this fragments and upsets the userbase. New users looking to add a myuplink device to HA, for example, will get Google results for the HACS integration as well as the core integration, with different information in each. And then need to decide which one to follow (or click the top result and go with that.)
Existing users will either already have the HACS myuplink, or switch to the core integration. At some point one or the other may stop being supported (regardless of there being duplicates, this is obviously always a possibility), and users will be forced to switch. Which will bring loss of historical data. (I now have 1 years worth of statistical data for my HVAC system that I compare current usage to. So I am locked in to the HACS myuplink integration).
I understand sometimes HACS integrations don’t cut it and can’t be added to core. Or maintainers don’t want to. But from an end user perspective (with limited coding experience), it feels like we’re being let down, and I don’t know how to migrate from the HACS integration to the core one. (or even when to do so depending on maturity levels of HACS vs core integration).
For people that are comfortable hacking away at HA, this may seem trivial. But for the larger userbase who is less technically savvy, this alienates us.
So the main request is, add some workflow for new integrations to make sure there isn’t a thriving HACS integration, and if there is, at the very least reach out to that before starting a new one. Maybe the maintainer would like to work with whoever is trying to start the core integration to add theirs to core.
Ultimately by duplicating integrations, there will be resources working on both the core and HACS integrations, when those same people could be working on a single integration, thereby increasing support, knowledge, etc, etc.
On the contrary, it is great to have the option to choose which integration fits your use case best.
e.g.
At one point there were three ways to connect Lifx lights.
Core integration
Core Homekit device integration
Third party integration
The Homekit integration was the simplest to connect but lacked some features.
The third party integration had many new and improved features not in the core integration and had a rapid development cycle that allowed for testing and improvement. This was eventually merged into core after testing.
Homekit integration aside (as that’s a Homekit integration, not Lifx, so they have duplicates for anything they support) (At least, not having homekit, that is what I assume)
There was a core and HACS, one of them was more actively developed, became more mature, and was merged into core.
And depending on how that went (I don’t have Lifx, so can’t say), this either was done seamlessly (entity names remained the same), which would be best case scenario. Or there was impact to the userbase whose entity names did not stay the same. And a potential migration path of things to adjust/change to get the merged integration working.
I am not saying we cannot or should not have duplicates. But I am saying there should be someone looking at this and at least observing that there IS already a HACS integration, and check with the person trying to put a new integration in core if they are aware of that, if there’s a reason they want to start from scratch, and check with the existing HACS integration owner to see what’s going on.
And then multiple outcomes can happen:
Person trying to start core integrations joins in updating HACS integration (and either works towards getting it into core, or just leaves it HACS)
Person working on HACS integration works with person trying to add to core, and they merge code in there
Both parties disagree, and decide to go their own way
Any other option not listed.
In the case of the 3rd option we’ll still have duplicate integrations, but it was at least an informed decision. There was an attempt to consolidate, keep things simple, and it just doesn’t work, make sense, or wasn’t what either party wanted.
I am not saying we shouldn’t have duplicates. But duplicates (from the HA side) should be informed. Else you get integration sprawl, and have integrations that die down because others are better. And end users frustrated because they now have to figure out how to migrate their dead integrations to the “winner”.
We’re not going to avoid those scenarios. But from the HA side, as project owners, you should want to reduce duplications and end user frustration.
In most cases, custom integrations are not in core because they employ functionality that would not be allowed in core.
When that integration is then moved into core, that functionality would be omitted or drastically changed so that it fits into core architecture. Requiring users to make changes to their automations to get back up to speed.
There is no migration path for things like that, it’s something the user will need to touch.
On top of that, even if a migration “functionality” was added, users would still need to manually adjust things through that migration path. It just puts the burden on the developer and offers very little benefits to the user.
A good example of this:
I built a custom integration that adds a service to a sensor. This service swaps between active media players and it adjusts calculated volume based on which meida players are active. I built this integration ~5 years ago when select entities didn’t exist. If I were to add this to core, the sensor would remain the same but I’d make the service into a select entity. This would force people to swap the service call and entity_id.
Requiring a migration path would be an immense amount of work that I would not want to do when the user has to manually adjust these things anyways. The only benefit would be saving a few button clicks for the user, but the tradeoff is that I now need to spend 40 hours developing that. No thanks!