End of integrations that use GPIOs :-(

Torok42 · December 30, 2021, 10:04pm

Hello,

From April, integrations that use GPIOs will be removed
Here is the ADR: architecture/0019-GPIO.md at 780ea1b180263fce7b08805c019dd580f3db6fe2 · home-assistant/architecture · GitHub

Very bad idea which unfortunately is based on incomplete data. In ADR-0019: “All of these integrations have a low usage count (source Home Assistant Analytics)”

However, for exemple :
1-wire (231 installations)

DHT (180 installations)

There are still a lot of people who use these integrations.
If we remove the integrations because they are not used much, there will not be much left

ESPHOME is not a solution. A cable is more reliable than WIFI
Really unfortunate that the community is not consulted.

francisp · December 31, 2021, 5:40am

Most of these integrations are unmaintained.

If there are no maintainers, it makes sense to remove the integration.

Tinkerer · December 31, 2021, 8:09am

231 out of 122 thousand is irrelevant in terms of number of users.

If you feel that ESPHome and similar aren’t options then the solution, of course, is for you and others that want to keep them to step up and maintain them as custom components.

Torok42 · December 31, 2021, 10:24pm

The API for these integrations does not change and in 10 years it will still work. They are not cloud integrations.

A call to the community to find a maintainer would be better.

Torok42 · December 31, 2021, 10:31pm

So 80% of integrations are irrelevant in terms of number of users?
Why accept others?
HA must be limited to 50 integrations and especially not put on the website “Works with over 1000 devices” if more than 800 integrations are not relevant in terms of number of users and can disappear at any time

francisp · January 1, 2022, 5:58am

AFAIK GPIO integration does not work already on 64-bit Pi.

Torok42 · January 1, 2022, 2:46pm

No luck for them…

Tinkerer · January 1, 2022, 5:25pm

And nothing is stopping the community from supporting these GPIO based integrations as custom components.

Except the thing that’s caused them to be unmaintained as it is - nobody is interested in doing that.

donburch888 · January 1, 2022, 9:14pm

or maybe because no maintenance has been necessary ?

Maybe that is part of the reason that Raspberry Pi Foundation have not yet released 64-bit RasPi OS … and surely RPF need to get GPIO integration working in 64-bit RasPi OS before anyone on this end can start to test or maintain it ?

Torok42, this seems to me very much more part of a trend to position Home Assistant as a service running on a PC in a back cupboard, with all sensors connected via network.
Raspberry Pi is still a cheap way for people to start with a server, but we have to stop thinking of it for its I/O.

A separate physical RasPi may be necessary to act as a remote I/O controller device, separate from Home Assistant. I note that there is a remote_rpi_gpio integration … but I don’t think it really does this.

Bartem · January 1, 2022, 10:02pm

Also it is extremely easy to copy an existing component folder and move it to custom_components … (the last time
I did it anyway it was)

If are are really set on keeping it going I would suggest you make a GitHub repo for the “custom_component” which can literally just be a copy of the existing one… and maybe your post will catch the attention of someone with the capability and desire to keep it functioning… but in the meantime that should still function on your system even beyond it’s deprecation … (other than the aforementioned 64bit issue )