[Abandoned Plugin] OctoPrint-PSUControl-Shelly #1417

Activity

1. starlord1980

   added

   abandoned plugin

   on Mar 9, 2026
2. github-actions

   added

   needs review

   on Mar 9, 2026
3. foosel

   added this to OctoPrint Backlogon Mar 9, 2026
4. github-project-automation

   moved this to Todo in OctoPrint Backlogon Mar 9, 2026
5. starlord1980

   changed the title [-][Abandoned Plugin] <insert name of plugin here>[/-] [+][Abandoned Plugin] psucontrol_shelly[/+] on Mar 9, 2026
6. starlord1980 commented on Mar 9, 2026

   

   starlord1980

   on Mar 9, 2026

   Last edited by starlord1980

   Author

   More actions

   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.
7. starlord1980

   changed the title [-][Abandoned Plugin] psucontrol_shelly[/-] [+][Abandoned Plugin] OctoPrint-PSUControl-Shelly[/+] on Mar 9, 2026
8. Triodes commented on Mar 15, 2026

   

   Triodes

   on Mar 15, 2026

   Last edited by Triodes

   Contributor

   More actions

   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

   👍React with 👍1Reacted by CyanAutomation
9. Triodes commented on Mar 15, 2026

   

   Triodes

   on Mar 15, 2026

   Last edited by Triodes

   Contributor

   More actions

   @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.
10. jneilliii commented on Mar 15, 2026

    

    jneilliii

    on Mar 15, 2026

    Contributor

    More actions

    @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.
11. jacopotediosi commented on Mar 15, 2026

    

    jacopotediosi

    on Mar 15, 2026

    Last edited by jacopotediosi

    Member

    More actions

    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

    👍React with 👍1Reacted by CyanAutomation
12. Triodes commented on Mar 16, 2026

    

    Triodes

    on Mar 16, 2026

    Last edited by Triodes

    Contributor

    More actions

    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?
13. jneilliii commented on Mar 17, 2026

    

    jneilliii

    on Mar 17, 2026

    Contributor

    More actions

    Thanks for adopting @Triodes.
14. jneilliii

    closed this as completedon Mar 17, 2026
15. github-project-automation

    moved this from Todo to Done in OctoPrint Backlogon Mar 17, 2026
16. jneilliii

    removed

    needs review

    on Mar 17, 2026
17. Triodes commented on Mar 17, 2026

    

    Triodes

    on Mar 17, 2026

    Contributor

    More actions

    @starlord1980 I should have fixed the problem you described in my latest version. So you can move to the version now maintained by me if you want 😊
18. starlord1980 commented on Mar 17, 2026

    

    starlord1980

    on Mar 17, 2026

    Author

    More actions

    Great, thank you I will test tonight and reply here.

    👍React with 👍1Reacted by Aron List
19. starlord1980 commented on Mar 17, 2026

    

    starlord1980

    on Mar 17, 2026

    Author

    More actions

    All working here! 👍

    👍React with 👍1Reacted by Aron List