The deprecation is not “active” yet.
I’m sure the documentations will be updated when it is deprecated. Or anyone can do it via GitHub.
I believe very few have their RPi next to what they are trying to control.
Looking at the analytics about 1000 use some type of GPIO compared to 130 000 installations.
Sure, not everyone has opted in to analytics but I doubt it has much effect on the percentage.
I totally agree with @CaptTom the reason I use HA Core with the Pi is because of the functionality of the Pi and the fact that you have these pins that do all sorts of wonderful things. Sort of takes me back to the days of the ZX80/81 and the early days of home robotics.
I used NodeRed extensively for my home automation before I came across HA, for the very reason that it utilises everything to do with GPIO. It’s one of the coolest things about the Pi.
That’s still 1k users then. It’s dangerous to use analytics in that way. Only 1k people use it, we can just remove it right ? What about some other features only 1k people use ? Remove them too ? And little by little you’ll lose more and more of your power users who opted to go with HA because it would cater to their specific needs. You’ll end up with only the most ‘popular’ features left, the lowest common denominator, the Tuyas, Hues and Echos. A popularity contest. Of course you need to focus development especially if you’re limited by (voluntary) resources. But chose wisely what you cut out. These power users are also the ones that are most likely to contribute to the project.
Haven’t really looked into it, but it’s probably just a matter of taking whatever was in the core before and repackaging it as a custom integration, maybe with some small mostly cosmetic changes and API glue. Functionality wise it would be pretty much equivalent. Of course someone still has to do this (and take over the responsibility of maintaining it !).
The main difference is that this IS supported elsewhere.
I understand that it’s not great to delete stuff, but given that this exact thing is supported within ESP-Home then I would call it a move and not a removal.
Since ESP-Home became Nabu casa it’s understandable, before that the GPIO was the main integration and ESP-Home was the “custom”.
Now HA has two integrations that do the same thing, one has 18 k installs. Maintain both or deprecated one?
I understand that Tom and Reena is frustrated with this but I find it “not unreasonable” to deprecate it.
I hope the integration/code stays there until it “stops working” due to other things breaking it and that it’s not just deleted in, say February or March. That would be a fair thing.
But demanding that two components doing the same thing is maintained is in my opinion too much to ask.
Things change, just like yaml vs GUI that there was a hugh uproar about, but that too works well today.
Building a smart home will never be a walk in the park, things happen all the time and you need to adjust for that.
This is a notice of something happening in the future, it has not happened yet. Calm down and try to find a way around the issue instead in my opinion.
ESPHome and GPIO support on the Pi (or on other SBCs) are not the same, and while there might be functional intersections for certain use cases, they’re not interchangeable. Trying to shoehorn native GPIO support into ESPHome by throwing yet another microcontroller into the mix, just because we can, doesn’t help the cause. It’s a work around, not a solution. It will create additional points of failure, additional maintenance requirements, additional power use (as little as it may be), additional devices on your LAN or Wifi, additional security implications, additional latency, and all that for no additional benefit in this particular scenario.
I mean just my thoughts, because if I used GPIOs I would just go the MQTT route anyway. Not a big fan of ESPHome (and ESPs in general) myself, but that’s subjective obviously.
What is it you mean that the RPi GPIO supports that EAP-Home does not?
Just reading the documentations I would say ESP-Home had the upper edge, but perhaps I’m missing something since I haven’t used RPi GPIO.
The point is extra and unnecessary hardware between the RPi and the device, regardless of where it sits.
So Dev’s estimate there are 4 to 5 times the number of installations quoted, as that is just the people allowing collection of analytics, so 4 or 5 thousand users of GPIO. In addition you have not included all the integrations that directly use GPIO such as 1-wire (264 users in analytics, another 1000 or so), anything using I2C buss so more users.
Not that it matters one iota, as the decision was made and won’t change; we were not consulted because we are irrelevant to the projects direction, as harsh as that may sound. I have already found other ways to do it with no additional equipment, so it is not a big deal, just another frustration with HA.
ESP Home does not support RPi GPIO at all. It only supports ESP based devices and their GPIO. You would have to connect an ESP Device to the RPi (via wifi, ethernet or usb), and use the ESP device to interface with the field sensors or whatever you have.
But if the RPi is not close to the device you want to control it’s neither extra or unnecessary.
Think about what you just wrote.
How does that change the percentage? It’s still 1% however you want to read it.
No it doesn’t.
You can connect any device you want. You just need to add the relevant library.
And as I said before, you are more likely to find library’s for Arduino than RPi since Arduino is more generally used for IO than RPi.
But if you have a specific device you say ESP-Home does not support then please post it so that we can see what we can do for you.
Following this logic you could also argue that the zha integration should be removed as there is also zigbee2mqtt which does exactly the same thing or does it even better because of wider hardware support. And removing zha would free a lot of resources in maintaining HA. And zha and zigbee2mqtt are really meant for the same hardware. ESPs and RPis are something completely different. Then let’s also remove support for Tasmota as there is ESPHome. And let’s remove support for Google Home, everyone can use Alexa instead. 
I also think that the percentage of installation which use GPIO may be low but that these are installation by power users and tinkerers who are more likely to contribute to HA and to develop it further. And it is a pretty bad choice to make this user group unhappy.
ZigBee2Mqtt is a add-on, ZHA is core.
So not sure how your logic make those the same.
Tasmota is also an add-on.
Alexa and Google Home is not the same, that is two competing manufacturers so the integrations naturally is different.
Your logic is really bad.
Lastly, if this was used by “power” users then it would have been maintained by the same power users, right?
Why would these power users who develop themselves just let this be deprecated?
I may misunderstand, but as I described above.
If the GPIO platform is removed and I have a stackable fan board and I control the Rpi fan in front of the GPIO and the generic thermostat, how will I control it if I can’t activate the GPIO pin on the Rpi?
This is not true, I control and read devices from RPI GPIO that are 75 feet away, I use wire to connect them.
I did not say it did, I pointed out that it is many times the 1000 users you quoted that are affected.
Nevermind, you don’t understand the issue; we don’t want or need to add ESP home hardware/software and programming, we want to use native, RPi Kernel controlled GPIO. ESP Home cannot do that.
ZigBee2Mqtt is a add-on, ZHA is core.
So not sure how your logic make those the same.
ZHA is core and is not deprecated. GPIO is also core and is deprecated.
ZigBee2Mqtt is additional software which gets integrated via MQTT, so it MQTT IO which has to be used in the future to control GPIO. For me that looks like exactly the same constellation.
Tasmota is also an add-on.
Tasmota is not an add-on but also a core integration:
Alexa and Google Home is not the same, that is two competing manufacturers so the integrations naturally is different.
So are ESPs and Raspberry Pis. That’s the point.
Lastly, if this was used by “power” users then it would have been maintained by the same power users, right?
At the moment they all work fine. How often maintenance of these integrations is needed to keep them working? That’s a genuine question. I would expect that it is minimal but I may be completely wrong.
I will go the MQTT IO route to keep my sensors working. But these architectural decisions really make me think if it was the right choice to switch to HA.
And you didn’t read the very next sentence after I wrote 1000 users.
But as I pointed out before. It’s two integrations doing the same thing.
Nobody here has yet to explained what specifically you are lacking with ESP based equivalent.
My bad.
But apparently there is still a large enough users and developers interested in keeping both ESP-Home and Tasmota alive.
Both ESPs and Raspberries are still supported. Not sure what you are trying to say now.
One feature of Raspberry is about to be deprecated.
There is features of ESP, Google Home and Alexa that does not work or has been lost.
I believe that is correct but I don’t know.
You can possibly look at GitHub.
I do believe it will keep working for a very long time after the maintenance has stopped.
And that is why I think this is all unfounded drama.
It was probably a year ago the Broadlink yaml configuration was deprecated but last time I tried it, it still worked fine since I have just left it in the configuration.
Hate to quote myself, but here you go:
Add to this: creates yet another dependency into yet another ecosystem you don’t have control over (ESPHome). If the devs remove something from ESPHome that you’re using, you’re on your own (again).
@Hellis81, you are arguing very forcefully in favor of removing a core HA functionality which you’ve already said you have no use for.
Obviously you feel very strongly about this. I want to keep this discussion respectful and productive, and I want to understand your position.
You brought up the issue of monitoring or controlling remote devices, but that’s not what anyone is asking for. I happen to already use one ESP device for exactly that purpose. But by its very nature, the RPi GPIO solution is local. Anyone using it already has wires connected directly to the Pi.
Moving to an ESP solution would be adding additional hardware, power, software and WiFi dependency in between those wires and the RPi, where it’s totally unnecessary. I pointed this out early and often in this thread, as have others. Can you explain why you keep disagreeing with this assessment? How is adding all this overhead a good thing?
That is not the question I asked.
I asked based on your statement before
According to the documentations of RPi GPIO you get switch, cover and binary sensor, and you can use one wire with a different integration.
All these are supported in ESP-Home.
So, what device, sensor type, whatever is it ESP-Home does not support but RPi does?
The answer is not anything about wifi, extra power consumption.
The only answer I have seen yet that I actually feel for is the cooling fan. Although it’s possible to do it with an ESP I understand that is less convenient.
I’m not forcefully arguing in favor of removing this. You clearly have not understood or read what I have written.
My intention is to understand if there is a valid reason for this to continue that is larger than the work needed to maintain it.
I don’t know if I have brought up anything about remote devices but OK…
Local is a definition here, don’t you think.
When we talk about ZigBee being local we don’t mean we have wires across the room.
Local in the meaning of this forum usually means controlled within the LAN, and ESP-Home is local by that definition.
“The same” overhead is created by maintaining another integration (according to the devs). I can’t speak for them, but I do understand that more integrations in core means more things to test.
In my opinion, having the “same code” (same result) in two places would seem frustrating when doing the acceptance tests before the release.
But as I said before, I believe this is way too much drama over a possibly none existing issue for now.
I don’t believe there is much changes that has been done on the GPIO integration. I could see that there would be changes that is needed when RPi 5 is released (if that changes anything on the pins).
Instead of trying to make it still alive, try and get it to stay as deprecated in the core.
But my usual motto is that there is too much changes going on in life to bother with one, just adapt to the change and live on.
In this case, as I see it, it’s a fairly simple change needed to live on with local control (depending on definition) of the same devices.
I have had integrations stop working and I just adapt to it and find a way around it.
My ignorant mind finds it unnecessary to remove the integration, just keep it as deprecated, but perhaps there is something I (or we) don’t know that the devs know.
But to summarize, I do not forcefully want to remote this integration. I just want to understand what devices the control is lost on when this is “moved” to ESP-Home.
I can understand that it creates issues, but power consumption of an ESP, and wifi/LAN dependencies is not really something I can take serious since both of those are used quite heavily in a smart home anyway, one or two ESP’s is not going to make a difference.
In an attempt to bring this back to the original question and emphasising a few points, rather than making this purely a RPI GPIO vs ESPHome debate, I few comments:
I’ve checked the HA core repo, and there are no maintainers for Raspberry Pi GPIO – and that’s also what the ADR says.
So here are some options: Anybody that cares enough with the right skills that can become a code owner? Perhaps the core devs will then reconsider keeping it. I completely understand that they simply can’t maintain everything (and this is FOSS). Either properly support something or drop it.
There is still remote_rpi_gpio. I couldn’t see whether this will be deprecated too, but this might still be an option to use. Sure, we can debate whether the “network IO” adds “unnecessary” overhead, but if you use a loopback device (i.e. localhost), this is a fairly moot point, especially if this ends up being the only option to achieve your goals. I have played with this integration before, but had some issues so just aborted my attempts. YMMV.
Then, as already stated (or actually, implied): Someone could take the code and make a custom component / 3rd party integration of it offered via HACS. See my first point about ownership. But, as the ADR suggests, there are some hardware challenges and someone taking this on will probably deal with a variety of PIs – from a model 1 to 4 and all the variations and architectures.
Incurring some additional overhead, but this is actually what I did myself quite a long time ago and that is to run Homebridge connected to HA via a HomeKit Controller. So, I can read and write to pins remotely this way. The background for this is that I had HA running on a PI, which was also set up as a security camera. Since then, I’ve moved my installation to a server and kept the PI as a camera which also has some indicator LEDs and a BME280 temperature and humidity sensor connected to it. There are a lot of layers involved here, but it works, it’s fast and I haven’t upgraded any of the software on it in 2 years so the maintenance of this has been very low (maybe I’ll regret this one day, who knows).
And then the fiercely 
debated ESPHome: This is a very good option, in my opinion. The software and the support is excellent. I run a number of custom built ESPHome devices and where I have the time and skills, this is really my first option (costs are generally fairly low too).
This is also my main use of Rpi IO, and it’s the neatest.
Using ESPhome to achieve the same thing is messy, a very ugly solution indeed.
@Frenk, given that so many HA installs use Rpi, and that cooling is a obvious part of the overall system reliability, what is your proposed work-around for this?
