Closed JCiszSi closed 5 years ago
ok, What version Pi are you using and what OS image are you on? I'll test it out.
I'm using the Raspberry Pi 3 with Raspbian (version May 2016)
is it jessie or jessie-lite?
I think that I have an idea that will fix the problem ( I am unable to reproduce it on my raspberry pi 1 or 2, so I think that it is 3 exclusive ). I'll let you know when I have a possible fix.
ok, I updated gpioneer. hopefully this will fix the shutdown problem. Try this:
sudo nano /etc/rc.local
Delete the line that reads: python /home/pi/gpioneer/GPioneer.py &>/dev/null & exit and save, then:
cd ~/gpioneer sudo bash remove.sh git reset --hard origin/master git pull sudo bash install.sh
That should get you completely up to date. Gpioneer will automatically start with the system and you can easily stop/start gpioneer and the web interface using these commands:
sudo systemctl stop gpioneer -or- sudo systemctl stop gpioneer-web
Unfortunately the shutdown problems doesn't disappeared with the new version - at least not completely :( The Raspberry now reboots, but needs for this a very long time (about 2 Minutes).
But the bigger problem is that the whole GPioneer didn't worked anymore at first: The configuration of the buttons was possible and also the Webserver was up (with the new really nice menu :+1: ), but the new logs page produced some errors (see the attached picture) and the GPioneer didn't have responsed to any keypresses. I had to stop the GPioneer Service through the Web Interface first and reboot and now it works probably (at least with the long reboot delay).
After a little bit try and error I've found the line "pins = [pin['#'] for pin in self.PIN_LIST]" in the definition of the signal_handler (line 143) - when this line is commented out, then the reboot and shutdown goes normally.
I'm not sure if there is any fundamental function in this line, but as for now it works for me :)
PS: I'm using the full jessie
so that line pins = [pin['#'] for pin in self.PIN_LIST]
is to generate a list of the pins that you are using, then the next line (GPIO.cleanup(pins)
) cleans them up for other programs to use them. By commenting out that line, it means that the next line (GPIO.cleanup(pins)
) will error out, because the variable pins
has not yet been set. For the most part, it's not really a problem.
At least we now know what is causing the problem. I think that there must be some problem with the RPi.GPIO module, because it only does this on the pi3. When I get my hands on one, I'll be able to troubleshoot it more.
I have seen the same slow reboot issues on my Pi3 as well (you probably remember that we have gone through several rounds of troubleshooting together). If I am reading this correctly, JCiszSi above may have found a workaround for the slow reboot issue. Is that correct?
I'd like to try reinstalling GPIOneer, as it still seems like a handy method to leverage GPIO for just about anything. Which file exactly do I need to edit in order to comment out the "pins" definition? Also, it sounds like I might as well comment out the cleanup line as well since that will just generate an error otherwise.
yep, its line 148 of the file GPioneer.py
Hi mholgatem,
after further using your GPioneer we've encountered that the Raspberry Pi isn't able to reboot or shutdown anymore. It will hang on the message
"[OK] Stopped target Remote File Systems (Pre)."
without any explicit other errors. If I kill the script with "sudo pkill -9 -f GPioneer.py", then I can reboot and shutdown normally.