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.
Also interested in this.
have already found a suggestion (involves some soldering, getting rid of the hat I’ve been happy with for about 2 years RN). Will most definitely test over the weekend. Might even work with the hat I already have.
My yaml code curently is:
# Raspberry Pi Cooling Fan
sensor:
- platform: command_line
name: CPU Temperature
command: "cat /sys/class/thermal/thermal_zone0/temp"
unit_of_measurement: "°C"
value_template: '{{ value | multiply(0.001) | round(1) }}'
scan_interval: 10
switch:
- platform: rpi_gpio
ports:
18: RPI Cooling Fan
climate:
- platform: generic_thermostat
name: RPI Cooling Fan Controller
heater: switch.rpi_cooling_fan
target_sensor: sensor.cpu_temperature
min_temp: 40
max_temp: 80
ac_mode: true
target_temp: 50
cold_tolerance: 0.1
hot_tolerance: 0.1
min_cycle_duration:
seconds: 120
keep_alive:
minutes: 3
initial_hvac_mode: "cool"
The way I’m getting the code (not a programmer myself) it’s not getting any sensor value from the gpio’s, but only acting as a switch on gpio 18.
Adjusting the code in the link above should work even with the cooling hat, right?
I’m using HaOS on Rpi4 and I’m not sure if it will install as described. I have no idea how.
I’ll keep looking for something for the original fan board.
I don’t want to remake the original Suptronic X735 record deployed on Rpi.
I have the same configuration, I use GPIO 13 on my board as a switch to control the fan
Where did you see this? That’s why the alternative is to use the Remote GPIO integration when it comes to the main issue of this topic. You’ll see there’s no depreciation notice. It works differently and that’s why it’s not being deprecated. The ADR is about local GPIO control and supporting the libraries to do that. The remote one works by offsetting this problem that the devs don’t want to maintain: it speaks with a daemon and not the hardware directly. Thus, just get pigpiod running wherever (remotely, or even locally) and it will work.
To recap (also said before):
The remote GPIO integration isn’t being deprecated.
It’s an alternative for those seeking local control.
I could have sworn that when I looked this up a couple days ago, both the local and remote GPIO was on the same page, and this was before the pages were marked for deprecation.
Also, I didn’t see any comments in the blog post or prior thread about the remote GPIO explicitly saying it was NOT going to be deprecated. It would be nice if this was called out in the blog post so this was clear. It is written like everything GPIO was being deprecated as of now or in 6 months and no reference to remote GPIO.
so, if I have an integration currently RPI_GPIO I will need to reinstall the integration via HACS?
Also, I am yet to move my legacy Google Apps For My Domain/Workspaces account over to the new system they’re coming up with, so I cannot currently “upgrade” nest to the new Nest system. So, for now I lose access to my next devices in HA?
“GPIO, in this case, means interfacing directly with the individual GPIO pins (or I/O lines) on the board running Home Assistant. This includes bus communications like I2C and SPI.”
In practice, the above means that the below use case will be NOT covered in default Home Assistant:
It will be NOT possible to have an HA entity integrated with RPi GPIO in a way that I will be able to see the state of a GPIO (high, low state)
and/or
It will be NOT possible to have another entity like push button (switch) that I would be able to change the GPIO state triggered by tap on UI or by changing it by API?
Moving a bit forward. For “typical” HA end users, who want to use so great feature on RPI like GPIO, or who do not want to put potential points of failure that comes with other hardware like ESP (ESP with its power supply, WIFI based etc), the only hope is to count that someone skilled and kind will create and share over HACS a custom HA integration with GPIO that will give possibility to see/change state of particular GPIO pin in HA.
Is that understanding correct? Please correct me if I am wrong (I hope I am wrong).
When I moved from Rpi 3B to Blue, the gpio sensors/switches stayed on the rpi. I’m using flyte mqtt-io to connect to HA. It’s mqtt over ethernet with auto discovery.
There’s so much vitriol on both sides, it’s hard to figure out what’s really going on. Here’s what I think I’ve gleaned after an hour of reading posts here:
The developers’ heels are pretty firmly dug in on removing the rpi_gpio platform from the base of HA.
Someone has stepped forward to continue supporting it as a custom, community add-on.
You will be able to install this add-on using HCAS or manually from here.
I’m a confused user, I haven’t got HACS and don’t want to install it (however the hell you do that). I have a simple entry in my yaml that allows me to have the Pi fan go on/off with core cpu temperature.
I assume that type of installation isn’t included in the usage stats ?
I assume if I updated to 2022.2 my fan will stop working.
This is pants, I imagine many people have their Pi done this way ?
I’ve had nothing but problems with HACS, but have been able to follow the manual install instructions for other components very easily. No coding required. I’m hoping this will be the same.
Apparently we have until June before the existing rpi_gpio stops working.
This isn’t a disaster - yet. The debate really went main-stream with the release of 2022.2, when it was formally announced. There are vociferous parties on both sides. Things may change again before June, either for better or worse.
This is a very disappointing development, because it shows the direction HA may be headed. But I don’t think it’s time to panic just yet.
I use a Climate Control so I can dial in the temperature I’m aiming for (45’C) that keeps the temperature constant, this reduces stress on components I think.
When choosing a platform for Home Assistant, I settled on the Raspberry Pi 4B precisely because GPIO could be used.
And very soon, my RPi will not be able to control its own UPS, and in addition will lose the ability to control other devices connected to the GPIO. And if device management without using GPIO can be somehow organized by adding additional points of failure to the system, then I don’t know how to manage an uninterruptible power supply. It’s a pity.
I must say that the amount of new users who makes their first post with the purpose of ranting about the GPIO has taken me off guard.
Either most GPIO users has never registered in the forum or we have a few duplicate accounts.
