I would just like to point out 2 things:
1 Posts here seem to indicate that people can just use an esp instead of an RPi, or as an alternantive, not so. For most using this the RPi is doing other things as well, like maybe running HA, or for me a DHCP server and node-red. The ESP devices cannot do those things effectively, so they must be used in addition to the RPi as purely an interface.
2 This is a waste of time, as it is not going to change; and from my reading of the ADR all the integrations that use GPIO, including RPi Remote GPIO, anything using I2s, 1-wire, SPI are going. Best to use this time to plan and implement a path forward, and ask for help moving on if needed.
But this is my answer to your question ! Iâm a little puzzled to be honest, there seem to be a fundamental misunderstanding somewhere. Let me rephrase: The Pi GPIO can perform this task without requiring more hardware (and all the implications that derive from this). ESPHome canât, since it doesnât support the Pi GPIO as a platform. My assessment would probably be different if you would propose ESPHome running natively on the Pi accessing its native GPIO.
Maybe itâs because in my day to day job I work a lot on high availability production systems. We spend a lot of time on making sure our software just works. And a basic mantra of this is the good old KISS acronym - Keep It Simple Stupid 
Are you familiar with the concept of technical debt ? Basically every workaround you take, every new platform you introduce as a quick fix to a more fundamental problem, will increase your âdebtâ over time. It will make it more brittle and prone to break, itâs harder and harder to maintain and keep stable on the long term. Adding an entirely new ecosystem, both software and hardware to duplicate existing basic functionality is pretty much the ultimate sin in that concept. While you may not treat your HA system like this, you must understand that some people (including myself) do treat our HA systems as production systems where the most important points are reliability and low maintenance.
2 Likes
Agreed, the majority or about 800 (~80%) of integrations have less that 1000 analytics users but all of them could be providing a valuable service for someone.
1 Like
Just to give an example from another system, this development was a surprise to me but I had had some prior discussion which was indicating a move to greater use and integration with ESPhome for sensor monitoring. My own system design has a Rpi at a central location with the home network patch panel that provides ethernet, 1-wire and serial data conections around the house. It was attractive for me to develop with a single RPi doing all the monitoring and control. It is very capable and has been very reliable and I have been moving in the opposite direction to what is signaled here by integrating as much as possible with the HA core. For me 1-wire temperature sensors are probably the most important for solar thermal HW system monitoring and some control. I also have BME280 and radiation sensors on I2C so currently use those core integrations as well as relay control.
Having read this thread, I can sort of see the developer rationale for removing the integrations from the HA core. In the shorter term, I am likely to keep the same wiring and without the core integrations, rather than a separate ESP solution with its additional hardware, Iâll either use custom integrations or even revert to some external processes that read GPIO sensors on the Pi. These all worked very relaibly as command line sensors, the configuration just becomes a bit more customised.
1 Like
@HeyImAlex, I stand with you on your last post. Full agreement with your thinking.
@ALL, I advocated in my post for a path forward that does not compromise existing capability. This path should not exclude the realities of âtechnical debtâ for reasons @HeyImAlex, others and myself have already put forward.
The devs have their reasons and our just grumbling wonât help. Making a case for need does. If nothing else it helps all focus on the actual required capabilities. From there we can find a path that will work for (hopefully all) which will survive the long haul.
As said previously, I am not capable enough to avoid, nor do I have the time to waste finding dead ends. To the extent that I can help to achieve a common goal that can reasonably be expected to work, I will. At the start, my part will be âworks for me or help! Here are my logs, etc.â To begin, I need leadership / guidance from the more knowledgeable. A consensus from the more capable among us would be very helpful.
Having said that, can we move this threadâs focus (or start another) toward a good solution that maintains the existing hardware as-is for those that need to and/or are using it please? As it is, we seem to be milling about, making noise but not progress. The need is proven. Can we shift the focus to solutions now?
The question:
What is the path forward that prevents amputation of system capability for which a case has been made and there is a real and justifiable need.
To wit:
I need:
GPIO
I2c
possibly SPI
All via the RPI header.
I must maintain access to:
Genie
Notifier
NodeRed
InsteonMQTT
ESPHome
Mosquitto broker
UniFi
probably some others.
I must not end up with an âunsupportedâ dead ended, or high maintenance core OS/HomeAssistant config. Personally, I just purchased a PI-8G for my core I will get another ASAP for other things and to serve as a spare. I do not want to switch platforms again soon and it would not solve this problem anyway.
What path (if any) meets these requirements? For me, violating these requirements would ultimately mean abandoning HA.
Respectfully,
Q
System Health
version: core-2021.12.8
installation_type: Home Assistant Supervised
dev: false
hassio: true
docker: true
user: root
virtualenv: false
python_version: 3.9.7
os_name: Linux
os_version: 5.10.0-10-arm64
arch: aarch64
timezone: America/New_York
GitHub API: ok
Github API Calls Remaining: 5000
Installed Version: 1.11.3
Stage: startup
Available Repositories: 824
Installed Repositories: 5
logged_in: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok
host_os: Debian GNU/Linux 11 (bullseye)
update_channel: stable
supervisor_version: supervisor-2021.12.2
docker_version: 20.10.12
disk_total: 117.2 GB
disk_used: 18.3 GB
healthy: true
supported: true
supervisor_api: ok
version_api: ok
installed_addons: File editor (5.3.3), Samba share (9.5.1), Portainer (1.4.0), Mosquitto broker (6.0.1), SSH & Web Terminal (10.0.0), Grafana (7.4.0), Glances (0.14.0), Check Home Assistant configuration (3.9.0), InfluxDB (4.3.0), Node-RED (10.3.1), Pi-hole (4.0.0), motionEye (0.16.0), Insteon MQTT (0.6.8), ESPHome (2021.12.3), MaryTTS (1.4.0), PicoTTS (1.4.0), Almond (2.0.1), Notifier (1.0.1), Genie - Edge (edge-3d0c903), UniFi Network Application (1.1.3)
dashboards: 2
resources: 3
views: 6
mode: storage
1 Like
Thank you, I agree this should be the focus. Apparently, thousands of people are using this function, and replacing it with a more complex solution like additional hardware running ESP has significant drawbacks.
One of the things I learned from a career in IT is that you should never dismiss a userâs need by saying something like âWhy would you want to do that??â The users of this functionality have presented a very well-justified need to use RPi GPIO pins. To keep telling us we donât need it isnât helpful.
Those who do have an interest in this functionality should focus on solutions. Iâd politely ask those who do not to focus their energies on things that they need. I promise I wonât jump in and challenge them about their need for a function I donât use.
3 Likes
Iâve given you solutions, but you seem to have decided to ignore those and keep going on about you not wanting to use ESPHome (which is only one option). For GPIO on a PI, there is the remote GPIO integration. I read the ADR again, because I wasnât sure what would happen to this integration in this case, but the ADR clearly states itâs about direct access. The remote PI GPIO integration speaks with the the pigpiod daemon over the network, so it shifts the responsibility of the communication to GPIO pins to the daemon and the remote host. As long as you get that working, youâll be fine. Bonus: The configuration on the HA side of the two integrations are almost the same.
One solution is to copy the integration directory and copy it to the custom_component directory
1 Like
I already use everything on ESP and I have no problem.
The only thing is a stackable board on the Rpi with a fan that I control via GPIO. What are your fan control solutions?
3 Likes
@Torok42, thank you. That seems like a viable option, at least to buy some time until the next RPi hardware.
Is it documented somewhere how to find and copy the right integration directory files?
@CaptTom You must copy the directory of the component you want to use
And put it in the custom_component directory.
At startup, HA will first take components from the custom_component directory.
1 Like
@Torok42, thank you!
Looks like Iâm too late, however. The files there have already been updated to reflect the deprecated status.
I seem to recall thereâs a way to get the previous version, but I canât recall how.
Disregard, I figured it out. Iâm leaving this in case others have the same problem. Select the rpi_gpio directory, then History, then on an earlier entry click the file-with-arrows icon for âView at this point in history.â
@CaptTom Itâs just an indication in the logs
For older versions, you have to go to the releases and download the source code then go to âhomeassistant/componentsâ
1 Like
Thatâs the one, thanks!!
1 Like
What about Raspberry Pi UART on GPIO ? Iâm asking for people like me who have a ZigBee coordinator connected to the RPi UART on GPIO pins 8, 10.
Will that survive the removal?
Iâm very disappointed with this. Donât you have the feeling that HA evolves backwards?
The last⌠10 updates donât have nothing really interesting. The last interesting thing is the Energy panel, but the rest⌠Summary is âmenu supervisor is moved to other place, x button is moved to this placeâ
We donât want a Super Media Player (We have VLC, Kodi). We want a domotic system, and the gpios are wonderful to connect relays, ds18b20 that guarantee reliability because they donât need any wireless connection to work. But they will be past in the following months. Why? Whatâs the problem with they? They just work. Let it be. They donât hurt anybody
4 Likes
This is my need as well. GPIO and the i2c bus are used for fan control on my pi4 device.
3 Likes
Does the removal of GPIO support mean the GPIO pins on the J11 header for Home Assistant Yellow will no longer work?
1 Like
This is copied from HA blog post:
"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."
Removing gpio is exactly that, crippling our devices.
8 Likes
Yes I agree. On the one hand, Rpi hardware is recommended. On the other hand, GPIO will be removed and in my case the cooling of this recommended hardware will stop working. That makes no sense. If it is a sensor, I am able to move it to esp, but not the stackable cooling plate Rpi. I am not a programmer just an ordinary user, so what will be the basic solution?
2 Likes