Updating mesh from printer clears all custom system actions defined in config.yaml
Opened this issue · 32 comments
When the "Update mesh now" button is clicked, it clears all custom actions under the system section of config.yaml after updating the mesh.
Steps to reproduce:
- Click "Update mesh now".
- Refresh OctoPrint's UI.
- Check config.yaml see any custom actions defined under the system section disappear. Instead you see system: {}.
Octoprint version: 1.4.0
BedLevelVisualizer version: 0.1.13 (latest)
Can you provide an example custom system command you had configured? Also, are you using a plugin to set those or manually adding in config.yaml?
I have tried using the System Command Editor (https://plugins.octoprint.org/plugins/systemcommandeditor/) and tried editing config.yaml manually to create two actions. Both times, updating the mesh clears the custom actions. The actions are:
system:
actions:
- action: poweron
command: gpio -1 write 16 1
confirm: false
name: Power on printer
- action: poweroff
command: gpio -1 write 16 0
confirm: This will turn off the connected 3D printer.
name: Power off printer
I use these actions to turn my 3d printer on and off using the telegram bot and as an alternative to PSU Control from the Power menu in Octoprint.
Ignore the incorrect indentation. I can't seem to get it right.
Thanks, I'll do some testing on my end and try to find out what's going on. No worries on the formatting, I fixed it up for you.
This appears to be an issue reported a while back on the System Command Editor plugin's repo over here with other user's reporting the same thing. The last couple of reports are from user's that were seeing it with Bed Visualizer. Does it also happen if you disable System Command Editor completely and manually update the system commands?
My troubleshooting steps involved the following:
- Both Bed Visualizer and System Command Editor installed.
- Custom system commands defined.
- Updated mesh.
- Lost custom system commands.
- Re-defined custom system commands using System Command Editor.
- Updated mesh.
- Lost custom system commands.
- Uninstalled System Command Editor.
- Restarted OctoPrint.
- SSH'd into OctoPrint and defined custom system actions in config.yaml.
- Updated mesh.
- Lost custom system actions.
- Uninstalled BedVisualizer.
- Restarted OctoPrint.
- Confirmed custom system actions persist across server restarts and reboots.
I hope this makes sense.
Ok, just did some testing on my development machine and the commands don't appear to be deleting falling these steps.
- Uninstall System Command Editor
- SSH to the Pi
- Run command
sudo service octoprint stop - update config.yaml with your commands. For my testing since I'm on windows I modified to open notepad and calc for the two commands.
system:
actions:
- action: poweron
command: notepad.exe
confirm: false
name: Power on printer
- action: poweroff
command: calc.exe
confirm: This will turn off the connected 3D printer.
name: Power off printer
- run command:
sudo service octoprint start - Open web page, update mesh: no changes to system commands
- restart OctoPrint: no changes to system commands
- Update mesh: no changes to system commands
I'm about to test on a pi to verify these steps on it as well, but wanted to give you my initial findings.
So several tests with the above steps seem to work for me. The system commands stick no matter how many times I restart OctoPrint or run Update Mesh, etc. I have not been able to reproduce this issue.
Thanks for taking the time to investigate this. I will run some tests again and come back to you.
This is very strange. The troubleshooting steps I performed above definitely confirmed the issue, but now I have reinstalled Bed Level Visualizer and System Command Editor and tried them again and the issue is gone. This is so strange. I'm going to try a couple more things and get back to you. Thank you.
I have reinstalled Bed Level Visualizer and System Command Editor, but I didn't use the latter to define custom actions. My custom actions were defined manually in config.yaml. I tried updating the mesh several times and it didn't clear my custom actions. This morning, I turned my printer on using PSU Control and clicked connect in OctoPrint. Once connected to the printer, I clicked Update Mesh Now and it immediately cleared my custom actions.
I don't think it happens every time, but it happens under specific conditions. Would there be some place where I can look at logs or send them to you to investigate?
Logs probably won't help in this case if the issue isn't consistently reproducible. Does it do it every time with psu control process?
No, it doesn't. I turn my printer on and off heaps of times and it doesn't clear the custom actions ever. This time I turned the printer on, clicked Connect and waited for the Update Mesh Now button to be enabled. Once it was enabled, I clicked on it, and silently my custom actions vanished.
Any progress on this issue? Do you need me to do any further troubleshooting?
Nothing yet. I still haven't been able to reproduce, but have been trying.
Today I had a very similar problem. I do not think that it requires a separate issue topic. Rather, it is an idea of possible causes ...
I have been using the "Custom Control Editor" plugin (v.0.2.2) for a very long time. Later, "Bed Visualizer" was added, and later, "Terminal Commands Extended". All this without problems was jointly operated on OctoPrint 1.3 and 1.4.
Yesterday I performed a Raspberry software update ("apt-get update" + "apt-get upgrade"). And today I got a problem - right after building the mesh ("Update Mesh Now"), the Custom Controls buttons disappeared from the "Controls" tab - the corresponding section was deleted in the "config.yaml" file.
The plugin "Custom Control Editor" continued to work - with its help it was possible to create buttons and sections for "Custom Controls", they were saved, and displayed normally after restarting OctoPrint. But they disappeared after building the mesh ("Update Mesh Now") - the section was also deleted.
After disabling the "Custom Control Editor" plugin, the problem ceased to appear. For verification, I turned on this plugin again - and the problem resumed.
Besides the Raspberry update ("apt-get update" + "apt-get upgrade"), I haven’t done any changes / updates for three weeks now. During this time, I printed a lot, and each time before printing I did the construction of the grid. There were no problems.
By the way, the "Python 3 Check (0.1.3)" plugin reports that "Custom Control Editor v.0.2.2" is not compatible with python v.3.6
Thank you, @EagleB3. I hope this can help @jneilliii get to the bottom of this.
@Salandora has actually identified an issue with the Custom Control Editor and System Control Editor plugins that is causing this issue and is currently working on rewriting them both. I still recommend Setting up your system controls/custom controls using his plugins and then saving, and then disable both immediately after.
@DuDecancoDe there's a prerelease version of system commands that might fix the problem for you. Salandora/OctoPrint-SystemCommandEditor#5 (comment)
Warning, that system commands editor version is very buggy...he's working on it.
Thanks, @jneilliii. I appreciate you looking into this for me. Your plugins is pretty awesome and I use it often.
Yeah, again the issue is in the other plugin and how it loads/saves settings. I supplied a fix to the other plugin or you can setup all your buttons and then disable the custom control plugin. It's not required to be loaded to be able to function, it just needs to be loaded to make it easier to setup your buttons.
@jneilliii , Many thanks!
Just because of my poor knowledge of English, I did not understand one aspect. You wrote: "I supplied a fix to the other plugin" - you sent a variant of possible corrections to the author of the plugin (Salandora ?), and now we are waiting for him to fix his plugins?
And, taking this opportunity, I want to ask: did the buttons made to you (in plugins "Bed Level Visualizer" and "Terminal Commands Extended") support the execution of external script files (* .gco)? I am referring to an analog of the opportunity provided by config.yaml, for example:
- confirm: 'Find table by probe in CURRENT nozzle position?'
name: Find table
script: custom / FindTable.gco
you sent a variant of possible corrections to the author of the plugin (Salandora ?)
Yes, that is correct. I don't know if he's even considered the merge because I know he plans on re-writing the whole plugin though. The pull request is here and the related issue is here.
support the execution of external script files
No they do not, just the ability to send configured GCODE commands.
@jneilliii , Many thanks!
No problem. If you want to install my patched Custom Control you can do so by installing it using this URL in plugin manager and it should resolve the issue, if Salandora doesn't get around to merging the change for a while. The only thing you won't be able to do is delete all the custom controls.
https://github.com/jneilliii/octoprint-customControl/archive/devel.zip
@jneilliii ,
I installed the plugin from your archive and performed the first checks (edited congig.yaml, saved the results, built a bed table, saved the results. Control panel settings did not change and did not disappear. After octoprint reloaded, the Control panel settings also did not change and did not disappear.
P.S. The buttons you made in your plugins are much more convenient than the "standard" buttons. The standard buttons really lack pop-up hints ...
P.P.S. Thank you, thank you very much!
Hello, Is there a way to get back Custom Control commands after hitting bed mesh update? I lost everything. I looked at config.backup but nothing. Thank you
Not that I know of
@yvessa , I'm afraid that nothing. Some time ago, the "Custom Control commands" plugin stopped correctly creating a backup copy of the "config.yaml" file before saving the edited file. issue
It’s a good idea to periodically back up the entire Raspberry SD card image, or at least the Octoprint directory.
Yep lesson learned today :) I had a pretty long custom commands list... Thanks
That really sucks @yvessa, sorry that happened. Yeah the new backup restore option in settings is definitely a benefit in those situations. Especially without including files/timelapses for speed. Would be beneficial to have that possibly on a schedule. Maybe a good plugin idea. Might even be possible via CLI cron jobs, but I'd have to check.
closing since issue is not with this plugin, but other plugin.