I could have sworn that when I looked this up a couple days ago, both the local and remote GPIO was on the same page, and this was before the pages were marked for deprecation.
Also, I didn’t see any comments in the blog post or prior thread about the remote GPIO explicitly saying it was NOT going to be deprecated. It would be nice if this was called out in the blog post so this was clear. It is written like everything GPIO was being deprecated as of now or in 6 months and no reference to remote GPIO.
so, if I have an integration currently RPI_GPIO I will need to reinstall the integration via HACS?
Also, I am yet to move my legacy Google Apps For My Domain/Workspaces account over to the new system they’re coming up with, so I cannot currently “upgrade” nest to the new Nest system. So, for now I lose access to my next devices in HA?
“GPIO, in this case, means interfacing directly with the individual GPIO pins (or I/O lines) on the board running Home Assistant. This includes bus communications like I2C and SPI.”
In practice, the above means that the below use case will be NOT covered in default Home Assistant:
It will be NOT possible to have an HA entity integrated with RPi GPIO in a way that I will be able to see the state of a GPIO (high, low state)
and/or
It will be NOT possible to have another entity like push button (switch) that I would be able to change the GPIO state triggered by tap on UI or by changing it by API?
Moving a bit forward. For “typical” HA end users, who want to use so great feature on RPI like GPIO, or who do not want to put potential points of failure that comes with other hardware like ESP (ESP with its power supply, WIFI based etc), the only hope is to count that someone skilled and kind will create and share over HACS a custom HA integration with GPIO that will give possibility to see/change state of particular GPIO pin in HA.
Is that understanding correct? Please correct me if I am wrong (I hope I am wrong).
When I moved from Rpi 3B to Blue, the gpio sensors/switches stayed on the rpi. I’m using flyte mqtt-io to connect to HA. It’s mqtt over ethernet with auto discovery.
There’s so much vitriol on both sides, it’s hard to figure out what’s really going on. Here’s what I think I’ve gleaned after an hour of reading posts here:
The developers’ heels are pretty firmly dug in on removing the rpi_gpio platform from the base of HA.
Someone has stepped forward to continue supporting it as a custom, community add-on.
You will be able to install this add-on using HCAS or manually from here.
I’m a confused user, I haven’t got HACS and don’t want to install it (however the hell you do that). I have a simple entry in my yaml that allows me to have the Pi fan go on/off with core cpu temperature.
I assume that type of installation isn’t included in the usage stats ?
I assume if I updated to 2022.2 my fan will stop working.
This is pants, I imagine many people have their Pi done this way ?
I’ve had nothing but problems with HACS, but have been able to follow the manual install instructions for other components very easily. No coding required. I’m hoping this will be the same.
Apparently we have until June before the existing rpi_gpio stops working.
This isn’t a disaster - yet. The debate really went main-stream with the release of 2022.2, when it was formally announced. There are vociferous parties on both sides. Things may change again before June, either for better or worse.
This is a very disappointing development, because it shows the direction HA may be headed. But I don’t think it’s time to panic just yet.
I use a Climate Control so I can dial in the temperature I’m aiming for (45’C) that keeps the temperature constant, this reduces stress on components I think.
When choosing a platform for Home Assistant, I settled on the Raspberry Pi 4B precisely because GPIO could be used.
And very soon, my RPi will not be able to control its own UPS, and in addition will lose the ability to control other devices connected to the GPIO. And if device management without using GPIO can be somehow organized by adding additional points of failure to the system, then I don’t know how to manage an uninterruptible power supply. It’s a pity.
I must say that the amount of new users who makes their first post with the purpose of ranting about the GPIO has taken me off guard.
Either most GPIO users has never registered in the forum or we have a few duplicate accounts.
I think those of us who spend a lot of time on this forum (or on GitHub, or Facebook, or wherever else HA is discussed) forget that not everyone does that.
Most people don’t bother to register when everything is going well. But when something that thousands of people use was deprecated, I’m not surprised we started hearing from people we don’t usually hear from.
Frankly the passions were getting high on both sides, and I suppose you could call it ranting, both by those impacted by the change and those trying to dismiss those concerns as trivial.
Now, with a well-documented solution which is within the capabilities of anyone messing with GPIO pins, I think a lot of that should be behind us. You might even say it took all those users raising their concerns (or ranting, if you prefer) to get to this point.
Either way, I appreciate the people who took the time to document their support for this functionality. Thank you!!
Some of the comments from the affected clearly fall under the definition of ranting because, instead of discussing mitigation and alternatives, they come here (some for the first time) to comment on how this is nothing short of an extinction event.
Where is the equivalent hyperbolism from the so-called other side?
Some of the affected appear to have spent more time writing nonsense than researching alternatives. They seem to have failed to see, or ignored, the commentary in the blog post concerning the deprecation and alternatives:
Additionally, there are many projects around that handle these purposes of GPIO better than Home Assistant. For example, our sister project ESPHome, or the MQTT IO project, and many more.
We do not forbid the use of GPIO, but we are merely deprecating and removing built-in integrations, providing GPIO functionality from Core. We welcome custom integrations (existing or new ones) to provide alternatives.
I think the only miscalculation is that the development team assumed anyone who tinkers with GPIO doesn’t need hand-holding instructions to implement alternatives. Apparently they do.
Fortunately, those who have no use for ranting explained how trivial it is to make the official rpi_gpio integration (any official integration) into a custom integration (a.k.a custom component) by simply copying files into the proper folder. Or use MQTT IO as mentioned in the release notes.
On one point that I do agree with the affected is that ESPhome is not an equivalent substitute for an RPi’s GPIO pins.
I don’t know anything about the PoE hat and how that works.
But it will work now with the latest version.
In June it will stop working if the PoE hat needs the GPIO (which I don’t know).
