Other plugins can force RPi.GPIO as the default crashing the app when using a button

[thomst08]

Using a different app that requires the RPi.GPIO library, this can cause the plugin to crash when on a later version of OctoPrint.

This happens because gpiozero will automatically choice between lgpio or RPi.GPIO depending on what's installed, if another plugin is running and using RPi.GPIO, it will use this library instead to avoid conflicts, however, this will cause the plugin to crash if using a button to control the light, this is because RPi.GPIO does not work correctly with that later versions of the Linux kernel.

[thomst08]

Explorer options in forcing the plugin to use a select library as discussed in #14

[TheShanMan]

Not that I want to rush you if you don't have the time at the moment but otherwise I'm curious if you've hit any roadblocks or if it looks like the discussed changes are going to work?

[thomst08]

Hey @TheShanMan,
It's all good, I was working on this last week and hit a few problems with getting this working, I'm planning on looking at this again today.
I will let you know what I have found when I'm abit more organised

[thomst08]

OK!!!
Hey @TheShanMan, I have finished researching and testing it....
First of all, I have setup a build that allows you to select what library to use when dealing with the GPIO pins, however, I found it not to be working very reliably, so I had to do some digging to get it working, what I found was the GPIOZero library is not that latest, Octo Enclosure is forcing the library to be on a much older build, this make sense as that version if for older python versions, but as this is much more current, it causes a conflict with the latest lgpio library and fails...

So I could not get it working unless I directly forced the code to overwrite the default pin library, but even then, it might fail due to the conflict on the new lgpio and the GPIOZero library, so this didn't help....

What you can do, is force the latest GPIOZero library by SSHing into the PI and doing the following commands

./oprint/bin/pip install --upgrade --force-reinstall --no-cache-dir gpiozero
sudo reboot

Once done, it could break the Enclosure plugin, however, OctoLight will work as expected, the latest library will function correctly. I could then change the default library, but again, didn't work reliably.

So a few things:

• Current version of OctoLight is fine, I wont make a new version to allow the user to change the GPIO library as it doesn't do much and causes more issues (plus I would need to test it with older builds to make sure it does not screw with them)
• The main cause in this case is the Enclosure plugin is super old, its also depracated. As far as I am aware the maintainer is working on a new version and seeing if people want to help. The main issue with the plugin is it does not support the newer standards and forcing a downgrade on the libraries OctoLight needs to work. Unfortunately this is just a conflict I can't really correct and the Enclosure plugin needs to update it code.

Running that command should solve the issue, but I do not know if that will break the other plugin completely or if it will work just fine, but give it a try and let me know.
I can do other things if needed, but this is what I have found so far.

[TheShanMan]

The enclosure plugin works fine after running that command. I then installed OctoLight and the output works fine but it isn't detecting the button press whether I specify it by pin number or GPIO number. Maybe I should re-flash my octopi card, try installing OctoLight first, get the input working, and then install the enclosure plugin and run the command.

[thomst08]

Hmmmm, give that a shot and let me know what happens.
I might need to see more of your OctoPi environment to try and work out why that happened, I will also format my Pi again and see if I can get the same result you where, you might need to re-run the command after a plugin install and it might have caused a downgrade after the forced upgrade. But I will see if I can replicate what you had.

[TheShanMan]

Looks like it works after all. I forgot that I still need to modify the octoprint service. Now the 2 plugins function together. The only issue is neither one pays attention to external changes to the output GPIO, so if I turn it on with OctoLight, then the enclosure plugin still thinks it's off so I have to toggle twice with the enclosure button to turn the output back off. And vice versa - if I turn it on with the enclosure plugin, I have to toggle twice with OctoLight to turn it back off. I can live with it but it would be nice if both plugins had the ability to periodically poll the current value of the GPIO, or just poll right when you tap the icon. Maybe it could be an option which is disabled by default. Just a thought.

Thank you for figuring out a path forward for using both plugins!

[thomst08]

Hmmmm, it sounds like you have both plugins reading the same pin?
If that's the case, that's not really recommended.... the libraries used for both plugins want to fully control the pin, when you have a pin being shared between the two, the libraries overwrite one another, they don't share info like that, so that isn't really wise.....

What would be better is OctoLight has a API you can interact with, so if we can make the other plugin check through that API (or vise versa) then this might help with this issue as you only one one plugin in control of something at a time.

[thomst08]

Just to go over this a bit more, I can see you can do "Shell Scripts" for outputs on the Enclosure plugin, that would/should allow for calling OctoLights API and toggling the light switch from the Enclosure plugin, but for detecting an input.....
Could you write the lights output pin to the light switch and another pin to detect when the light pin is high?

[TheShanMan]

Yeah I realize it's not a recommended use case, and I don't expect you to cater to such use cases. It looks like the enclosure plugin loses some of the options if you switch to "shell script" so I'm not sure that's a great option. The setup I have now with both plugins setting the output is definitely klunky but seems to be the best option currently. Who knows... if I get some time maybe I'll see if I can tweak the enclosure plugin code based on what you've figured out. I sure appreciate the time you've put into this. It's helped me out a lot and might be helpful to others who use the enclosure plugin.

[thomst08]

It's all good ThShanMan, I will leave this open for the moment and close it later once I have updated the README with some of this information so others can force library updates if needed.
Reach out again if you need anything else.