If you have really read the whole thread you will see rpi gpio survives via hacs.
1 Like
Yes, I really have read the thread, thanks for the friendly tone.
As you probably know HACS requires a Github account and I personally prefer a rather clean streamlined setup. It might be ok for users who love to tinker and toy with bleeding edge features. But for me personally this is less from desirable.
Every possible solution requires additional hardware and/or additional layers of software dependencies with much added complexity.
For other unfortunate GPIO users: HACS, remote GPIO, ESPHome, MQTT-IO
I understand that this is the way to go and I have to accept this way. Nevertheless my enthusiasm for this project has found a sudden end. My bad that I went all in to this platform.
4 Likes
HACS is just the easy way to install it. You can still install it manually without HACS.
3 Likes
Just follow the manual install instruction here to install the original rpi_gpio as a custom integration, no need for HACS if you dont want it
thecode/ha-rpi_gpio: Home Assistant Raspberry Pi GPIO Integration (github.com)
7 Likes
It would have been nice if at least the removal of GPIO was announced in advance. Like a depreciation warning, as is common in other breaking changes.
Edit: let me apologize, this is exactly whatâs happening, it will be removed in 4 months. Apologies for my mistake.
It has been marked as deprecated and will be removed in 2022.6
From release notyes breaking changes
As of this release, all integrations interfacing with GPIO directly, have been deprecated.
and
The following integration have been deprecated and will be removed in Home Assistant Core 2022.6:
- 1-Wire (SysBus only!)
- Raspberry Pi GPIO
so thats 4 months for people to get alternatives in place.
4 Likes
Welcome to the forums, Salog! If you are willing to stay, you will find that the vast majority of forum members adhere to netiquette and will treat you in a factual, friendly and helpful manner. 
9 Likes
It is announced in advance⌠itâs being deprecated in 4 months.
1 Like
I just want to add that the whole promise of HA is private, local home automation. By its very nature this project will attract those who are turned off by cloud based solutions and all of the privacy breaching telemetry they entail. Hopefully the devs take that into account before making decisions based on metrics.
I for one have the analytics turn off in HA, and I even go a step or two further and block telemetry from other systems at the router. I also found this to be an effective solution to Microsoftâs forced feeding of updates at the most inconvenient time. You should see my firewall logsâŚ
But hey this gpio fight isnât mine. I donât run HA on a pi, not powerful enough.
Carry on.
2 Likes
First of all, many thanks to the developer(s) who stepped forward to support rpi_gpio as a community add-on!!
A couple of points that are being missed or dismissed:
This change is hitting a nerve for many people because itâs fundamentally opposed to the stated philosophy of HA, and the reasons many of us chose this system. From the HA blog:
Durability
If there is one thing that technology firms are very good at, it is launching new products. However, maintaining the products and making sure they keep working is an afterthought for most. The result is that vendors can decide to no longer support your device, crippling itâs features or even prevent it from working at all.
As we install more and more devices in our home, durability is becoming more and more important. We shouldnât have to buy everything new every couple of years because the manufacturer decided to move on.
Durability for the Open Home means that devices are designed and built to keep working. Not just this year, but for the next decade.
I think that sums up the way most rpi_gpio users feel. Maintaining this core functionality is being treated like an afterthought.
I know some folks are trying to help by recommending alternatives. But asking users to re-configure their systems using new hardware and software isnât helpful. Personally, I love ESPHome and am looking forward to using it for more applications. But duplicating the existing GPIO pins on my existing RPi thatâs already running HA, adding dependencies on additional hardware, power supplies and WiFi infrastructure, is not a reasonable solution.
Finally, I keep reading that only 1,100 installs use the rpi_gpio platform. Iâve also read that this is not the real justification for the change. Yet it keeps being thrown back at us rpi_gpio users. So I felt it important to point out that only a fraction of HA users share statistics, so the number is actually several times higher.
9 Likes
But with the same logic the number of total installs is also several times higher.
The analytics is the best we got, unless you create a poll and make sure every user answers it.
2 Likes
There are going to be bumps in the road in all software. Things change. Thatâs the nature of life and you have to adapt.
If youâre unwilling to adapt, then whoâs fault is that?
rpi_gpio users have 4 months to prepare. They have multiple options, some free, some not, some that require new software, some that require new hardware, and some that just require you to copy and paste files. This is 100% being overblown as there are FREE simple fixes to this problem that only require 5 minutes of work⌠in 4 months time.
9 Likes
My point was that this number keeps being thrown at us rpi_gpio users to justify dismissing our concerns as insignificant. Then when we answer, weâre told thatâs not really the reason for the change anyway.
Logic would dictate that we need to either admit that the needs of thousands of users are being dismissed as unimportant, or to stop using that statistic as a supporting argument in the first place. I recommend the latter.
2 Likes
There are 2,000 integrations in HA. I donât think there is someone actively maintaining each. Nor would I expect such in an open source project, even one as well run and supported as HA. People are citing stats because it was literally the first reason listed for removing GPIO and if it was about cleaning up other unmaintained integrations many others would be going.
1 Like
It just needs to have a maintainer who fixes issues when issues are written against it. If it has a low % of users and no maintainers and the issues are flying off the wall⌠itâs probably a good indication that it will get the axe. That doesnât mean it will get the axe, itâs just a good indication that it might get the axe.
1 Like
Until a couple of hours ago, there were no options which would only require 5 minutes of work. If it comes to pass that thereâs a working, supported community add-on, then I agree that this will become just a minor bump in the road for an experienced HA user who has installed such add-ons before. And I appreciate the effort which led to that solution.
I donât think the 5-minute time frame is going to apply to everyone, though.
3 Likes
You always have the option to copy the current integration and use it as a custom integration. so⌠yes, that option existed the moment this news broke.
2 Likes
Agree with everything you said. Citing usage stats as the first reason to remove an integration is frankly scary. It punishes those who donât share which really goes against the main principle of HA. I completely understand the logic behind it but in this particular community it doesnât work given the encouragement to stay local.
That being said, GPIO is also not my fight. Also, why isnât a Pi powerful enough for you? Iâm currently running on one and curious if I can expect to reach a point it wonât be enough power for me.
1 Like
You can find out if there is.
Iâm not going to.
This is the thing.
âThe GPIOâ people keep referring to the blog post from last week about decade of service, yet on the other hand they donât expect anyone to service them.
Which one is it going to be?
Where was this the first reason?
Perhaps there is more cleanup in the pipes?
If the ânew mottoâ is to make sure integrations work then that could mean HA and Nabu casa is aiming for every integration must have a developer (?).
This is perhaps step 1 of 10.
Who knows?
But right now, this is the current situation.
Alternatives are already in place, four months in advance.
The Broadlink yaml configuration was also deleted this release.
Probably because it was âdueâ anyway but also because there is no support/maintainer (I guess).
1 Like
In that other thread which broke the news, I think I asked where the instructions for doing that were.
IIRC, there werenât any. I think I now have the right files, but Iâm still not really sure. I shudder to think what someone with less experience would have to go through. Sometimes we forget that not everyone has the same background and experience level we do.
If it were so easy, wouldnât it have made sense to document a step-by-step procedure to implement the alternative? Instead a LOT of effort has been put into challenging anyone who posts their concerns.
3 Likes