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).
With your words, I feel a bit as “called up to the board” as indeed it was my first post here, Lol
I am during the migration of my setup from ancient EasyIot to a newer framework. The reason for migration is that the driver for GPIO is different for rpi4 in comparison to previous releases so EasyIoT does not work and rpi4 has 1Gb eth interface.
For now, I’ve had Domoticz for 3 weeks and HA for 2 weeks on my table. Availability of GPIO support is the main factor of choosing a platform. If I would start my research, let’s say in December 2022, and find official info that GPIO is not supported in HA more than likely would reject Home Assistant immediately. Why? I consider RPI GPIO as the simplest design with guarantee of stability because all that may break out there is Raspberry Pi or relay. BTW, I have been using rpi2 since 2015 and so far literally NO failure (same SD card all the time!).
So, the point is: In my automations, GPIO is dedicated for critical things, ESP for others. What is critical? Gate, gateway, additional lockers, alarm areas, garage doors.
So, withdrawing the official GPIO support I consider as a big loss. When I found out info about the plans + I did not know HACS. I decided to give it try but will stop upgrades on the latest version on which GPIO works.
Well, from the other hand, huge advantage of HA is the community which is large. Community is something really important. I know what I am saying - EasyIoT as closed-source software has been kill -9 by their developers because of literally no support in the last two years. At some point, Domoticz developers may also decide to take off GPIO, then it is much better to be on HA with HACS and big community.
Thanks for all who had put alternatives solutions and workarounds with links to HACS solutions in this thread. Thanks for those who builds these alternatives.
Thanks also for everyone who contributed in such amazing project like Home Assistant is!!
I am one of the people affacted by the deprecating of the Raspberry_gpio integration as I used a GPIOs to control a relay and a 1-wire temperature sensor. I understand the considerations for the deprecation.
I am aware of alternatives like, the HACS integration, ESPHome and MQTT IO.
What about serial over USB connection to an external microcontroller with GPIOs? This seem to be an alternative to those that want to read and output to GPIOs close to the server and don’t want to depend on the (wireless or wired) network for those GPIO reads/outputs.
At the moment I don’t think there is an option to send/receive data via USB to ESPHome devices, correct? It does work with arduino devices. Sending is covered in this topic.
I use i2c for bme280 integration. It works fine on my rk3399 based nanopc t4, which is 64bit. The reasons for deprecation in the ADR are not valid in my opinion, OS differences and 64bit, the fact that bme280 worked on my sbc is proof nothing special is needed. Mayabe analytics are not picking up all installations. My log indicates that bme280 integration will be dropped in 2022.4, while it is indicated elsewhere that raspi.gpio is being dropped in 2022.6 why the difference? As for bme280 being unmaintained, a claim in the ADR, this commit was merged and accepted in december https://github.com/home-assistant/core/commit/c7eae8b0bc73dc00038053e275b941a0ee32ac94
I found a solution to bme280 if bme280 is really removed. Linux supports this sensor directly. My kernel has it compiled as a module. All that is needed is a device tree overlay:
My sensor is on bus2, the 2 at end of &i2c2 is bus number, 76 is id for bme280
Sensors will then appear in:
scott@hass:/sys/bus/iio/devices/iio:device1$ ls -l
total 0
-r--r--r-- 1 root root 4096 Feb 4 15:18 dev
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_humidityrelative_input
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_humidityrelative_oversampling_ratio
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_pressure_input
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_pressure_oversampling_ratio
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_temp_input
-rw-r--r-- 1 root root 4096 Feb 4 15:18 in_temp_oversampling_ratio
-r--r--r-- 1 root root 4096 Feb 4 15:18 name
lrwxrwxrwx 1 root root 0 Feb 4 15:18 of_node -> ../../../../../../firmware/devicetree/base/i2c@ff120000/bmp280@76
drwxr-xr-x 2 root root 0 Feb 4 15:16 power
lrwxrwxrwx 1 root root 0 Feb 4 15:18 subsystem -> ../../../../../../bus/iio
-rw-r--r-- 1 root root 4096 Feb 4 15:16 uevent
scott@hass:/sys/bus/iio/devices/iio:device1$ cat in_humidityrelative_input
74870
scott@hass:/sys/bus/iio/devices/iio:device1$ cat in_pressure_input
101.192171875
scott@hass:/sys/bus/iio/devices/iio:device1$ cat in_temp_input
17950
Then add a command line sensor to cat those and divide by 1000 where necessary. IDK if this will work on hassos, if it does it will likely be “unsupported”
This is my post just posted on the thread “2022.2: Let’s start streamlining!” I report it here because it is more specific to the topic.
I also want to give my opinion on the RPI GPIO issue, even if it has already been discussed indefinitely, because it is right that the HA community knows how we make the Home Assistant system work.
After having taken a sound anger and after having disposed of it slowly by reading the various posts I would like to have my say.
I understand the reasons for the deprecation. For those like me (and there are so many) who are not able to help with the software (age, training, time) but have dedicated themselves to developing their own PCB boards and automatisms with the most disparate chips and successfully integrating them in HA …it was a really bad surprise.
Unfortunately there is no going back but the suggestion and effort that I ask the developers and those who work on the HA software is this:
help those like me, with practical tutorials and examples, to proceed with the conversion with the various alternatives. This will make the angry ones happy and earn their HA reputation.
Sure it will be an extra effort on the part of those who work hard to keep the system up to date.
Such a radical change deserves a special approach.
Hi everyone
Hey @fraygon,
I appreciate your calmness. I know that the topic can be a bit stressful for people that were caught cold by this.
My setup is quite different. I have almost always one device for one dedicated function. that is honestly grown out of experience that things change (one could say improve for the greater good) and you don’t want to build on too many tight dependencies! The GPIO topic hits that perfectly. I personally (and that is not an attack on anyone!) would never mix the concerns of running a complex Home Assistant setup with connecting a bunch of sensors and e.g. your custom chips and PCBs. If my HA system dies today, I want to be able to still control all devices through a less convenient web page or similar.
That said, I don’t know about your specific application but I’ll just assume you have a custom PCB that serves a task and was connected via GPIO to your HA Raspberry Pi.
Imho this is really not a huge deal and a good opportunity for you to modernize your setup (you might not have the time or the nerves to do that these days, I totally get that and it would annoy me too).
Long story short: Go with an ESP8266 and either ESPHome or Tasmota, depending on your preference. Both are very easy to set up and get working after you invested one hour to understand how their general concept looks. I have dozens of both solutions in my home and am a big fan.
developers … help those like me, with practical tutorials and examples
Just a quick thought on this. ESPHome is now part of the Home Assistant family. It’s super versatile, documentation is excellent, and tutorials are out there, hundreds on youtube alone. The way I understand this the decision to deprecate GPIO support was done only after the core team evaluated that there are adequate solutions and tutorials etc out there. I wonder if that was not communicated clearly enough. In summary: Why would you need to provide documentation, if there is documentation
I share a lot of what you wrote. My system is mixed: I use ESPHOME (which I don’t like) to make some important functions autonomous but a lot on GPIO for electronic extraction and for various self-built pcbs (sprinkler, thermostatic valves, anti-theft controls). My system is constantly evolving and … I got scared!
You say there are many examples, and this is true, but they are very specific. For those who self-build the modules, these must be translated, interpreted and adapted. This is why I wanted to insist on generic tutorials.
It is true that the HA community is very present (I can confirm this directly) but for us “do it yourself” it is always difficult even to ask the questions correctly and in the right language.
It is easy to buy and pair but self-build and make it work is a little more complicated … but rewarding!
It is easy to buy and pair but self-build and make it work is a little more complicated … but rewarding!
I can 100% agree. Most of my “standard use cases” like temperature sensors, valves, switches) are off the shelf. I have also completely replaced an old central heating controller by a solution based on a ESP32, I have automated my coffee machine with an in-build ESP8266 (plus self-wrote firmware) and we have permanent weighing scales under 6 bee hives It’s just so rewarding when you have such a project robustly doing its job for years!
Sadly, I’ve noticed in the communications the trend to focus more and more on the needs of the masses. It was, I suppose, inevitable, to make it easier for the uninitiated user to jump right in, doing everything from the UI, removing more and more from YAML config with every release. They say they won’t, but they do. I welcome some of this (because I cursed YAML when I started HA) but, for example, because the UI removes comments from YAML it edits, I can’t use it. I rely heavily on comments in the code to keep things straight, plus, as a programmer, I’m comfortable that way. Who codes without comments?
… but you sure do have a lot to say about it. Who are you? No picture. No name. Are you a dev? On what in HA? I’m just curious from whom are we getting “advice.”
Why do you even care? Clearly you’re not going to step-up and maintain it.
I’ve been a HA user for 2 years, and this is news to me. Thanks for that tidbit. Although, granted, that custom integration is still a dead end, ultimately, right? And just because it’s been added to HACS, does that mean it will be maintained, or is this just a short term solution to installing it?
The maintence of the custom integration is now the resposibility of the person who forked and added to HACS, just like anyone they can just walk away and it will not be maintained. But any of the code in HA core will not be dependant on it or tested against.
Being a custom integration does not mean in any sense its dead end, there are many custom integrations that have been going for years.
Some devs use custom integration as a stepping stone to being added into the core or are happy for it to stay as one.
Can i ask in this thread, what is the reluctance to running the integrations that are marked as being deprecated as custom integrations as opposed to being in HA core.
Is it that it harder to install? HACS can simplify if its in their or you can do manually and you can carry on using them as long as you wish.
Is it that it wont be maintained, because at the moment those are not anyway and if they break you are buggered as most require specific hardware to develop or diagnose against
I’m surprised you learned about it here from me because it’s been mentioned, at the very least, in the two threads that discussed the deprecation prior to the introduction of the Release Notes and in the discussion attached to the Release Notes announcement.
The difference between an official and a custom integration is:
An official one successfully passes the development team’s vetting process and becomes incorporated into official releases of Home Assistant.
A custom one doesn’t do any of that. It’s not vetted by anyone and isn’t included in the official release.
What the two have in common is the integration’s author maintains it and typically accepts improvements from others. If the author abandons it, unless someone else takes over, it remains static and might continue to work … unless something in its environment changes and renders it non-functional.
You can copy all of an official integration’s code into the custom_components directory, restart Home Assistant and now it will use the copy of the integration instead of the original version. You are free to modify this instance of the code to suit your needs.
I did this shortly after I started using Home Assistant, back in October 2018, when the MQTT HVAC integration didn’t meet my needs and I modified it (had to learn more than just a little bit of python to do that). Eventually, the official MQTT HVAC integration got the features I wanted so I stopped using my customized version of it.
You can copy all of an official integration’s code into the custom_components directory, restart Home Assistant and now it will use the copy of the integration instead of the original version. You are free to modify this instance of the code to suit your needs.
Thanks for the clarity. A large part of success is simply knowing what is possible. This opens a world of possibilities.
Now if I could only sort out the difference between integrations, add-ons, custom-components, platforms, domains… life would be good (and before you provide a link to the architecture diagram… didn’t help ). Cheers.
). Cheers.