Removing when it breaks makes for a worse scenario, they do not have any time to try and find alternatives. deprecating and giving people the deprecation time is a better solution
I really don’t see what the fuss is about, you can take the existing integrations and make it a custom integration yourself or in this case someone forks it and allows it to be installed via HACS or manually
So any core integration with no current maintainer is now on its way out?
Those number conveniently omit the core integrations (that are maintained by the main team). The original person who came up with those numbers did not include them in the calculations. This kind of miss information just leads to the argument that we are seeing.
Everyone:
Can we all please stop this?
There’s a solution. Regardless how hard it is with HACS, there is a solution that will get you exactly what you want. There always has been. Not to mention, you don’t need HACS in order to get there either. HACS is just an installation integration. You can always install these manually.
Repeating the same tired crap over and over again does not help anyone.
It doesn’t matter because you can take any integration that is deprecated and make it custom.
Is WWN now in HACS, too?
I saw GPIO moved to HACS, which is great kudos to the person/team who stepped up.
I didnt see anything about WWN integration. If I missed it please can you link the post…
I cant answer that,
Personally i believe HACS should be a core integration, and all other integrations classed as custom and are added using HACS mechanism as and when needed
That way if they are abandoned by the maintainer or is broken based on the current HA version then you install and use at your own risk and the maintainer of that integration gets all the flak and not HA
This then removes the huge burden placed on the HA team to try and make sure every current core integration still works each month. The onus then moves to the maintainer and users of those integration to test
I have no idea. But you can copy the integration files from home assistant core and put them in your config\custom_components\<name_of_component> folder and you’ll have it working in future versions.
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…
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.
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.
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: