I'm unhappy with the removal of GPIO

Social
1

No more Raspberry Pi GPIO!!??

How dare you!

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.

Reading this conversation makes me angry:

" The Raspberry Pi platform is officially supported by Home Assistant and is recommended for use. GPIO is one of the main hardware features of the Raspberry Pi.

According to analytics, the Raspberry Pi GPIO integration is currently used by more than 1,100 people, which indicates that it is quite in demand.
I hope we could keep at least the basic GPIO capabilities that this integration currently provides.

frenck 6 days ago

It won’t. The decision has been made and formalized in #686.
The integration has been deprecated, as of Home Assistant Core 2022.2, and pending removal for Home Assistant Core 2022.6. "

Used by more than 1,100 people!

Are you really that alienated from the actual users??

56 Likes
2

Look here for options: Removal of GPIO support.

1 Like
3

I have the exact same question. Not sure how to control the Rpi fan board when GPIO is removed.

6 Likes
4

I agree with the concern here on GPIO. Are we saying all GPIO support is being removed? My entire alarm system, motion/door sensors, and doorbells, are hardwired into my HA Pi using GPIO’s and the Raspihats and rpi_gpio integrations. This would be crippling to my entire home’s security and I would humbly ask that this be reconsidered. Major loss of functionality here.

21 Likes
5

I get why getting rid of GPIO in the core support streamlines things, etc…

ESPhome works well, but it doesn’t support the Pi platform, and Pis can run other functions that are sometimes handy to have collocated with the IO. After all, ESPhome isn’t the only way HA deals with IO today.

So I don’t understand why using the GPIO pins on a remote Pi should be a problem. In your case, if you just bought a new Pi and moved HA to that, and left the old Pi (and it’s wiring) in place purely for GPIO (and other compute functions) should solve your problem.

2 Likes
6

GPIO support is being removed from the core integrations. Third party integrations are still free to implement this.

For your use case I would recommend moving away from integrations entirely and using this: https://github.com/flyte/mqtt-io , on a second pi if you are running HAOS. This is what I currently use (on two separate Pis) and it is rock solid.

Alternatively, you could get an Ethernet ESP board and use ESPHome with some MCP230xx I/O Expanders. This is what I plan to move to for reduced power consumption and improved reliability, as no SD card is required (though I have never yet had an issue with that).

4 Likes
7

You mean used by 0.8% of installations?

There is currently no one maintaining these integrations. The core team does not have the resources to maintain everything. They are not being dropped altogether. Just moving from the core integrations to third party.

If no one picks up the challenge and maintains a third party GPIO integration for your device you still have many (IMO much better) options. See my post here.

These options are independent of Home Assistant and utilise either the MQTT or the ESPHome API. This actually offers much greater reliability.

Yes it will require a little effort and a small amount of additional hardware but the benefits will be worth it.

7 Likes
8

Do you suppose that the people running Home Assistant on a Raspberry Pi and using the GPIO integration might among those least likely to participate in the cloud metrics?

10 Likes
9

This type of comment is honestly terrifying to me. Just yesterday I was setting up Room Assistant and noticed the MQTT Room Presence Integration is only used by 350 installations. Hope an integration I need isn’t next.

It should also be noted that these are tracked installations. Curious how many, like myself, have analytics turned off.

15 Likes
10

Why would that demographic be any less likely to participate?

1 Like
11

Not OP but I was thinking along the same lines. People using GPIO are likely less oriented to cloud services and by the same principal sharing cloud analytics

7 Likes
12

Hey @tom_l,
Kindly suggest a replacement /alternative for my gpio usage for a RPi cooler hat?

Current yaml 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"

Would this scripting work if changing the gpio from 17 to 18 in the script? If so I’m definitely losing the card control over the cooler.

Is there maybe an alternative?

Or do I need to ditch the pi hat and have an always on cooler?

PS. I’m one of those guys who don’t report analytics, not counted on when deprecating gpio control.

4 Likes
13

Regardless of your broad statement, the decision wasn’t solely on numbers used if you look at the ADR.

The major one for me if i was using is the one below, its a ticking timebomb for you.

“Most of these integrations are unmaintained”

4 Likes
14

No, I doubt there is a strong correlation.

2 Likes
15

It’s not just number of users. If there is an active maintainer of the integration it will be much less likely to be moved to third party integrations.

7 Likes
16

Well as long as you doubt…but seriously I bet there is a strong correlation. Those with GPIO aren’t as inclined to any cloud services, including analytics. It always worries me when decisions are made based on analytics as there are a larger number of people without them enabled.

3 Likes
17

There are nearly 2,000 integrations in HA. The idea that an open source project can ACTIVELY maintain all of them is beyond a pipe dream.

I’m not even using this integration, I just think it’s easy to discount the depreciation of integrations until it affects you and citing analytics is scary given how many people don’t enable them.

4 Likes
18

And that is why those that are not maintained should be removed from core and used as custom ones.

2 Likes
19

Because the type of people that would engineer their own hardware to work from GPIO are probably averse to anything involving the cloud. Most things you might want to use GPIO for can probably be done with off-the-shelf home automation projects, but one of the motivations to roll your own solution is to avoid interaction with third-party services/the cloud.

Same thing for other homebrew-adjacent integrations like Tasmota.

7 Likes
20

I use both esphome and tasmota, and upload my stats
so do 17% of esphome integration users and 8.9% of tasmota integration users, so no your statement is still not valid

But as mentioned before, Its removal wasn’t just based on numbers used, there was others, including not being maintained which is a far bigger problem if you ask me

1 Like