PSU Control plugin does not retain settings

Hi, on update the PSU control plugin loses the settings needed to control the GPIO. Its happened on the past two updates. I didn't see a way to start an issue or bug on GitHub, so if the developer is here, just let me know how to proceed to help you.

Use the search bar. Come on, it's not hard.

1 Like

I'm not asking for help fixing the problem. It would be nice to report the bug. The developer's page points here. If it caused me issues, I know it will cause others issues.

1 Like

It points here:

There is no way to create issues for the developer to know about. I don't have time to create a pull request and work on it. I only wanted the developer to know about the issue so he could potentially save other uses headache. I pulled everything apart before I realized my settings disappeared on the update.

It looks like https://feathub.com/kantlivelong/OctoPrint-PSUControl is the right place to go. I didn't realize it was a link on the page. Thank you for the help.

Hey, it was not me trying to get you help, it was me trying to tell you to find the solution yourself, using the search bar.

There is already multiple posts about this, including even a fix provided by the plugin author. For your convenience (since the searchbar doesn't seem to have worked) I will link them all here for you:

https://community.octoprint.org/search?q=PSU%20control%20settings

1 Like

You helped me find his feature suggestion page. That was a great help. If it happened with the update today, it must still be an issue. I totally understand developers being busy. Getting it documented always helps. Its really a tiny issue, but I'm sure other people will stumble with it. I hope to help them. Have a great day.

@cbusillo I keep my issue tracker closed because the majority of reported issues tend to be user error or flat out support requests.

I understand. Just to reiterate, I ran the update for the plugin on octoprint today. It removed the setting referenced above. I saw a mention of a fix five days ago, but this has happened since. If I can be of any assistance just let me know. Its just a tiny thing and isn't a big deal for me, now that I know to check on updates.

BTW, I love the plugin and it works perfectly.

Enable debug logging for psucontrol, restart octoprint, and pastebin the log.

To be clear, the plug in works fine every time after changing that value once after an update.

octoprint.plugins.psucontrol did not create a log. I added the DEBUG level logging and restarted, but no log appeared. I have attached the pastebin for the plugin update log. If I can do anything else to help just let me know.

Everything gets logged into the octoprint.log, unless it tells you it is somewhere else. There's no different logs for plugins, all in the one file.

unless the plugin tells the logger to do so. I keep separate logs for my plugins to only look at what's being logged by it directly.

That's what I meant, but I think there might have been a word or two missing...

Here ya go. I included as far back as I could with pastebin's 512k limit.

My fault. I opened the octoprint.log and searched for psu. I must have mistyped it.

Thanks. Which setting appears to reset in the UI? Have you cleared your cache or tried incognito/private mode?

Before the upgrade "Switching Method" is set to "GPIO Pin". After the last two upgrades the "Switching Method" changes to "G-Code Command"

The plugin does not work at this point. I thought I had a bad relay and pulled my control box apart.

Once I change the setting back to "GPIO Pin", everything works perfectly. No need to clear cache or change browsers. It just looks like the upgrade overwrites that setting some how.

According to the logs switchingMethod is set to GPIO on startup. The recent (0.1.10) update fixes an issue where another option would get selected if GPIO was used for either switching or sensing. So far I am unable to recreate your issue after that version. That is why I asked if you tried in a incognito/private window as the js side could be cached still. It's also possible that the compressed js cache is stale but I'd lean more towards browser cache right now assuming there isn't some other weird edge case.

1 Like