Repeat last printjob with physical push-button


At the moment I'm a bit brainstorming with myself:
sometimes (in a kind of mass production) after a completed printjob it would be nice to clear the printbed and just push a button to repeat the printjob instead of walking back to the computer and start it from there.

  • connecting a push-button do a raspi's gpio isn't the problem
  • also reading this button with a python script shouldn't be that problem - the interweb is full of examples :wink:
  • but then I'm a bit lost in space: how can I achieve that Octoprint starts the current printjob again?!?

If there is already a plugin for that purpose ... I didn't find it.
It would be much apreciated if some could give me some hints how to reach this plan.


It's possibly simpler than you might think. Since the file remains selected, you just tell it to start.

POST /api/job: {"command": "start"}

If it were me, I'd incorporate an M40 command for the Eject... or an OCTO40 using the Gcode Systems Commands plugin.


O.k. I think I see the plan:
simply have to send something like mentoined in this thread
Because I'm not a python programmer this seems a nice project over the holidays to learn something new :yum:

Regarding the "M40" command, not with my current hardware :disappointed_relieved: and ... is there a firmware out in the wild that supports this command?


It looks like Marlin doesn't support that yet. I'm not really finding the reprap firmware source but I got the M40 from so you'd think that they'd support it...

But I guess that nobody actually supports this yet.

So next, the Gcode System Commands plugin would allow you to connect something to the Raspi's header and run it from OctoPrint via, say, an OCTO40 command that you'd pair up with a Python script, a shell script, JavaScript or even a go language script or C program if you want.

Personally, I like NodeJS these days so I often try to do something with pigpio in JavaScript. But most would just use a simple shell or Python script.


Did not want to wait until Christmas and it is really easier than I had thought at first.
With my minimal to nonexistent python knowledge and the help of Google, I've managed to glue together a script that does exactly what I was up to.

from time import sleep
import RPi.GPIO as GPIO
import requests

GPIO.setup(16, GPIO.IN)

headers = {
    "Content-Type": "application/json",
    "X-Api-Key": "xxxxx...."
data = '{"command": "start"}'
url = ''

while True:
    if ( GPIO.input(16) == True ):
	#print("Button pressed")
	response =, headers=headers, data=data)

No idea if it's good programming style or you could do it better - it works, at least on my playground Pi with the Virtual Printer.

One last question: to start the script automatically I can just put a line
python /home/pi/scripts/
at the end of the /etc/rc.local before the exit 0 or can that have any side effects?


Nicely done. Take a look at my script and foosel's response which followed. She's obviously got a better way of controlling that code in her version which isn't so hungry. She's using event detection instead of live-querying the GPIO (which presumably is slow-ish).

You could put it into /etc/rc.local. Pretty sure anything GPIO-like needs to be running as root. It's good form to give the full path to the python you want (since the root user doesn't have all the PATH stuff that the pi user might). And you've got the full path to your script (good). Caveat: if you add it here and you later upgrade -> move to another OctoPi image you'll likely lose this modification since Guy manages that file.

You could look into the /etc/rc0.d folder. Review the existing K01octoprint script. Basically, "mode 0" is what happens when you boot the Raspi. Anything in this folder will run in alphabetical order. This is how OctoPrint is controllable as a service as in sudo service octoprint restart. If this feels too complicated then you could pass on that suggestion.


Ah, o.k. I see the point in foosel's response, think this way it makes more sense. Just tested it and it works.

About the caveat regarding the /etc/rc.local - that's a thing I can live with. After all this button is not a high avibility or security feature and if it doesn't work sometime I think I will remember rapidly what the cause is :blush:

Testing on my real printer is not possible before Christmas. There are too many pre Christmas "could you please" and "that would be nice to have" printjobs at the moment. :sweat_smile:

Thanks a lot for your patience.


I've just finished up a gig as a software development instructor; it comes with the territory. :wink: