[Abandoned Plugin] OctoPrint-PSUControl-Shelly

[starlord1980]

Which Plugin?

https://plugins.octoprint.org/plugins/psucontrol_shelly/

Link to ticket on plugin's issue tracker confirming abandonment

Its on the front page "This repository was archived by the owner on Feb 16, 2026. It is now read-only."

Is there someone open to adopting it?

Not that I know of, but I have some corrections in the code that need to be made as it currently doesnt work however found a way to fix it through a manual edit and manual install

[starlord1980]

I'm not a developer and have no interest in adopting it. Would just like others to have the benefit of the fix.
The plug will only turn on once and then not respond to any further commands... heres an AI description of the fix that works, but not for anyone else who might want to use this plugin unless someone updates it with these fixes:

---

The problem with the existing code was a logical deadlock caused by a safety mechanism called self.transition. This variable was designed to prevent the plugin from sending multiple commands at the same time, but it lacked a reliable "reset" trigger.

Here is the step-by-step breakdown of how the code was breaking:

1. The "Lock" is Set

When you clicked the button to turn the plug ON, the plugin ran the change_psu_state function.

• The code checked: "Are we already transitioning?" (if self.transition: return). Since it was the first time, the answer was "No."
• The code then set self.transition = True. This acted like a padlock, telling the plugin to ignore any future commands until the lock was removed.
• The command was sent to the Shelly, and the plug turned on.

2. The "Unlock" Mechanism is Missing

In the original code, the only way to set self.transition back to False (to remove the lock) was inside a different function called get_psu_state.

• get_psu_state is the function that asks the Shelly "Are you actually on right now?"
• The code assumed that OctoPrint would call this "Status Check" immediately after the "Turn On" command.

3. The Deadlock

If your main PSUControl settings were set to use "Internal" sensing (or no sensing at all), OctoPrint would never call get_psu_state.

• Because that function was never called, self.transition stayed True forever.
• The next time you tried to turn the plug OFF, the plugin checked the lock, saw it was still True, and simply logged: "Still in transition... not sending command."

Summary of the Fixes

To fix this, we made two key changes to the logic:

1. Immediate Reset: We told the code to set self.transition = False as soon as the command is successfully sent for local devices, rather than waiting for a status check.
2. Deadlock Override: We modified the check so that even if the transition flag is True, the code logs a warning but proceeds anyway. This ensures you never lose control of the hardware just because a software flag got stuck.

[Triodes]

I already have my own working fork which I use. If not too many issues and pr's come in I wouldn't mind maintaining this plugin

[Triodes]

@starlord1980 I noticed the plugin had some logic to disable the transition variable if the plugin was not used for sensing, but this logic was only used if you enabled Shelly Cloud. I moved the code block so it is now also used for local connection. This should fix the problem you described if you use local connection, but not this plugin for sensing.

[jneilliii]

@jacopotediosi did you have any concerns with the original plugin?

@Triodes if you look at former adoption pull requests here you'll see basically what needs updating. If you would like to take over maintenance submit one of those for this plugin and we'll review your fork and validate.

[jacopotediosi]

As always, thanks @jneilliii for involving me.

This plugin had already passed my security review in March 2025. As a precaution, I re-checked just now the current code at https://github.com/edekeijzer/OctoPrint-PSUControl-Shelly.

The only security consideration I have is to add some form of alert to suggest the user to use HTTPS instead of HTTP (if possible) for the server URL in the settings.

Since we are in the adoption process, I'll also take the opportunity to share some code quality recommendations:

• Use is instead of == for type comparisons here: https://github.com/edekeijzer/OctoPrint-PSUControl-Shelly/blob/243b5909a2ccfa3e2238258e56ab2fd6c464b3d9/octoprint_psucontrol_shelly/__init__.py#L42-L49
• I suggest implementing (and applying) a pre-commit hook for linting with ruff and djlint. An example pre-commit configuration for OctoPrint plugins can be found here: https://github.com/jacopotediosi/OctoPrint-Telegram/blob/master/.pre-commit-config.yaml

[Triodes]

The only security consideration I have is to add some form of alert to suggest the user to use HTTPS instead of HTTP (if possible) for the server URL in the settings.

Local control of Shelly devices can only be done over HTTP. But the Gen2 devices and higher use Digest authentication (instead of Basic) which I think is ok for the purpose of a smart switch. The password itself is never exposed this way and replay attacks are also prevented. If the device is controlled using Shelly Cloud then HTTPS is the only option since the Shelly servers don't do HTTP

I have very little experience with pre-commit hooks and the file you referenced seems to be a config file for python package hooking in on top of the basic git pre-commit hooks. I'm not sure if I have the time to learn all this new stuff...
Is that a requirement or can I take over the plug-in as is for now?

[jneilliii]

Thanks for adopting @Triodes.