core Duplicate myUplink integrations. HACS version is a lot more mature than the core HA version.

The problem

HA added a brand new myUplink integration in 2024.02, however there is already a very mature HACS integration (https://github.com/jaroschek/home-assistant-myuplink) that does a lot more (and uses the same domain), so users are now stuck between picking the core integration that does not support all systems, or a HACS version that does have all the required functionality. And in the mean time both are being updated and maintained, so that's (in my view) duplicating effort.

What version of Home Assistant Core has the issue?

core-2024.2.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

myuplink

Link to integration documentation on our website

https://www.home-assistant.io/integrations/myuplink

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I currently use statistics on my HACS myuplink entities to compare historical usage data to current data. So a potential future switchover from HACS integration to core would be impactful. A lot of people that need write access to myUplink will be pushed towards the HACS integration instead of the core one. What are the options to consolidate this and move towards a single integration to avoid duplication of effort and allow all users full functionality.

Mar 08 '24 14:03 JvdMaat

Hey there @pajzo, @astrandb, mind taking a look at this issue as it has been labeled with an integration (myuplink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of myuplink can trigger bot actions by commenting:

@home-assistant close Closes the issue.
@home-assistant rename Awesome new title Renames the issue.
@home-assistant reopen Reopen the issue.
@home-assistant unassign myuplink Removes the current integration label and assignees on the issue, add the integration domain after the command.
@home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
@home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

myuplink documentation myuplink source _{^{(message by IssueLinks)}}

Mar 08 '24 14:03 home-assistant[bot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Jun 06 '24 16:06 issue-triage-workflows[bot]

No answer yet, and both are still there.

Jun 07 '24 12:06 JvdMaat

Would be nice to hear something here

Jun 16 '24 12:06 whizkid79

I know this isn't productive, but devs, please have a look at this.

Aug 26 '24 15:08 enoch85

Have you tried latest 2024.11.2? It's amazing!

Nov 15 '24 22:11 enoch85

@enoch85 time to switch from the HACS integration to core?

Afaict, the core integration now has write access, supports my model (F-1155), and filters out some unneeded entities (the daily schedules). Would there be any downsides besides a discontinuity in historical measurements?

Nov 16 '24 07:11 IngmarStein

@IngmarStein I've been running both HACS and the core version. The core version was pretty bad until yesterday.

I'd say do the switch! Yes you loose the history, but IMHO, HACS is just a supplement to stuff that's missing in core, and now when that's sorted with equal (afaik) functionally - well there's no reason to run it on HACS any more.

Nov 16 '24 08:11 enoch85

I will close this issue though. Feel free to continue the conversation, but this isn't an issue with the codebase and thus does should not have an open issue for it.

Nov 16 '24 08:11 joostlek

While not an issue with the codebase itself, I think it's an issue with the process of adding new integrations. This core integration came out of left field. Who decided to make one from scratch when there was a good HACS one available? Is there no review of what is out there already that could be incorporated (or revamped for incorporation) instead of creating new from scratch? This just fragments the userbase into those that have used HA for longer (and use the HACS integration since switching to the HA integration makes us lose all historic data we've already collected and use for YoY comparison), and those new to HA who can now use the integrated one. And now two nearly identical integrations (core and HACS) need to be separately maintained. The same just happened with the LG ThinQ integration (Though that was slightly different as it sounds like the new HA core integration is actually made by LG (?), whereas the HACS version was by independent developers). But again, we now have a userbase where some use a HACS integration and some use a core integration to do the same. (And those are just two HACS integrations I used that got new core integrations from scratch. I'm sure there's others I am not aware of).

There should be someone on the HA (Nabu Casa) side to oversee this and either mediate combining HACS integrations into core integrations, or go through some other process to avoid this fragmentation. Or make an informed decision to create from scratch and at least let the HACS integration owner know so they can see about providing a migration path into core to enable users to retain all their statistical history? @balloob? Else you're just alienating the userbase that uses the HACS integrations that have been replaced with core ones.

Nov 18 '24 16:11 JvdMaat

This core integration came out of left field. Who decided to make one from scratch when there was a good HACS one available? Is there no review of what is out there already that could be incorporated (or revamped for incorporation) instead of creating new from scratch?

Not all custom component developers are willing to contribute to core. They either want full freedom of their releases or don't like the extra hassle. We don't require a new developer to first check with them.

switching to the HA integration makes us lose all historic data we've already collected

There are tools for that. But this is the result of the risk of using a custom component.

And now two nearly identical integrations (core and HACS) need to be separately maintained.

So? If the HACS developer doesn't want to work on core, we can't help that.

The same just happened with the LG ThinQ integration

And yes, the HACS integration for LG provides more, but LG implemented it themselves and they used the official API. There are also people mad about that. We can't prohibit developers or companies to implement an integration with less features just because someone made something custom.

Keep in mind, there are many reasons developers choose to go custom. We have a higher bar of quality at core. While HACS integration can be shit (Remember when 2024.10 dropped and Alexa Media Player messed everyone's system up? that was an AI generated PR that was not reviewed or tested). That would never happen in core. We are stricter, prohibit certain constructs. And that's not for everyone and that is fine, you can go custom. We are strict to maintain a good user experience.

But there is also a trouble with how to reach the custom component devs. If a custom component dev would send me a message on discord or whatever and ask me if I can take a look at their code if it is viable to bring to core. I would take time to do that. I love bringing new people in contact with core. To give an example, I created the mealie integration, apparently right after someone else made a HACS one 3 weeks before that. Now we work together on the core one and it works well. Just because the HACS developer commented on a PR and we had a conversation over discord. Same situation, but with another ending. I am drifting away from my point here. Those devs are not around on our dev channels on discord (some are, like powercalc or measureit, and I have good contact with them). So how should we reach them? I find it very blackmaily to send them an email "hey, x wants to implement the same integration like you have, you can choose to stay working on HACS or help collaborating". I would be very mad if someone reached out like that as it sounds like a threat to shut down my own work. Because in essence, it will mean that your user base will slowly go away as core will be there for new users and old users slowly move away.

My main point being. If developers don't have a reason to bring it to core when they started, why should we try to convince them? In our current ecosystem, we don't care what you use. If you are happy with the myuplink HACS one, just keep using that if that makes you happy. We don't force you to move over.

Or make an informed decision to create from scratch and at least let the HACS integration owner know so they can see about providing a migration path into core to enable users to retain all their statistical history?

This can be implemented in the custom component.

Nov 18 '24 16:11 joostlek

That's a fair point. From what I could tell, the devs for LG ThinQ and myUplink were both unaware there was a core integration being added. So they may have been willing to share code, migrate their code into core (or work on making their code able to go into core), or collaborate on creating a core integration (or just not be interested). I'm experiencing this from an end user perspective, and it's a frustrating experience to have a HACS integration and then find out there's a new core integration available, and no planned or easy migration path available. (Or not knowing if I should stick with the HACS integration or switch to the core one. (Which highly depends on the devs. Will the HACS integration continue to be supported, or will that stop for whatever reason?)) I recognize that HACS is custom (and not technically supported). But when you have a smart device that isn't in a core integration, HACS is the only option, and most people will gladly use that (as opposed to not having access to that device from HA at all). I guess what I was looking for was some acknowledgement when a new integration gets added that has a larger existing userbase on HACS, and maybe more info on what to do (and yes that would require HA to reach out to the HACS dev on their github or elsewhere, and them being responsive).

At its core, HACS is custom, and Nabu Casa does not support them. But they add significant value to HA as a whole by providing integrations not available in core. Creating new integrations to replace HACS integrations (without trying to work with the HACS developers) is bad marketing and could potentially reduce willingness of developers to create custom integrations. (Why bother? HA will just create a new one at some point to replace all my work).

So how should we reach them? I find it very blackmaily to send them an email "hey, x wants to implement the same integration like you have, you can choose to stay working on HACS or help collaborating". I would be very mad if someone reached out like that as it sounds like a threat to shut down my own work. Because in essence, it will mean that your user base will slowly go away as core will be there for new users and old users slowly move away.

Wouldn't it be good to know that before it goes live? Maybe they want to collaborate? Maybe they want to use their code. Or maybe they won't care and want to keep working on their custom integration. But at least then it's planned and informed.

My main point being. If developers don't have a reason to bring it to core when they started, why should we try to convince them? In our current ecosystem, we don't care what you use. If you are happy with the myuplink HACS one, just keep using that if that makes you happy. We don't force you to move over.

Some may be very willing to go to core, but just haven't thought about that because it started as a hobby project just for themselves and then became a full fledged HACS integration as others found it and started using/contributing. But by creating a new core integration from scratch the users are going to get caught in the proverbial crossfire where they either need to move before the HACS integration stops being supported due to declining use, or not migrate, but miss out on additional functionality the core integration provides. Ultimately it decreases the overall HA user experience.

Nov 18 '24 17:11 JvdMaat

At its core, HACS is custom, and Nabu Casa does not support them.

Keep in mind, the Home Assistant project does not support them. Not Nabu Casa.

I recognize that HACS is custom (and not technically supported). But when you have a smart device that isn't in a core integration, HACS is the only option, and most people will gladly use that (as opposed to not having access to that device from HA at all).

And I get that, but that comes with a risk. Either the development stops or the integration stops working with HA or the integration breaks your system.

I guess what I was looking for was some acknowledgement when a new integration gets added that has a larger existing userbase on HACS, and maybe more info on what to do (and yes that would require HA to reach out to the HACS dev on their github or elsewhere, and them being responsive).

I mean we are going to have the same thing next release as nordpool will be a core integration from scratch. I will definetly try to think about it, also with Missy to make sure we keep the dev eco system open.

I personally really like to see new developers succeed. For example, I am now working on a new integration quality scale system which renovates the silver, gold and platinum by introducing a bronze scale which is the bare minimum for new integrations going forward. This will give a better expectation of what we expect from you when you are going to contribute it to core.

And this is also an open invite for everyone who wants to contribute to core, if you are unsure if your integration is fit or if you want to have second opinions on thins, feel free to send me a message.

Some may be very willing to go to core, but just haven't thought about that because it started as a hobby project just for themselves and then became a full fledged HACS integration as others found it and started using/contributing.

I think there is also a task for the end user there. Try to motivate the developer to contribute to the main project. We as project don't hunt for new integrations. As in, new integrations are nice, but its not that we want x new integrations every month. So that's why we don't actively reach out.

But thanks for understanding. This isn't an easy problem and usually people are more hard with these discussions :)

Nov 18 '24 17:11 joostlek