Pi 4 and Gpio Issues

Hardware
5

Welp just figured it out,

GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely for board detection / identification. The only allowed connections to the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect anything else to these pins!

So connecting these pins to ground is a bad idea :joy:

HA setting them to “pull up” should address the floating problem. It won’t help if you connect a switch to ground and that GPIO enables in OUTPUT mode at boot up though. This is what the resistors are to protect against.

That makes sense, but by default HA sets them all to Pull UP so not sure why GPIO14 is floating…

Now the next question is how do I make other GPIO pins work. Even though they show up in the hardware view if I declare in HA config, they don’t actually work. Anyone else has this issue?

6

Alrighty, got it all figured out. Here is the scoop. For some reason HA doesn’t set the GPIO to pull up properly even if you state it in the config. This is why my sensors appeared to not be working, since they were in pull down mode. To get around this I had to manually set my GPIO pins to pullup on Pi4 boot up.

Here is how, (in Raspbian). First install raspi-gpio to manage pins

sudo apt install raspi-gpio

Then you can print out all your pins and you can see their actual state: sudo raspi-gpio get

Then it’s really simple to set the pin to pull UP mode. If you want pin 13 to UP mode (on) Just type:

raspi-gpio set 13 pu

You can type
sudo raspi-gpio get

to see if it updated

Apply at startup
To have it get applied at startup, you have to edit your PI’s boot up script:

sudo nano /etc/rc.local

before the exit 0 line at the bottom add the pins you want to be turned on (UP):
For example, I needed these pins for my sensors.

raspi-gpio set 13 pu
raspi-gpio set 18 pu
raspi-gpio set 23 pu
raspi-gpio set 24 pu
raspi-gpio set 25 pu

This will set those pins to pull UP mode on startup.

4 Likes
7

Thanks for posting!! I’ve been tearing my hair out on this one. I’ve been unable to get the GPIO pins on my RPi 3B+ to work reliably.

I thought I was using the internal pull-up resistors by not specifying pull_mode (taking the default.) The GPIO pins are connected to the contacts of some relays which my heating system drives. Electrically, these are just like a switch. Should be dead simple. Open or closed.

I’ve read a lot on this, and apparently I’m not the only one struggling with HA and GPIO inputs. There are all kinds of theories. Yours seems the closest to what I’m seeing.

I’m running HASS.IO. I’m not sure your solution is going to work for me. I certainly don’t have any experience installing or using things like raspi-gpio, so…

What if I just added a pull-up resistor to each GPIO connection? Any harm in trying? Like, if they come up in pull-down mode, instead of floating, will my external pull-up hurt anything? I’m thinking somewhere in the neighborhood of 10-50 Ohm resistors. Any recommendation?

Thanks again!

8

You should be fine adding your own resistor. Haven’t tried it myself though.

1 Like
9

Thanks, I tried that. I also tried moving everything closer to the RPi to eliminate interference, and using Cat6 shielded twisted pair even for the short run to the GPIO pins.

Everything works - sometimes. From what I’ve read, the problem isn’t interference. The GPIO component in HA doesn’t poll the state of the pins, it depends on edge detection. Apparently, that’s not very reliable for whatever reason. If it doesn’t detect the instant an on/off or off/on change happens, HA will never see the new state.

There’s a known problem that’s been out there for a couple of years now:

There doesn’t seem to be much progress on the fix. My whole project is on hold for now, or maybe I’ll just give up and find another way to monitor my heating system.

It’s very disappointing that a core hardware function of the RPi isn’t supported by HA.

10

If you install the official Raspbian Buster Light and Hassio on top of it, you can easily enable those resistors into pull up mode on boot. It’s really easy to install Raspbian Light + Hassio. It runs just as fast and you will have more features available from main OS. You can follow my step by guide on how to do it here: Rpi 4 installation and skip the external hd stuff.

The main difference during initial installation instead of just putting HassOS on sd and booting into everything ready for you, you have to first install Raspbian Light then install HassIO on top. Then to enable gpios you ssh into Raspbian Light and run those 2 commands. You have to do it once and your Home Assistant will work the same.

1 Like
11

Thanks Alex. I think if I started over, that’s the route I’d go.

It turns out the problem isn’t with the pull-up resistors, anyway. Even hard-wiring an external resistor didn’t help. The problem is, simply, HA can’t read GPIO input reliably. It seems nobody with the skill set to fix it is spending any time on it. That’s just the way volunteer, open-source development works.

But I do think I may have found a workaround. It turns out real-time GPIO status information is recorded in the file system. So a command line sensor can read the status at a set interval. With this project, we don’t need to know the exact moment the GPIO status changes, like you would with a doorbell. Every few seconds is enough; it’ll average out in the end.

I plan to write all this up at some point, but meanwhile, here’s what I put in my configuration.yaml today which so far (just a few heat on/off cycles) seems to be working great:

binary_sensor:
  - platform: command_line
    name: zone_1st
    command: "cat /sys/class/gpio/gpio17/value"
    payload_off: "1"
    payload_on: "0"
    scan_interval: 30
1 Like
12

Haven’t tried your solution, but it looks like it will be floating so it will work sometimes and sometimes it won’t. The main issue is that HassIO which is a supervisor container that runs on top of guest os (HassOS or Raspbian) doesn’t pass Home Assistant’s pull up / pull down settings from config .

This used to work before and only started happening for me once I switched to PI4. I know it’s not HA or the main OS since I tried it with both HassOS and Raspbian. There is a bug issue of this and it’s logged here: https://github.com/home-assistant/hassio/issues/1331

My solution was to enable the extra Gpios manually through guest OS (in my case Raspbian Light) thus bypassing Hassio.

If you type raspi-gpio get you can see which GPIOs are set to UP and which are set to floating. All the GPIO’s that were not working were set to float.

These Gpio’s are already set to pull UP by default and you can use them without messing with anything:

gpio15
gpio14
gpio8
gpio7
gpio6
gpio5
gpio4
gpio3
gpio2
gpio1
gpio0

For my use case, I needed way more so that’s why I had to manually switch on additional ones.

1 Like
13

Hi, I used the cat / sys / class / gpio / gpio6 / value command to slightly read the status of some GPIOs on Rpi3 b + cpn HASSIO and I never had any problems, now I have switched to Rpi4 and I receive the following message: Command failed: cat / sys / class / gpio / gpio6 / value, can you help me?

- platform: command_line
  name: Cancelletto
  command: "cat /sys/class/gpio/gpio6/value"
  value_template: '{{ value }}'
  scan_interval: 1
  command_timeout: 1
1 Like
14

I’d be tempted to open a bug report on github for this, others may be experiencing the same thing as you, or may already have a workaround or solution.

FWIW, I’m able to use NodeRED to read the status of GPIO pins without issue on the Pi 4, so I can use the websocket node to feed the values into HA if I want.

This is a pretty bad workaround but may work for you if you have NodeRED installed.

1 Like
15

It was already reported, over two years ago now. See the link in my earlier post, above. Apparently not many people use or care about this functionality. It’s a bit frustrating, since to me the ability to use the external sensing hardware (GPIO pins) would be a fundamental requirement of any home monitoring/automation system.

There are a number of workarounds. Thank you for adding yours. Maybe it’ll help someone with a similar configuration.

16

I’m still on a Pi 3 B+, but I’m always looking ahead. This would be a show-stopper for me if it didn’t work.

Have you checked to verify that the /sys/class/gpio/gpio6/value file exists? Have you tried the same command from a console or Putty session?

I did notice that this doesn’t work unless you include the rpi_gpio platform in configuration.yaml and identify the ports you want to use. That’s apparently what creates the files the command_line platform is reading.

Unless it works differently on the Pi 4.

17

Any reason you are not using the built in Gpio platform? That’s what I am using om Pi4 and it reads it without issues

18

ok perfect, everything works I had accidentally deleted platform_gpio on binary_sensor

thank you very much

19

Not sure who you’re asking. For me, no amount of tinkering with internal or external resistors, or eliminating potential sources of noise in the wiring, made any difference.

It turns out that HA on Hass.io simply doesn’t always succeed in edge detection when one of the GPIO pins changes from high to low, or vice-versa. It’s explained in the bug I linked to a few posts up. However, setting up the rpi_gpio platform does reliably populate specific text files with a zero or one, indicating whether the pin is “off” or “on.”

Using the command_line platform to poll the contents of these files regularly (I set it for every 15 seconds) turns out to be rock-solid reliable, at least for me. Yeah, it’s a kludgy work-around, but it’s all done natively in HA. Maybe some day that bug will get a little love and we can go back to using the rpi_gpio platform as intended.

20

I perfectly confirm what CaptTom says, even for me it is the only way to make GPIOs work well

21

@CaptTom. Thank you for posting about your discovery that the rpi_gpio problem is likely not related to the pull-up. Or, it may be actually caused by more than one problem…
I did a few experiments and it turns out that the problem is likely related to debouncing. I have a button connected between GPIO3 and a ground. So, to work I need GPIO3 to be pulled-up. Once I press the button, the state sticks to “ON”. To make it OFF, I need to touch GPIO3 by hands and it may switch to “OFF” This is usually a sign that the GPIO is floating…
On the other hand, I added bouncetime: 5 (default is 50) and now the button works most of the time. I.e. it reliably turns ON and with 95% probability turns OFF when the button is released.
I do not know if the pull-up is an issue or not, but it seems obvious that the rpi_gpio code has problems with debouncing.

1 Like
22

I’m nood but I did the same 1 year ago… and still now my config is with bouncetime: 5 I have 95% probability it works, but not too reliable (100%). And I don’t know but in the last year, I burned 3 different raspberry gpio. =(

23

Ciao anche io sto tentando di collegare il mio inverter ibrido a home Assistant, ti posso chiedere delle dritte per riuscire a collegarlo?

24

Hi, could you please post your question in English? Thank you.