I think thats a superb idea
Hopefully someone will add to HACS to save 1000s of people doing this individually, assuming they are capable. 
Said the same again and again.
If there is a sin on the devs side, itâs that donât seem to act (or at least donât tell) on what seems a win-win-win for core devs, integration devs and users.
It could actually start now if new integration devs would submit to HACS rather than coreâŚ
1 Like
Oh I agree, but as you can see from the responses in this thread, removing stuff and having it loaded via HACS or manually seem to get a lot of people bent out of shape when they still have the option to run it
Not going to happen. The HACS developer has repeatedly said they have no interest in bring HACS into the core.
HACS or something else, now or later, HA proper or a fork, it will happen, mark my words 
Oh i know @tom_l but it would solves the issues presented above
If it broken then it the maintainer issue, The maintainer and its ussrs then become responsible for testing during beta etc and not HA team
If people want to run unmaintained, possible broken software then they are responsible for it, nobody else
I think (I donât use GPIO so Iâm not sure) that it is just awkwardly explained. It makes sense to not integrate hardware specific integrations in HASS, because it shouldnât be the task of home assistant to handle actual âdevicesâ. If there is many users the positives of an integration might outweigh the negatives of maintaining them, but otherwise itâs better to âmodularizeâ it.
So, in short, you can still use GPIO from any device of course, the handling of the GPIO itself just wonât be the task of HASS, HASS will just receive the necessary messages.
Think of it like the change where zwave was moved to an external server. It confused me at first as well, but in the end it made a lot of sense. The issue of course is that it is a breaking change, which is always annoying, but we should allow the devs to fix past mistakes, otherwise hass will just get held back by lots of legacy stuff.
Just to reiterate, you donât need another device, you just need to handle the GPIO signals in a separate service (which now could also be a totally different device).
Yes indeed.
If you search for the phrase in this forum, youâll see it has never been used to describe this project (only one other hit and for a different context) so it was overdue to state it plainly in order to disabuse anyone from the notion that this project was in any way different.
Itâs an homage to the spirit of many posts that promote fear, uncertainty, and doubt. The most common one is the slippery-slope hypothesis; something changes and it is held up as a sign that itâs the future for everything else. If you have the stomach for it, review the posts here and in the dedicated gpio thread and youâll see how there are unfounded fears and predictions how all low-use integrations will suffer the same fate.
If you have lots of extra time, review the old thread where thereâs the claim that all YAML will soon be eliminated (itâs an old thread so their prediction is obviously false ⌠yet people still add their fearful comments to it because they no longer understand the original context and the thread is now an example of the âtelephone gameâ).
Then you missed them because theyâre definitely there. If I didnât value my time, I would link a few for you. As an introduction to FUD, read the YAML thread.
What words did I use to âwrite them offâ? The gist of my statement is you canât please everyone all of the time. The evidence is not only found here but in everyday life.
4 Likes
Hereby I sign the petition. +1
Well said, and I think this is the way many who raise concerns here feel.
The general tone of responses is dismissive of the concerns raised. People have put a LOT of energy into âprovingâ that the users of this feature are somehow wrong, foolish or just complainers. Some have taken this opportunity to push their favorite platforms (ESP, MQTT, etc.) as if they were somehow equivalent to direct GPIO usage.
Another misconception is the idea that any feature without an active, assigned developer should be abandoned. Thatâs not how any development project works. When something changes which impacts an already-supported function, someone gets assigned (or volunteers) to fix that function.
There are active components which always have developers working on them. But there are other components which just work, and have worked for a long time. These donât need day-to-day attention.
Labeling anyone who points out an issue as a complainer isnât helpful. By all means, challenge them if they didnât read the previous discussion. Call them out if theyâre nasty or make ad hominem attacks. But why is it necessary to put so much energy into dismissing their concerns?
To me, changing rpi_gpio to a custom integration is ideal. I think more integrations should be optional add-ons. This makes them independent of core updates. I even wrote a FR to that effect once.
5 Likes
With all due respect. Continuing this conversation does not help. Especially from you, who has prior knowledge to this removal more than a month and a half ago in this thread.
You were privy to the conversations. You know the reasons are not just âAnother misconception is the idea that any feature without an active, assigned developer should be abandoned.â.
Yet here you are, still fueling the fire. Please stop.
For anyone else that stumbles upon this, here are the actual reasons why itâs being removed.
Please take extra care when reading bullets 3 and 4:
5 Likes
I move the post to the appropriate thread.
I understand that you are fed up with this topic but my post was meant to be a suggestion on how to proceed.
This is not a business where you pay people to do a job and make demands. Even so, you canât just give them any job. If youâre unreasonable, theyâll leave. Source: Iâm an IT manager and former dev.
1 Like
I was not replying to you. If you notice at the top of my reply, youâll see who the reply is to.
Youâre right. Excuse me.
If you want to edit or delete the post.
I posted my speech on the thread you indicated.
Be patient but the topic is very heartfelt 
.
Just use the Custom Integration⌠Youâre literally losing nothing by switching.
well it doesnât mean deprecated anyway.
1 Like
I suggest this scenario (whether for gpio or any future similar integration deprecation) would have been much better handled in this way:
If the devs had made a blog post saying âwe are forced into a position that weâll have to remove GPIO because it has no maintainer, step up or itâll go in 4 months.â Low and behold, @thecode steps up, problem averted.
So devs, how about a slightly friendlier approach. Itâs pretty hard to keep up with github, discord, discourse etc, but a blogged list of what needs attention or maintenance may reduce your load and improve the process.
9 Likes
This is the first Iâve seen of this âlistâ of declarations, and I consider myself to be a pretty active user. Perhaps if more people knew about this list, this particular brouhaha could have been avoided. Clearly there was some thought that went into this decision, and whether everyone agrees that the thinking is sound or just a formalized justification of âitâs too much troubleâ can be debated ad nauseum, but it is what it is. If this had been published when the decision was being made, perhaps as @nickrout suggests below, then people who rely on this functionality would not be finding out about it in a major release. Who knows, perhaps even one enterprising soul would have a unique solution, or could take over development, or add a new component, etc.
Itâs not about users having a âvoteâ, itâs about being considered as a partner in something weâre all striving toward, together. To put it bluntly, if it werenât for users, HA developers would be wasting a whole lot for their time for NOTHING. Clearly, those who started this movement wanted something bigger, whether fame, fortune, or to do something thatâs never been done before. Either way, a robust, happy., and enthusiastic user base is paramount to that success; otherwise, youâre just sitting on another dead-end branch of unused code. And there is a whole lot of that in the world.
Also, isnât it a bit dangerous to rely too heavily on the stats of who uses what (ref: 0.8%) when making these decisions, knowing that not everyone reports usage? For example, who uses EVERY integration in the default list? I can attest that there are some in that list that I DONâT use, ever, like TTS. So those integrations are clearly over reported.
3 Likes