I have a couple of devices (cooling fan, and LED lights) connected through GPIO pins on Rpi3. This setup used to work flawlessly in OctoPi 0.14.0. after re-imaging and restoring all OctoPrint settings the GPIO commands and shell scripts do not work.
The sh scripts are very simple:
gpio mode 0 out
gpio write 0 1
then I use System Command Editor plugin to add a menu item to OctoPrint.
However after a cold boot up or a reboot the sh script does not work at all (therefore the system command menue items do not work). There are no errors or messages. simply running sh pin11_on.sh will not turn on the gpio pin.
However if I ssh to server and just run "gpio mode 0 out" one time then everything works for as long as the machine is up. running the sh scrips can turn that pin on and off without issues. Everything also works via the webUI after that. I have to do this for every used GPIO pin, otherwise scrips won't work at all.
After every reboot the issue is back.
The permissions on the sh files are set to 755. The owner is pi. Running the sh file as sudo will not work either.
Am I missing something? I have another RPi 3 running Repetier Server on Raspian with exactly the same hardware setup and everything is working fine there. OctoPi is the only one giving me this problem so far. Additionally this was all working with the OctoPi 0.14.0 and nothing has changed hardware wise other than reimaging the SD to 0.16.0.
Sounds like you might need to run the gpio mode 0 out command in a script at bootup.
Why does this happen in the first place? what is the difference between running this command via sh and same user account just typing it at the terminal?
This doesn't make any sense.
well... I added it to /etc/rc.local and no dice. it still does not work when the RPi is rebooted.
Note that /etc/rc.local runs by root during bootup. You might need to give a full path to any scripts or whatever.
I just added these lines to the /etc/rc.local:
gpio mode 0 out
gpio mode 2 out
…
did I do something wrong?
Do a which gpio, determine the full path and then prepend that. The root user doesn't have the same path as the pi user.
this workaround works. however this is just a band-aid fix.
I still do not understand what they screwed up in the new OS/driver/software, and what the root of the issue is. The strange part is that if I run my .sh script in command line it does not work after reboot. I have to actually type the gpio mode command via console, then the .sh starts working after that.
what is the difference between running a command in the shell, or executing a script to run the same command in the same shell? I have never experienced any difference on any other Linux/Unix system other than RPi (although other device/servers/mainframes/VMs I have ever worked on did not use gpio)
Good question, Gary
~ SpongeBob
When you're in the command line, you've logged in. As a part of logging into the Raspbian Buster Lite terminal, it's done at least one thing for you: running (sourcing) your ~/.bashrc file for you. This will modify the world around you. For example, it will set the PATH variable so that it knows where to find executables which don't include the full path to them.
So now, when something runs under the context of initd or systemd or rc.boot or similar then it's probably running as the root user and will almost always have a different path.
And then there are scripts which are fork'd or spawn'd from something like OctoPrint. I'm not 100% sure of what setup they'll get. I'm somewhat confident that it will be running under the pi user's security context but it won't necessarily run your ~/.bashrc file, though.
And so, whenever we write scripts for general use we almost always prepend the entire path all the way back to the root folder just for safety's sake; you never know how/when your script will be run.
Well, that's not exactly what I meant by running sh script. The issue I am facing is that I ssh to the Pi, log in as Pi user, run the led_on.sh and it will not work. Even running it as root (sudo sh led_on.sh) does not work. I have to type "gpio mode 0 out" first, then my .sh files will work. after running that for the first time, now all the sh script files run correctly.
What I don't understand here is what is the different between my user running the command via a sh script, or just typing the command at the prompt. To my knowledge I didn't know there was a difference and I had never observed a difference in any Unix/Linux systems before.
Additionally this is something new with this release, it worked fine before. Is this something special about gpio program itself after the update, or a change to kernel or shell on how it executes scripts vs typing commands? I'm a bit lost on this.
Something is broken/changed with this release. I don't know if this is something that can be replicated with other commands or only gpio is special?
Oh alright. I gotcha now.
I think something changed in Raspbian (Buster?) itself which now doesn't seem to persist these gpio-17-is-an-out-device sort of changes. So yeah, this isn't you and it's not really OctoPrint/Octopi either (other than newer Octopi images pull from newer Raspbian images).
You'll need to persist these settings at bootup, in other words. You need to have any of the bootup type of scripts call your script for you.
There's also this race condition described by someone on here who obviously knows what's-what. He's talking about the OrangePi but it's possible that his method may help you as well. Look at that udev stuff to see what commands he's running there.