Integrating popular frontend custom cards on HACS to standard HA cards

Feature Requests
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
22

There seems to be a misunderstanding regarding “the dev team”. :slight_smile: The so called “dev team” are some (not many!) fulltime developers, paid by NabuCasa, but the majority of the dev team are people like you and me, that want to give back to the community by developing code, @petro is one example.

So in reality the dev team is actually more of a community, that works in their free time for the project. A classic open-source project. Everybody can join and make suggestions for changing the code.

Most of them don’t fit the guide lines setup be “the dev team”. That doesn’t mean it would be a “bad card”, it just doesn’t hold up to the standard that “core” HA cards need to. Alarmo for example, is a really great integration and works really nice. Nonetheless it would not fit the guide lines for a “core” integration, because it has a seperate UI for itself (and some other things). This is frowned upon for integrations…

2 Likes
23

Thank you.

I appreciate the explanation. I understand the concept but not so much how everything comes together for it to be what it is. I also can’t even begin to imagine what goes into an open source project of this size and I have a lot of respect for the devs that contribute to make it what it is. That’s one reason I pay for Nabu Casa, to give back what I could. I wish I knew more so I could contribute more but unfortunately I don’t. I actually don’t even like posting feature requests and have deleted several before I even posted them because I feel like I’m bothering the devs with something they don’t need to be bothered with. Lol.

24

How everything comes together is a different thing. Nobody knows how that works :joy:

No, seriously, it’s not that complicated, it just looks like that from the outside, and what makes it complicated in reality, is the sheer mass of people to handle.

From top to bottom:

Level in hierarchy Who? Note
1st Paulus Last instance, if he says no, it’s no
2nd Core Dev Team Employees of NC
3rd Members Most active volunteers, can be considered part of the Dev Team.
4th Code Owners People responsible for one or more integrations, like @petro
5th Contributors Community members who contribute to various parts of HA
Base Supporters & Users This is you and me, here in the forum, Discord, Facebook, etc.

This is not a complete list, and there might be people in more than one level, there might be sub-levels, but it’s just to show a little example.

If you’re a developer, you can develop some code, and submit it to the repo of HA on Github.
The next level will be the code owners. They are responsible to check, and see if the code is valid, fits the guide lines and all that. They are as well responsible for the code to fit into the integration, they’re the code owner of.
If the code owner gives there go, the code will get further up, and the dev team decides, if the code fits into HA. They’re responsible for the bigger picture. Does the code make other things buggy or invalid, will there be some other area, where this code might cause issues, all these things.
If there are problems, the last instance comes into play - Paulus decides what to do.

All this gets a little mixed up, because people are in many cases “members” of more than one level. If Paulus writes some code (what he does surprisingly often), he’s all in one, developer-to-code-owner-to-dev-team :laughing:

In theory, all the NC employees are just members of these different levels. You might want to see it like a company, where Paulus is handling paid and non-paid employees.

But please note, this is a very minimalistic approach of an explanation, the reality is a little more complicated, as usual. :laughing:

A lot of people have their NC subscription for that reason. I do as well. :laughing:

And trust me, if the input is not nonsense, it is welcome! Feature requests in this forum are exactly for that. You propose and describe a feature, people discuss it, and if things go well, someone will pick it up and develop said feature.

This sub forum is not a direct path to the developers, they might take a look inside this category from time to time, but it’s not like if a FR gets enough votes, it will be developed. The better it is described, the higher the chance, someone will pick it up and will either develop it by himself, or takes the input from here and makes a feature request on Github. That’s where the developers come into play and what I described above starts… :smiley:

3 Likes
25

I extremely appreciate that explanation. That’s one of the things I enjoy so much about HA… the community. For the most part, everyone is willing to help and will do what they can to answer someone’s question. The dashboard that I started with compared to the dashboard I currently have is a testament to what I have learned with the community’s help. HA also tends to be a little additive because when I get stuck there’s no putting it down until I figure out a solution.

I would really love to learn how to develop my own frontend cards. That’s the one thing that I haven’t stuck with and solved. I have basic programming knowledge and have tried to utilize some online tutorials but I get lost rather fast. I’ve tried the approach of using someone elses card on HACS but I don’t quite understand the dynamics of Github and forks or branches and how to go about starting. For example, there’s a custom cover card that I’d love to change from it animating blinds opening and closing vertically to curtains horizontally but I haven’t had any luck. Hopefully one day I get it and if I do I’m sure I’ll be able to use what I learned to develop more and then maybe start making a contribution back.

Thanks again for the explanation.

1 Like
26

So, if I understand it right, this is actually coming, at least to some extent:

1 Like
27

The part you quote is followed by this completely useless table

[table of cards to be revamped]

28

It’s not a table. Which makes it rather clear they forgot to add the table or haven’t really made one at all. Either way, what’s your point?

29

Well there seems to be a promise that they’ll tell us what cards are going to be worked on, then forgot to do so. Unhelpful.