Plus add version tag 
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