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
This should be able to be packaged up in a HACS integration to make it easier.
Personally, I have no problem with getting rid of local GPIO support. However, if you are using a remote Raspberry Pi as an alternative to an ESPHome supported device, I don’t understand why that use should be deprecated. For me, I have a POE connected Raspberry Pi in an outdoor enclosure that talks to a couple RTL-SDR’s for deciding ADS-B data, etc… and I can use the GPIO pins to control antenna switches etc…
Why is remote use a problem? It should be like any other remote IO platform.
Seems like there is workarounds to this problem for most use cases. Put https://github.com/flyte/mqtt-io on the same Pi and use MQTT as the middleware between the GPIO and HA. Yes, it’s not as clean if the goal is to have HA and all your hardware GPIO exist on the same Pi. It does have the benefit of making the design more lego like with MQTT being the glue that lets everything communicate.
I just finished replacing my last Pi doing nothing but GPIO. I had them scattered around the house and in outside buildings. Keeping them updated, online, and dealing with upgrades was a pain. I replaced them all with this PCB running ESP Home. Kincony 8 Channel Relay Board (KC868-A8) Configuration for Tasmota It has a bunch of relays, isolated inputs, 1 Wire bus (for temp sense). The ESPHome software also has just enough features to do a bit of low level control without involving HA.
1 Like