I’ve been running Pi3 with about 10 Reed sensors that were connected straight to Gpio pins without any issues. When I recently migrated to Pi4 I noticed that only some pins are actually turned on:
I came to this conclusion after enabling all of the Gpio pins in the HA config file. With nothing hooked up to them only the ones above showed up as “on” (if they are active they should show up as on/active). When you go to Dev tools -> system > hardware info it actually shows other pins active as well but they don’t actually do anything.
This happens with both Raspbian Lite and HassOS so it must be HassIO that’s at fault here.
What makes the matter worse is that today I found out that if I hard reboot pi it won’t boot, the red light will stay on and no USB devices will power up, you won’t even get shell. If i disconnect the sensors it will boot fine, and I can hook them back up and they will work without any issues.
UPDATE on above boot issue: don’t use pin0 (gpio0) as its reserved for flashing, so it will work but when you reboot your PI it will hang during boot up. Only use pins marked in green on the official PI schematic
Any insight on this would be great, or maybe someone else can turn on their pins to see if they show up as on
Did you at any stage connect the reed switches before you set up the GPIO pins to INPUT?
If a GPIO is set to OUTPUT and you connected a closed switch between it and ground, it will create a short circuit, pull a load of current and potentially fry parts of the PI. I have done it before myself.
You say the PI boots without the sensors? So you may still be shorting a GPIO to ground, but current not permanently fried it.
Double check you GPIO modes.
To safe guard against short circuits it is recommended to put 1K resistors on each input to limit any “mistakes” to 3.3mA. Unless of course your switches already have resistors in them.
Another thing to note is that not all GPIOs have internal pull ups (I don’t believe), so on some you could get inconsistent results as the input is “floating” picking up ambient RF when the switches are OFF.
The switches where already there, they are basic reed switches I tested them for continuity that’s about it. They dont have any resistors in them, and I thought that pi already includes pull up resistors.
I plugged them in when pi4 was already running, since they worked before on pi3 didn’t think there would be an issue. How do you change GPIOs between INPUT / OUTPUT? is there some way to trouble shoot this? Maybe there is some command line app i can run to see what’s active?
According to HA the default is it activates a pull up resistor, and uses ACTIVE HIGH logic.
You are also right, one of the GPIOs (GPIO14) is floating, when it goes to on (open circuit) it doesn’t stay on it keeps jumping up and down…
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.
If you are using the default “Pull Up”, then you would need your switches connected from the GPIO to ground. This is the risk configuration, grounding a OUTPUT pin can cause damage.
I would double and triple check your wiring. Try adding the sensors one and at time and see if they work.
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
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?
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.
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, 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.
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.
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:
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:
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?
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.
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.
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.
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.
