power: make the plugin more modular

[Aulos]

I am using CLI to turn on/off my printer, so I decided to integrate it into moonraker (and, in the process, mainsail).

I have also added new /machine/power/{action} endpoints, because now it's not just gpio_power devices.

[Aulos]

Oups, I haven't seen Klipper3d/klipper#2173 before.

Is there any chance it will be merged in the near future? 😛

[jordanruthe]

Unless the mood has changed, running shell scripts was not preferred and that's why gpio was used: #1 (comment)

The other problem you'd have with running shell scripts from klipper, is klipper would function properly running a power off script, but klipper doesn't allow commands to be run when in a lost mcu state. So the power on shell script wouldn't function.

[Aulos]

The other problem you'd have with running shell scripts from klipper, is klipper would function properly running a power off script, but klipper doesn't allow commands to be run when in a lost mcu state. So the power on shell script wouldn't function.

That's exactly what happened. I tried to use shell execution plugin from kiohs installer and power off macro works like a charm. The problem is I cannot turn the printer back on, because klipper refuses to run a gcode unless it's connected to mcu.

[Arksine]

Thanks. I understand why users would like to have this, however as mentioned in the PR you linked there are significant security and resource concerns.

Later today I plan to push some commits that will allow users to toggle device power via gcode macro. You will be able to use this to "power down" a device, then use the gpio_power remote API to power it back on.

[Arksine]

I just pushed the update that allows a Klipper gcode macro to toggle the power of a device on or off. The documentation gives examples of how to do this, including of how to use Klipper's "idle_timeout" functionality.

As explained above, this can be used to turn off printer power from Klipper. A remote API call can be used to turn it back on.

For this to work it will be necessary to pull the most recent version of Klipper, as it relies on new functionality added there.

[Aulos]

I've changed the power plugin so it allows me to write my own power plugin "type" - check https://github.com/Aulos/moonraker/blob/add-cli-power/moonraker/plugins/cli_power.py

It's better than writing separate service to monitor GPIO state and send requests to my ESP device :(

[Arksine]

Thanks. The changes to the power module itself look good to me, and they are actually in line with some changes I have planned in the future. The commit message needs a signed off line before I can merge.

[Aulos]

Done

[TazerReloaded]

Hello, sorry to dig up this merged PR, but are there any plans to include the cli_power plugin as well? I understand the security concerns, there should be no way to edit the scripts from the Web-UI, which conflicts with the principle of having the whole config accessible from there. Maybe add an additional startup flag for a second config file for shell scripts that is not inside the default config directory? Could be very simple, just <alias> <path> in every line, and then we could add

[power <name>]
type: script
alias: <alias>
...

in the main config. This would prevent code injection, as only predefined scripts could be executed.

The reason I'm asking for such a feature is that I would really like to switch my camera from the UI, which is only possible by starting/stopping the according systemd service.
With a shell script, basically every functionality could be realized, not just switching something on or off, like sending an email on a certain event (print finished, filament sensor triggered, MCU disconnected), control lighting (RGB, Philips Hue), Bluetooth radiator thermostats for ambient temperature control, messenger integration, taking snapshots, and so on. So I think something like the proposed system would be really interesting.

I considered other options, like adding it directly to Klipper, but Klipper is more on the firmware side of things, controlling the printer and inputs/outputs while printing. But some tasks need to run even when Klipper is in an error state or disconnected, and some scripts can be time consuming, so they belong in the communication layer. And because Moonraker macros can be invoked from Klipper, we could even write commands in the slicer that trigger commands.

I can open a new issue/FR if necessary, but first I'd like to hear what you, think about this idea. I could build a prototype, but I'm not very familiar with Python and have a tight schedule at the moment, so that could take some time.

[Arksine]

Hi. Security concerns are just one of the potential issues with allowing configurable scripts in the main repo. Configurable scripts by their nature introduce undefined behavior. This could lead to resource issues that impact both Moonraker and Klipper that are nearly impossible to debug.

I do understand the desire for power users to have this kind of feature. There are plans in the future to allow 3rd Party plugin support. Configurable scripting could be introduced there if someone desires it. The developer of such a plugin would be responsible for keeping it up to date and providing support. Any issues or bug reports for Moonraker would need to be reproduced without 3rd party plugins enabled.

[TazerReloaded]

Thank you for the quick and detailed response! I'll wait until third party plugins are officially supported.
I noticed that Klipper has support for writing user defined variables into a file with GCode macros. Maybe I can build something around that with inotify for the time being. An alternative would be building my own little WebUI, which isn't that big of a deal either, but I'd rather have an official solution than some hack that breaks with every update.

[Aulos]

@TazerReloaded I created a simple plugin (just place it in moonraker/plugins) when I needed the CLI:
https://gist.github.com/Aulos/bbcf5b95c3c14e80a96ad5ee34802d92

I migrated now to Tasmota plugin, but you may find it useful. The use is similar to the power plugin - just create section [cli_power device_name] in config with on_cmd, off_cmd and status_cmd.