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
It was published when the decision was made… Just because you don’t partake in github doesn’t mean it wasn’t announced.
And before you get more upset, here’s a link to all the discussions anyone can take part in…
If it seems like I’m frustrated, I am. I’ve linked this about 90039409234902394 times and no one takes part and then comes here to complain.
Maybe not precisely when the decision was being made but there was over a month’s worth of advance notice right here in the forum.
There was the one posted in December (link in Petro’s post, a few posts ago) and then I posted a heads-up on January 5th when the PR was being processed (i.e. the official deprecation announcement was very imminent).
The December thread identified alternatives in the form MQTT IO and converting the official integration into a custom integration.
So to answer your comment, it was done and done yet the outcome was still the same (a tidal wave of misplaced outrage).
Also, affected users still have several months before the integration is actually removed so there’s plenty of time to make transition plans.
1 Like
Can we stop with using the stats, the decision was not solely on that. Does the lack of a maintainer not ring any alarm bells in your head, especially with some people the case of the rp_gpio using it for their security systems.
I must admit I missed that. Thanks for your community spirit.
1 Like