Anyone using rpi_gpio? What will you do when it's gone?

So now that the rpi_gpio platform is marked for removal in 2022.6*, what alternatives are others looking at?

Or am I the only one left still using it?

I have five relays (contactors) which close when components in my heating system (zone valves, boiler) come on. These are connected to the GPIO pins on the RPi to allow me to track the status of this system. I’ll need some alternative way to gather this data once rpi_gpio is gone. I’m open to suggestions.

*UPDATE: The original question is now obsolete, since a developer has picked up support for rpi_gpio as a custom component You will be able to install this add-on using HCAS or manually from here.

By all means, feel free to post other suggestions, just don’t assume it’s totally going away.

2 Likes

Run it all using ESPHome?

2 Likes

I was hoping there were other options besides ESPHome, which was my first thought. That’s looks like a very handy piece of hardware, but it’s sort of the opposite of what I need.

I’m doing monitoring, not control. The relays are already in place, powered by the zone controller (24VAC) and boiler burner (120VAC). The contacts on those relays connect to GPIO pins on the RPi to detect when each devices is on (contacts closed) or off (contacts open.)

It seems inserting an ESP8266 or ESP32 in between is just adding more points of failure; the ESP hardware and software, the power supply and the WiFi network. There’s also the physical wiring, and the effort to build it all. There’s maintenance when ESPHome is updated (with possible future breaking changes) and more devices to fail. Not to mention the inelegance of sending the open/closed signals to HA over WiFi, when the relays are sitting right there next to the RPi.

Monitoring my heating system is critical in my environment. Frozen and burst pipes can get very expensive and make the house uninhabitable. If I had an ESP-based monitoring system, I’d have to question the need to insert HA into the mix. It seems so much more efficient to just use HA to monitor the GPIO pins, along with its other, admittedly less important functions. And it seems crazy to suggest that an ESP can be used to monitor GPIO pins, but a RPi cannot.

1 Like

Ah - I misunderstood.

I have dozens of ESP devices all over the house - and although I do have a (cheap) mesh network I find them very reliable.

I doubt there will ever be a breaking change is ESPHome that will break GPIO Binary sensors - the whole point of ESPHome is hardware interfacing.

I agree that removing GPIO support for the rPi is an annoying move - I think the reasons are a bit thin and the real reason is that the devs want the platform to be more hardware agnostic and less “hobbyist”.

What are you doing with the system? If it’s monitoring only with alarms you could possibly do it all on an ESP.

ESPHome is pretty powerful without HA. I have a proofing room completely controlled by ESPHome. The main ESP controls the control panel, display and sensors, while opto-coupler connected ancillary devices control the environment. It can connect to HA but can run standalone with full functionality.

ESPHome supports issuing HTTP requests - depending on what platform you use for notification you could interface that way.

Anyhow good luck with it. The ESPHome community is pretty knowledgeable and helpful if you decide to go that way.

1 Like

Thanks for the encouraging words about ESPHome. It’s looking like I’m on my own with this one. I can’t complain that abandoning this fundamental hardware capability is a stupid idea, if I’m the only one using it. I hardly expect the devs to cater just to me! So I’m trying to remain positive, even though I just finally (after two years!) got my HVAC monitoring system working exactly the way I wanted.

I’m impressed with the capabilities of ESPHome. I may have skipped using HA altogether if I’d known about ESPHome first. I’ve currently got an ESP8266 monitoring some temperature probes for another project, and to be honest it was far easier to set up than I’d imagined. It’s also proving to be very reliable. And as you say, it’s unlikely the ESPHome devs will abandon any hardware capability.

The more I think about it, de-coupling my heating system monitoring from HA gives me the flexibility to try other smart home systems in the future. So I suppose in the end it’s a good thing. At least HA gave me over five months advance notice.

As someone mentioned already in another thread there is a project called MQTT IO. I have not tried it yet by myself but it looks really promising. It is very likely that I will switch to it. Running HA on a Raspberry Pi and then not being able to use all it’s IO and replacing it with additional hardware does not sound reasonable to me.

2 Likes

You can do that with ESP-Home also.
But the pins on a ESP is 3.3 volts, so you may need to add a voltage divider or level shifter to make the signals from the relays ESP safe

Thank you. My understanding was that the RPi GPIO pins also operate on 3.3V. I’d be using the exact same circuit if I had to switch to an ESP. The relay contacts are just like a switch. They shouldn’t care about the voltage on the circuit they’re opening or closing. Or am I totally misunderstanding the issue?

I saw that on the other thread too, thank you. I think MQTT would be a good option for several use cases. Like if there were serial I/O or output (control) functions being used. I just use binary input, and I don’t already use MQTT, so for me that would be a last resort; one more thing to install and maintain.

I could see how moving to MQTT would help with platform independence however. This would allow easier migration away from HA in the future. I never thought I’d have to consider that, but now I’m left wondering.

That’s what I have done in my home. Everything is based on MQTT, that’s my main home automation data backbone. All my devices communicate over MQTT. My zwave mesh does, my DIY devices do, my RfxTrx433 does, my Hikvision smart events do - everything. And HA is just one of these devices. Everything is independent and interchangeable, nothing depends on each other on a platform level. Want to replace a zwave sensor by a DIY one ? No problem, just clone its MQTT topics. HA won’t even notice the change of platform. For HA, it’s the same sensor and entity, the hardware is completely abstracted away.

I like the total platform independence and freedom this setup gives me, even freedom from HA. I do not want to lock myself into a specific ecosystem and become entire dependent on it. And that includes HA. Because let’s face it, HA has become it’s own little locked-in system in a way. The devs change things, often without consulting their users, things that can irreversibly break your setup. And you’re supposed to just adapt to it. Sure it’s open source. But are you going to fork HA and maintain your own changes for its entire lifetime ? I did that myself before going all in on MQTT and it was pretty much unmanageable.

It also has the nice side effect of being almost unaffected by breaking changes when HA updates. Because the only platform integration I use is the MQTT one. And that one rarely breaks.

MQTT is awesome :smiley:

Edit: Of course this has downsides too. It’s not ‘easy’, whatever that is supposed to mean. You have to plan it out carefully, assign MQTT topics in a well defined way and keep records of all that when you want to do changes to it. It’s not a click’n’play setup by far. It’s a different approach for a different type of user.

2 Likes

Since I don’t know how it’s connected then I can’t say yes or no. But since it works then I would believe it will work with an ESP also.

Use the binary sensor component to see the relay status:

1 Like

I’ve come from 20 years of using Homeseer and having reliable ethernet hardwired IO for critical controls like heating, security, and pumps etc. I’ve moved several things to ESPHome on WiFi, which have been fine so far. I still want some devices wired though.

One of these has just arrived from Ali
http://www.wireless-tag.com/portfolio/wt32-eth01/

Datasheet here

Which is now connected into HA and I’ll test over the next few weeks. I’m hoping it will solve the problem and give me reliable wired connectivty. I need to add IO expanders to it, and also 4-20mA current loop sensors, all via i2c.

I’ve also got a LILYGO® TTGO T-Internet-POE ESP32-WROOM arriving soon which will hopefully give me the same capability with POE.

Use Node Red and Mqtt to home assistant

I’m trying Pyscripter from the HACS repositories. It’s actually a complete Python environment that lets you import modules like RPi.GPIO. It is quite simple to setup and use.

I can now manipulate the GPIO pins reading and writing. Unfortunately I can’t get the PWM module to work. It seems to work and generates no errors, but there is no output.

I will try to use pigpio in this environment next.

1 Like

I tried and can confirm that Pigpio works well within the Pyscript environment.
If you’re interested, I put the details here: https://github.com/paulvee/Home-Assistant

I am using it to detect when power in the house goes down. A relay turns off when power goes down and I sense it with a GPIO pin. I then use it to send myself push notifications that power is down and also us it to notify me when power returns. My rpi is powered from a UPS so I also have an automation that will do a proper shutdown if power is out too long.

I really hate to see this integration go away. Let me know if anyone has a replacement idea.

Thanks,

If you have any WiFi connected devices in your home that are connected to HA, write an automation that sends you the same message if the item in question changes state to “unavailable” for 2 mins. I have a reboot automation that does exactly this. Change the action at the end to use your existing message.

# RESTART NO SWITCHES #
- alias: Restart No Switches
  initial_state: true
  trigger:
    platform: state
    entity_id:
      - switch.brilliant_6
      - switch.brilliant_7
      - switch.brilliant_8
      - switch.arlec_2
      - switch.arlec_4
      - switch.arlec_5
    to: "unavailable"
    for:
      minutes: 2
  condition:
    condition: template
    value_template: '{{ states.sensor.uptime.state > "0.02" }}'
  action:
    service: homeassistant.restart

I like your idea! I never thought about using unavailable as a trigger. Thanks!

It’s not going away. A lot has transpired since the OP. You will be able to install rpi_gpio as a custom component using HCAS or manually from here.

2 Likes

Thanks, glad to see it will still be available. I appreciate your update.

Hello, i’m posting here because I just dont know where the right place is to post my request below.

Before GPIO was deprecated in Home Assistant 2022.6 and above, I used a BH1750 light sensor module connect to my RPi2b GPIO pins. In my configuration.yaml I had the following code:

sensor:    
  - platform: bh1750
    name: boiler
    i2c_address: 0x23
    operation_mode: continuous_low_res_mode
    sensitivity: 254
    measurement_delay_ms: 400
    scan_interval: 30

and that allowed me to get the light level into Home Assistant as a value and chart it (it used it to tell me when the ‘ON’ LED was illuminated on my Central Heating boiler).

However, now that GPIO is deprecated, I dont know how to get the BH1750 light sensor value into Home Assistant. I naively thought all I would need to do is add the new ‘rpi_gpio’ custom integration, but obviously it doesnt support ‘platform bh1750’. Looking at the ‘rpi_gpio’ instructions, i am thinking that it only supports binary sensors, so not what I need for my bh1750 light sensor reading.

I also wondered about ESPHome, but think I now realise that this add-on requires some kind of ESP32 board, which I dont have (my BH1750 is wired direct to the RPi2b GPIO pins).

Can anyone provide any guidance? Will I have to revert to an old Home Assistant image? (if so, then i’ll join the community of users angry at the dumping of a core feature of RaspberryPi & HomeAssistant)