External power control does not trigger bound services

[mvn23]

What happened

When using a power device with bound services, an external power event does not trigger a start/stop action on the configured bound services.

Client

Mainsail

Browser

Firefox

How to reproduce

• Configure a power device with bound services (in my case an MQTT smart socket bound to the klipper and klipper-mcu services)
• Check that bound services are being handled correctly when controlling the power device through the moonraker UI
• Trigger an external power event (e.g. push the button on the smart socket or control it directly through MQTT)
• Check that the power device gets updated in the moonraker UI
• Wait for the bound service(s) to change state accordingly...
• Wait some more...
• Nothing happens.

Additional information

The log excerpt below shows an on/off sequence through moonraker, followed by an on/off sequence through MQTT.

2025-07-09 12:52:36,220 [power.py:process_bound_services()] - Power Device printer: Performing start action on bound service klipper
2025-07-09 12:52:36,291 [power.py:process_bound_services()] - Power Device printer: Performing start action on bound service klipper-mcu
2025-07-09 12:52:37,087 [klippy_connection.py:_do_connect()] - Klippy Connection Established
2025-07-09 12:52:46,077 [klippy_connection.py:_request_initial_subscriptions()] - Webhooks Subscribed
2025-07-09 12:52:46,078 [klippy_connection.py:_request_initial_subscriptions()] - GCode Output Subscribed
2025-07-09 12:52:46,328 [job_state.py:_handle_started()] - Job state initialized: standby
2025-07-09 12:52:46,584 [klippy_connection.py:_check_ready()] - Klippy ready
2025-07-09 12:52:47,084 [data_store.py:_init_sensors()] - Configuring available sensors: ['heater_bed', 'temperature_sensor enclosure', 'extruder']
2025-07-09 12:52:50,295 [power.py:process_bound_services()] - Power Device printer: Performing stop action on bound service klipper
2025-07-09 12:52:50,354 [power.py:process_bound_services()] - Power Device printer: Performing stop action on bound service klipper-mcu
2025-07-09 12:52:50,367 [klippy_connection.py:_on_connection_closed()] - Klippy Connection Removed
2025-07-09 12:52:55,518 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.objects.query, Code: 503, Message: Klippy Host not connected
2025-07-09 12:52:55,521 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: 503, Message: Klippy Host not connected
2025-07-09 12:52:55,523 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.objects.query, Code: 503, Message: Klippy Host not connected
2025-07-09 12:52:59,987 [power.py:_on_state_update()] - MQTT Power Device printer: External Power event detected, new state: on
2025-07-09 12:53:14,766 [power.py:_on_state_update()] - MQTT Power Device printer: External Power event detected, new state: off

[Arksine]

This is expected behavior. Only requests through Moonraker can trigger bound services as noted by the tip in the documentation.

[mvn23]

I see. Is there a reason for this limitation? #987 seems to aim at implementing this functionality for a workflow which seems common to me.

[Arksine]

Moonraker needs to receive the power request directly and check for transition to execute all post power actions. This provides an intention check with regard to post power actions, making the behavior well defined...ie: it isn't possible for these actions to run at unexpected times. #987 is similar but addresses a different switch type. The author of that PR can restart Klipper directly using the API or he can use Moonraker to control the switch. His PR may resolve the issue he's facing, but it could cause issues for others with post power actions running unexpectedly.

[Arksine]

Just wanted to provide an update as this issue is now closed. After further consideration I do think that it would be appropriate to add an option that allows users to "opt in" to the requested functionality, ie: trigger actions when changes are made externally. I am currently implementing a "polling" mechanism for devices that don't receive asynchronous updates and I intend to add this option as part of that work.