@kantlivelong - Thanks for creating and maintaining the PSU Control - RPi.GPIO plugin. Using your code and OPi.GPIO, I was able to make it work on the OrangePi Lite V1. Wanted to get your feedback on the best way to proceed with this if I wish to share it with other pp.
Thanks!
There's a good chance that you can simply use the core plugin without any sub plugin at all. If that's not the case you're welcome to fork the sub plugin and publish it on the repo; though I'd be interested in figuring out why the core plugin wouldn't work.
Hi....accepting your host processor isn't fueled from your psu then startup would be something very similar, however you would require another activity order for the firmware restart. In the event that your host is controlled from the PSU (as mine is), you can't send an activity order to turn it on. You need to design the force on with the top bar button, or by one of different methods PSU control archives.
You can't put gcode macros in real life orders like that (gcode: RESPOND TYPE=command MSG=poweron), they just exist in klipper.
wrong thread?
That was my initial thought, I looked up the BSM numbering for my device and inputted it into the pluggin and got this error:
octoprint.plugins.psucontrol - INFO - Periphery version: (2, 3, 0)
octoprint.plugins.psucontrol - INFO - Using GPIO for On/Off
octoprint.plugins.psucontrol - INFO - Configuring GPIO for pin 12
octoprint.plugins.psucontrol - ERROR - Exception while setting up GPIO pin 12
Traceback (most recent call last):
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/periphery/gpio.py", line 539, in _open
self._chip_fd = os.open(path, 0)
PermissionError: [Errno 13] Permission denied: '/dev/gpiochip0'
I figured that it could be occurring cause I am running octoprint on a non-root user and the permissions for the octopi user to access the gpio are not setup. Unfortunately, I could not find much support of the OrangePI and python periphery library. However, I did see that pp were able to get around this creating a UDEV rules for the OPi.GPIO.
If you have any ideas on how I could solve it I would be happy to give it a try.
Does orangepi's os have a gpio/dialout group? maybe adding the user would resolved the permissions error.
Yeah quick look at the install instructions seems to indicate that's the right approach. I assume octopi has the udev rules preset.
Yeah it's a simple permissions issue.
Exec and report back with the results:
groups OCTOPRINTUSER
ls -la /dev/gpiochip*
output from terminal
octopi@orangepilite:~$ groups octopi
octopi : octopi tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh gpio
octopi@orangepilite:~$ ls -la /dev/gpiochip*
crw------- 1 root root 254, 0 Jun 25 02:40 /dev/gpiochip0
crw------- 1 root root 254, 1 Jun 25 02:40 /dev/gpiochip1
FYI, in the armbian image I got the gpio group was non-exiting. I created it using "sudo addgroup gpio". Then I followed a newer version of the instructions that @jneilliii referenced above
So as a test exec sudo chgrp gpio /dev/gpiochip* then try again in OctoPrint.
Err add a sudo chmod g+rw /dev/gpiochip* as well... So
sudo chgrp gpio /dev/gpiochip*
sudo chmod g+rw /dev/gpiochip*
permissions changed:
octopi@orangepilite:~$ ls -la /dev/gpiochip*
crw-rw---- 1 root gpio 254, 0 Jun 25 03:43 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Jun 25 03:43 /dev/gpiochip1
However got a new error on the log
octoprint.plugins.psucontrol - INFO - Periphery version: (2, 3, 0)
octoprint.plugins.psucontrol - INFO - Using GPIO for On/Off
octoprint.plugins.psucontrol - INFO - Configuring GPIO for pin 12
octoprint.plugins.psucontrol - ERROR - Exception while setting up GPIO pin 12
Traceback (most recent call last):
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/periphery/gpio.py", line 623, in _reopen
fcntl.ioctl(self._chip_fd, CdevGPIO._GPIO_GET_LINEHANDLE_IOCTL, request)
OSError: [Errno 16] Device or resource busy
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/octoprint_psucontrol/__init__.py", line 190, in configure_gpio
pin = periphery.GPIO(self.config['GPIODevice'], self.config['onoffGPIOPin'], initial_output)
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/periphery/gpio.py", line 496, in __init__
self._open(path, line, direction, edge, bias, drive, inverted, label)
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/periphery/gpio.py", line 547, in _open
self._reopen(direction, edge, bias, drive, inverted)
File "/home/octopi/OctoPrint/env/lib/python3.7/site-packages/periphery/gpio.py", line 625, in _reopen
raise GPIOError(e.errno, "Opening output line handle: " + e.strerror)
Maybe I should disable my other plugin?
Yeah make sure the same pin isn't being used by another plugin/proc.
it worked!!!!
octoprint.plugins.psucontrol - INFO - Periphery version: (2, 3, 0)
octoprint.plugins.psucontrol - INFO - Using GPIO for On/Off
octoprint.plugins.psucontrol - INFO - Configuring GPIO for pin 11
octoprint.plugins.psucontrol - INFO - Switching PSU On
octoprint.plugins.psucontrol - INFO - Switching PSU Off
octoprint.plugins.psucontrol - INFO - Switching PSU On
octoprint.plugins.psucontrol - INFO - Switching PSU Off
octoprint.plugins.psucontrol - INFO - Switching PSU On
octoprint.plugins.psucontrol - INFO - Switching PSU Off
looks like my 12 pin still reports as being used by the other plugin, but pin 11 works great!.
awesome!
You'll want to create a udev rule to make it permanent.
echo 'SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"' | sudo tee -a /etc/udev/rules.d/99-gpio.rules then reboot. Might do the trick.