Power switch button for printer #103

Open
opened 2026-07-28 19:16:40 +02:00 by ok24 · 4 comments

Description

Implementation of a button for an external power switch to power Kobra X printer on and off

Motivation

Many KobraX printers are likely controlled remotely because the printer is not located right next to the workstation (e.g., in a separate workshop in the house).
To switch the printer on and off, switches controlled via HTTP requests are typically used, such as Sonoff/Tasmota switches.

Proposed Implementation

Therefore, it would be useful to implement an On/Off button, for example in the "Printers" dialog as shown in the attached image.
The URLs for powering on (e.g., http://192.168.1.235/cm?cmnd=Power%20on) and powering off (http://192.168.1.235/cm?cmnd=Power%20off) could be configured in Settings.

## Description Implementation of a button for an external power switch to power Kobra X printer on and off ## Motivation Many KobraX printers are likely controlled remotely because the printer is not located right next to the workstation (e.g., in a separate workshop in the house). To switch the printer on and off, switches controlled via HTTP requests are typically used, such as Sonoff/Tasmota switches. ## Proposed Implementation Therefore, it would be useful to implement an On/Off button, for example in the "Printers" dialog as shown in the attached image. The URLs for powering on (e.g., http://192.168.1.235/cm?cmnd=Power%20on) and powering off (http://192.168.1.235/cm?cmnd=Power%20off) could be configured in Settings.
ok24 added the
enhancement
label 2026-07-28 19:16:40 +02:00
Owner

Thanks for the suggestion, @ok24 — this is a real gap for anyone running the printer on a smart plug in a separate room, since the printer itself has no MQTT command to power off or enter standby (nothing like that exists in its protocol — only heaters/motors/etc. can be controlled remotely, the mains power itself can't).

A Tasmota-style smart plug is the right way to solve this, and I'd rather implement it as Moonraker's standard machine.device_power API than as a bridge-specific button: Mainsail and Fluidd already have a built-in "Power Devices" panel that renders on/off toggles automatically for anything reported there — no custom UI needed on either side, and it's the same mechanism people already use for other Klipper-connected smart plugs (Tasmota, generic HTTP, Home Assistant, etc.), not just this bridge. Currently machine.device_power.* isn't implemented at all, so nothing shows up there yet.

I'll add it as a config entry (device name + on/off URL, e.g. your Tasmota cmnd=Power%20on/off example) so a configured switch appears the same way a native Moonraker power device would in Mainsail/Fluidd — should also cover other HTTP-controllable switches, not just Tasmota specifically.

Picking this up as a real feature — will follow up here once there's something to test.

Thanks for the suggestion, @ok24 — this is a real gap for anyone running the printer on a smart plug in a separate room, since the printer itself has no MQTT command to power off or enter standby (nothing like that exists in its protocol — only heaters/motors/etc. can be controlled remotely, the mains power itself can't). A Tasmota-style smart plug is the right way to solve this, and I'd rather implement it as Moonraker's standard `machine.device_power` API than as a bridge-specific button: Mainsail and Fluidd already have a built-in "Power Devices" panel that renders on/off toggles automatically for anything reported there — no custom UI needed on either side, and it's the same mechanism people already use for other Klipper-connected smart plugs (Tasmota, generic HTTP, Home Assistant, etc.), not just this bridge. Currently `machine.device_power.*` isn't implemented at all, so nothing shows up there yet. I'll add it as a config entry (device name + on/off URL, e.g. your Tasmota `cmnd=Power%20on/off` example) so a configured switch appears the same way a native Moonraker power device would in Mainsail/Fluidd — should also cover other HTTP-controllable switches, not just Tasmota specifically. Picking this up as a real feature — will follow up here once there's something to test.
Owner

Implemented, @ok24 — went with a bridge-native button as you suggested rather than routing through Moonraker.

Added a "Power Switch" section in Settings where you can configure power_on_url, power_off_url, and an optional power_status_url (your Tasmota example works directly: http://192.168.x.x/cm?cmnd=Power%20on / ...Power%20off, and ...cmnd=Power for status). Once at least one URL is set, a 🔌 button appears on that printer's card in the Printers grid — clicking it fires a plain HTTP GET at the configured URL, no Moonraker/Mainsail dependency at all. If a status URL is configured, the button also shows the plug's current on/off state (parses Tasmota's {"POWER":"ON/OFF"} response, with a plain-text fallback for other switch firmwares) instead of a static icon.

One safety detail: turning power off asks for confirmation first, since there's no way for the bridge to know a print is running on a smart plug it doesn't otherwise talk to.

Also worth mentioning since it surfaced while testing this: found and fixed a bug where config.ini values containing a % character (exactly what your Tasmota URL example has, Power%20on) were rejected outright when saving settings — configparser's default string interpolation misread it as a broken variable reference. Would have affected anyone trying to save a URL like yours regardless of this feature.

Committed on nightly with test coverage, going out with the next nightly build.

Implemented, @ok24 — went with a bridge-native button as you suggested rather than routing through Moonraker. Added a "Power Switch" section in Settings where you can configure `power_on_url`, `power_off_url`, and an optional `power_status_url` (your Tasmota example works directly: `http://192.168.x.x/cm?cmnd=Power%20on` / `...Power%20off`, and `...cmnd=Power` for status). Once at least one URL is set, a 🔌 button appears on that printer's card in the Printers grid — clicking it fires a plain HTTP GET at the configured URL, no Moonraker/Mainsail dependency at all. If a status URL is configured, the button also shows the plug's current on/off state (parses Tasmota's `{"POWER":"ON/OFF"}` response, with a plain-text fallback for other switch firmwares) instead of a static icon. One safety detail: turning power *off* asks for confirmation first, since there's no way for the bridge to know a print is running on a smart plug it doesn't otherwise talk to. Also worth mentioning since it surfaced while testing this: found and fixed a bug where `config.ini` values containing a `%` character (exactly what your Tasmota URL example has, `Power%20on`) were rejected outright when saving settings — configparser's default string interpolation misread it as a broken variable reference. Would have affected anyone trying to save a URL like yours regardless of this feature. Committed on `nightly` with test coverage, going out with the next nightly build.
Author

great news ! - I will test it at soon it is available. Thank you very much !

great news ! - I will test it at soon it is available. Thank you very much !
Author

I testet the new feature today evening. The tasmota switch operates very well with the new settings.
In my opinion only the visualization has a little problem. As shown in the screenshot the power state is "off" (the popup hint for the next click on the button shows "Power:on"). But the green circle and text didn't have this state and shows "ready" with green color.

I testet the new feature today evening. The tasmota switch operates very well with the new settings. In my opinion only the visualization has a little problem. As shown in the screenshot the power state is "off" (the popup hint for the next click on the button shows "Power:on"). But the green circle and text didn't have this state and shows "ready" with green color.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#103
No description provided.