Webcam activates LEDs?

thanks again Guru. i forgot about the executable privilege. i did that for the .sh file when i first tried this a couple days ago, but forgot that step when trying the python alternative. so i went ahead and set that, and updated the System Command plugin to run:

sudo /usr/local/bin/scripts/

Im running a job right now though, so im going to wait for it to be finished before i try it... just to be safe. As a side note, since there were so many script options above, this is what i currently have in the .py...

import RPi.GPIO as GPIO



GPIO.setup(red, GPIO.OUT)
GPIO.setup(green, GPIO.OUT)
GPIO.setup(blue, GPIO.OUT)

GPIO.output(red, 1)
GPIO.output(blue, 1)
GPIO.output(green, 1)

So as i understand, BCM sets the #ing to be the GPIO #, not the pin #. So, the above #s correspond to GPIOs i used, not the pins.

i know these lights work with PWM, as i can get any color thru the Enclosure plugin. So, IF this works, im assuming this will give me full brightness. Either that or it will give me 1/255th brightness.

and a final thought, in 1 of the tutorials, it made mention of needing python 3 or newer. Iv never updated python since installing Octopi, so im currently on 2.7 i think. Will that have an effect? I looked up how to update python and the one page i found on it seemed pretty involved... compling and such... something iv never done, and several users were reporting it taking hours.

Good to see things are moving. I´ve found a tutorial using this strips on raspberry, but I don´t want to make things more complicated.

Adding the link, if you want to take a look:

You do want a shebang there as the first line. Since you're running this by the script name (rather than saying sudo python, then you must start with a line that's something like:

#!/usr/bin/env python

... or...


...or whatever it is supposed to be. In the case of OctoPrint and its venv setup, it's probably a good idea to use that version of Python rather than any version that might be in the path.

And I like to use which nicely shows the BCM pin numbering right next to the hardware ("BOARD") pin numbering.

i looked in usr/bin and i found env, but not venv. so, at the top of the .py i added (as you had)...

#!/usr/bin/env python

stangely (to me), i could not cd into env when in the terminal. even though it showed up with ls, it said not a directory when i tried to get into it. so i write that out, go back into octo, power menu, press my Light On button, and i get the following error...

Command for custom:lon failed with return code 1:
STDERR: sudo: no tty present and no askpass program specified

i was getting this earlier to when i was trying different python things. so, seems i need a tty and an askpass...?

Johnnie, thanks for that additional link. from what i understand, this should be doable without having to download anything additional, so im going to try and get this working as is first before downloading more. theres probably just something simple im missing at this point.

The env command tells you what is currently stored in the environment (variables). One of them is the path to the python executable, in theory. So the first line reads something like: "look up the version of python that's in my path and run this if someone attempts to run this script by itself". So if you try to do a sudo it will know that this is a python script (even if you decided to drop the file extension on your script.

The venv program is a way of creating a virtual environment which isolates one Python-based project from another. Foosel has this folder under ~/oprint as I recall. We might pay attention to that later if this first attempt gives you troubles.

Okay, so from your error it looks like sudo wants to ask for a password and yet this is happening behind-the-scenes and there's nobody to give it. What's odd is the tty part of that.

I might need to rewind on this thread but is this an OctoPi image that you're using or did you use the manual route. I know that Guy (the author who keeps up that distribution) has done some clever things with the pi user's rights and this elevation is sometimes not necessary. Maybe @foosel can help here with the sudo bit.

thanks for giving this some effort Guru. im trying to follow along as best i can. i had a look in the usr/bin folder, and it seems i have quite a few python folders, including python3.5, so im not sure why i got a version of 2.7 when i did...

cd /
python --version

... probably not related to the issue, but i was just checking.

fwiw, i tried using your 2nd suggestion above, and just going with /usr/bin/python, and that threw the same tty error.

as for as my octopi install, it was from an image, not a manual install. i just followed the instructions on one of the many pages about getting octopi/print up and running. it was pretty painless. eitherway, hopefully this info is narrowing down what the issue here might be. is there any possibility that Enclosure plugin is somehow hijacking those gpios and not letting anything else access them?

@Johnnie_Walker , i tried your link above for using PIGPIO. i got it installed and tried running the first command (thru a putty terminal)...

sudo pigpiod
pigs p 33 255

and i get...

ERROR: no permission to update GPIO

so why does it feel like i dont have permission to do anything! is that my problem here overall? some sort of permission wall im behind?


Regarding your response to Johnnie, you loaded the daemon with sudo (good) and that's running in the background. It will accept client calls, look them up and respond back.

The second command pigs is the one that's likely throwing the error. Try prepending with sudo and see if that works out better. Like I mentioned earlier, writing to GPIO requires root.

damn, this is getting very frustrating. i just opened the terminal to try your suggestion (though im pretty sure i tried sudo pigs last night after it didnt work the first time), and i get...

sudo pigpiod

initInitialise: Can't lock /var/run/
Can't initialise pigpio library

To the best of my knowledge, the daemon (the program that ends with a "d") was already running. You can verify by running ps -ax|grep pig and look for the daemon version.

Assuming the daemon (server) is running, then run sudo pigs p 33 255. That's the client side of all this.

ok, that would make sense that its running, as it would have been running from when i tried last night.

sudo pigs didnt work though, still says no permission to update GPIO. as for the other ps command, this is what it spit out...

16603 pts/1     S+      0:00 grep --color=auto pig
17224 ?         SLsl    26:35 pigpiod

The first line of output from ps is you searching for "pig" (it's odd that it does that but that's just the way it is) and the second line is your daemon.

Regarding the error, it's possible that you might have to run sudo raspi-config and turn on the I2C interface for this to work.


Start up the daemon again to allow write access to all the GPIO pins.

sudo killall pigpiod    # kill the daemon
sudo pigpiod -x -1      # restart the daemon granting access to all gpios

bam! we have light! the access to all gpios seems to have done it. will this work with the System Command editor though? that will have to wait for a bit later for me to try. but, in the mean time, what sort of script do i need to write that will be run... .py or .sh? does pigs need its own special file extension?

thanks so much guru!

1 Like

We talked about the shebang earlier. Having one of those at the top of your script means that it doesn't need a .py extention; the first line tells your shell what program it runs under (Python, in this case).

This ought to work with the System Command editor. Just remember that you might have to give the full path to a program if it doesn't work otherwise. You might need to restart OctoPrint between editing sessions for the edit to be seen.

Very good you´ve made it! I´m not a developer guy, so I would create a simple bash script to turn on or off this, like the example I´ve added before, replacing the command with the pigs command.
Just remember to give execution permission to the script, and add sudo as a prefix of the command.

perfect, everything works! i ended up using the...


to start the .sh file. Then, had to remove sudo from System Command editor's command. So, all working now...


i can see down the road it will become an issue that ill restart the pi, or something, pigpio will need to be restarted, and that -x -1 command will need to regrant access to all gpios. so we also know that if we try and run sudo pigpiod while the daemon is already running, it will throw back an error. is there a simple if/then statement i can include that will check if the daemon is running, and if it is, run the pigs commands, and if it is NOT, run sudo pigpiod first?

i did some googling around, and i feel im close, but im not quite there. this is what i have in currently, which i took from here



if (( $(ps -ef | grep -v grep | grep $service | wc -l) > 0 ))
pigs p 26 255
pigs p 13 0
pigs p 19 0
sudo pigpiod -x -1
pigs p 26 0
pigs p 13 255
pigs p 19 0

so, IF the service is already running, its fine, it sets the correct color, but it seems that if its not running (if i kill it first to test if it will get turned back on), it is NOT getting turned on, and i get a socket error for each of the pins im trying to activate. maybe this has to do with what 'else' is looking for, or what that first command is returning? i honestly have no idea what that command is doing... all i know is its somehow testing to see if the service is active.

im testing all this in the terminal from the bin/scripts folder where my scripts are, so i know i dont need to be including the location of pigpio, right? it works when i type it in manually, but not when its run from the .sh

any more ideas on getting THIS bit to work now?

Okay, so running with the pig version... it sounds like you want to persistently start the daemon on bootup. I just ran the following search in Google: raspbian start pigpiod on startup. This gives us many competing ways of doing things "old-school" but the easiest then is:

sudo systemctl enable pigpiod.service

Then reboot.

ah, ok, thats an idea too... didnt think of just having it run at startup. but, again, will this take into account the -x -1 part of the command? that was essential to getting it to work. also, is this a set-it-once command? once i do it it will always start at bootup?

Good point. It probably won't.

So then, there's about three ways to do this. The author of the daemon suggests using crontab so let's go with that:

sudo crontab -e            # Choose option 2 for nano as the editor

You're expected to add this to the end of the file:

@reboot              /usr/local/bin/pigpiod

But I think I would then add your arguments to the end of that command.

And yes, these are all do-it-once sorts of things.

that did it! editted the light_on script back to just the pigs commands, rebooted, ran the script the System Command editor and it worked, so all permissions and such seem to be set and working after a reboot.

thanks so much for your help guru, and johnnie. probably wouldnt have gotten this working without you!

1 Like