Hey, does anyone have any experience using RPi.GPIO in an octoprint plugin? I'm developing a plug-in to interface octoprint with a 3x4 membrane keypad using pad4pi library so you can connect it directly to the raspberry pi's GPIO header. For some reason with my plug-in enabled octoprint will fail to start the first time and go into safe mode. It works normally the second time and everything functions without error. Tried turning up logging verbosity and cannot seem to figure out what the problem is.
I'm an electrician by trade and have messed around with programming and python in the past, it's possible I made a silly mistake. Wondering if I should put my code up on github anyway so maybe someone more experienced can point out where I went wrong?
If your end goal for this plugin is to contribute it to the repository, then putting your code up on github will be required at some point, so now is as good as any to get started. If you don't want to publish your plugin, then you can create a zip file and post it here.
As usual, we will also need the log files (octoprint.log, serial.log). For the logs, delete existing logs to get a fresh start and then go through the steps above for first time and second time. You can zip them up and post them here.
I updated the log on the repository after trying to restart again and it went into safe mode, though there doesn't seem to be any additional information as to why it failed to start
The octoprint.log posted in the repository still starts "after the fact". I'm not sure what triggers OctoPrint to rename the current octoprint.log and start a new one, but apparently this error must be one of those triggers. I'd suggest that you delete the octoprint.log and all octoprint.log.* files. Then I would disable all of the addons except yours (and the bundled ones you can't disable) and restart the system. After OctoPrint restarts in safe mode, go and look at (and post) any previous octoprint.log.* files for the cause of the problem.
I know that the log starts after the fact but it also does it again in the same log, if you would kindly take a look at line #764 is where I triggered a restart and it goes into safe mode. Was planning on buying another pi for other projects so first thing I'll do is a clean octopi install and try the plugin on there, though I did at one point disable all other plug-ins in my troubleshooting process. Idk what could be causing the problem when at full verbosity it doesn't throw any error. Perhaps it's because the plug-in was installed in dev mode as described in the plug-in development tutorial?
Good News: I finally got the latest octoprint.log you posted to actually show on my computer.
Bad News: I have no idea what's going on and I can't find anything in the log that helps.
The interesting log would be the one from before the safemode one. Take a look into ~/.octoprint/logs, there are old octoprint.logs there as well called octoprint.log.2019-06-17 and such (the logs rotate daily). It should hopefully be one of these. Alternatively start OctoPrint manually from commandline (on OctoPi: sudo service octoprint stop && ~/oprint/bin/octoprint serve --debug) and see if the error gets logged there.
Never mind, I found the log you were talking about. You directly linked to the old version up there, so just clicking on the link didn't produced the most recent version. Would have been better to either update the link or paste a new one, this way it was a bit confusing.
Anyhow, I took a look into your code because the log didn't help indeed.
On this line you effectively block the whole startup routine since your keypad_thread isn't actually spawning a new thread but instead blocking the current one.
This has to happen in a newly spawned thread, otherwise you block the startup, the flag that the startup completed never gets written and the next restart enforces safe mode - exactly for these kinds of reasons.
That's why I'm an electrician and not a programmer! Thanks. Learning so much! I thought it was needed because in every pad4pi example it had that while True:
