Integrating popular frontend custom cards on HACS to standard HA cards

Feature Requests
1

WHAT:

What I’m proposing is not so much a feature request but more of a program where the Home Assistant (HA) team collaborates with the developers of the most popular frontend custom cards on HACS to integrate them into standard HA cards.

I’ve already researched this topic and found this post addressing why HACS itself is not a standard part of HA.

I understand why the developers of HA might not want to make HACS a standard part of HA, as well as certain HACS integrations. One major reason is that they have no control over the company that makes the product the integration is for and the changes they make. So unless the company actually wants to work with HA, it makes no sense to standardize it.

However, I think the frontend custom cards on HACS fall under a different category. For the most part, the frontend cards are made specifically for HA and work with anything in HA that falls within a certain type of device class or can be used for all HA entities. There is no outside influence affecting them. I also think this decision would be left up to the developer of the custom card and not the owner of HACS.

WHY:

There are many great custom cards on HACS, but sometimes, over time and for various reasons, a custom card becomes abandoned and is no longer maintained. I assume that for those developers, maintaining the card is not a top priority. When this happens, what was once a great card eventually breaks and loses all functionality, which is frustrating for the HA community members using it.

HOW:

Idk what goes on behind the scenes of HA, but can’t the developers create some type of program for this? It would only apply to the most popular custom cards. I suppose there could be an issue with the developers’ proprietary rights regarding the idea and the actual code of the custom card. This is why I’m suggesting some type of HA program that works with the developer to integrate their custom card into HA as a standard card. Maybe the developer could still somehow have access to updating it and expanding its features, but HA would take over maintaining it so it always remains functional for HA users.

Again, I don’t know what goes on behind the scenes at HA, but it seems advantageous to the developers of HA, the developers of the custom card, and the community that uses both. Plus, if the Open Home Foundation fights for the fundamental principles of privacy, choice, and sustainability for smart homes, then wouldn’t something like this fall under “choice” and “sustainability” for HA community members?

2

The better way to go about that is to talk the card owners to contribute the cards to HA.

4 Likes
3

You have to allow for the fact that most developers published in HACS do so because they don’t WANT to deal with the rigor or schedule required for HA core / Lovelace. Add to this - the core dev team already has way more work than they have people for.

By doing what you suggest people who have no interest in signing up for the rigor are now beholden to help folks who already don’t have time…

This is a nice thought but a complete nonstarter.

4 Likes
5

I’m talking about a step past that which would be to make it standard in HA.

6

If people abandon their cards and they become unusable what makes you think that they would update then once they became part of HA.

1 Like
7

The whole way HA is structured is exactly so that the core dev team doesn’t have to do this. Any developer is free to push their work into the main repo if they are willing to maintain it according to HA guidelines and schedules. So, the framework exists.

2 Likes
8

And what in your suggestion prevent this from happening with the new setup?
It seems to still be the developers of the original card that maintains it and when it become abandoned, then only the HA devs can revive it.

1 Like
9

Core software needs to follow the rules of the core team. The opened end custom stuff it all at your own risk and you are responsible for the security of it. To make every repo that HACS was told to monitor by the author core status without vetting it, ridiculous. To properly vet all those thru the framework is ridiculous.

I’m pretty sure you have no idea how this all works. Maybe start with some of the change issues in the release notes and follow it back to the beginning to see what is involved, the tests that have to be written to vet core software, and the beta and approval process. You might better understand why some things are core and others are custom.

1 Like
10

@NathanCu it was just a thought like you said. It just sucks when a popular frontend card on HACS is no longer maintained and breaks, I’d think that because of it’s popularity the HA dev team would want to integrate it or it’s functionality into HA.

@nickrout I don’t which is why I was trying to propose something in which the HA dev team integrated the card or it’s functionality into HA. And I don’t mean everything on HACS. I’m only referring to the most popular frontend cards.

@parautenbach I had no idea. I thought the only way was to go through HACS. So if they do push it through to the main repo and for some reason stop maintaining it what happens? I’m only asking because I’ve never seen one added or removed. Aren’t the the same 25 cards released with Lovelace in 2019 the same as the ones that currently exist?

@WallyR that’s basically kind of what I’m proposing but I’ve honestly never seen the HA devs revive an abandoned card on HACS.

That’s not what I’m proposing at all and I do understand why somethings are core and why others are not. What I’m referring to are only the most popular frontend cards on HACS or the functionality of them. I know the HA dev team has worked to make tons of upgrades to HA and is working on adding more features but I can’t remember when the last time they’ve introduced a new Lovelace frontend card or added featured to a current one. Instead users turn to HACS to meet their needs for their UI design.

I absolutely love HA and can’t imagine being without it. However, I recently read THIS article on Verge stating that one of HA’s goals is to “stay swimming alongside Apple, Amazon, Samsung, and Google.” The article also points out that “onboarding devices can be complicated, the UI has lots of room for improvement, and integrations can be hit or miss.” I definitely think there has been a focus on two of those things with the UI being the exception. If HA aims to attract the same consumers who use the big brands, the dev team needs to realize that for these users, using HACS and custom cards is like rooting their Android device and adding custom apps and themes. It’s not going to happen.

The Lovelace UI was released in 2019 with 25 cards. Instead of waiting for another major UI release, I suggest the dev team consider annually adding to those 25 cards by searching out the most popular custom cards on HACS and evaluating if the card itself or its functionality should be integrated into the core of HA. Adding even one or two cards each year would also be a way to help make HA more consumer friendly.

11

There’s probably a ton of things that need to be considered: wide appeal, theme support, etc. I know a bit more about integrations than frontend cards.

Either an HA dev will need to support it or it will be dropped. Neither option is ideal.

EDIT: Actually, I’m not too sure. Integrations have an explicit maintainer. That was what I was thinking about.

I know of a few, e.g. the energy cards and not too long ago another one in that suite got added. While not a standalone card, sections were added too. Granted, all of these were HA initiatives.

1 Like
12

I think I have seen once an abandoned HACS project being revived as a core integration, so it does exist,but it is extremely rare.
I have though seen multiple abandoned HACS project being forced or revived, but non-NabuCasa people and that would not be possible with a core project.
Why compete with a perfectly well-running project just to secure it against being abandoned, which might never happen?

13

@WallyR I think it would help to make a better core system and stay relevant without having to depend on a third-party for certain functionality. I’m also not suggesting they compete with the project. I trying to think of a way to credit the developer and integrate it into HA.

I remember when vehicles only had radios which cassette players. Then electronic companies began making CD players that could be installed in almost any type of vehicle. Did car companies say why compete with a perfectly well-running project or did they recognize the demand and realize they needed to integrate that functionality into their vehicles?

14

This whole feature request assumes that “feature XYZ will be supported forever when added to core”, which is not the case. Things have code-owners, when code-owners leave the integration/feature typically suffers. Adding a card/integration to core does not guarantee it will survive long term.

2 Likes
15

Exactly what I was saying in post 6, but you probably said it better.

1 Like
16

Sorry, didn’t read the full thread!

1 Like
17

No need to apologize at all. We are both right, but some things need repeating.

2 Likes
18

Forgive my ignorance and I’m not trying to argue but just get a better understanding of HA and possibly clarify what I’m suggesting.

So I do understand what happens when code-owners fail to maintain their code on HACS (which is why I’m suggesting this.)

However, are you also saying that the same applies to a “standard” Lovelace frontend card such as the entities or light card that comes with HA and that I assume is part of the core?

My suggestion was entirely based on my assumption that when something is integrated as part of the core it’s survival is somewhat guaranteed (as long as the main HA Core code permits) because the dev team would maintain it. So as Lovelace is upgraded and improved, expanding the standard Lovalace cards based on the features of the most popular Lovelace cards on HACS would guarantee the survival of those features (which HA might even already do.)

19

The frontend is maintained by Core. All the cards are maintained by them.

There is no guarantee that anything survives in core. Things are added/removed/changed all the time.

I’d also like to mention that the majority of custom frontend cards that are available in HACs would not make it into core.

1 Like
20

Is this more because of choices made by the dev team or limitations due to changes in the main code? Just curious.

Without going into detail is there a simple explanation for this? Again just curious and trying to learn more.

21

Choices by the development team. There’s a number of employees who’s job is to design the frontend and implement it.

See previous.

1 Like