Issue with Octoprint Settings Dialog

[ScottWell1]

When PlotlyTempGraph is enabled, opening the Octoprint Settings dialog (i.e., by clicking the "wrench" in header) brings up the Octoprint Settings dialog, but the dialog's Close and Save buttons do not work. This prevents making any settings to the native Octoprint Settings, as the SAVE button does not function. The Close button is non-responsive, but the dialog can be closed using the X at top-right corner. The SAVE button is non-responsive and displays the rotating "busy" symbol in front of the word "Save".

If I disable PlotlyTempGraph and restart Octoprint, the problem is gone and the Octoprint Settings dialog (both Close and Save buttons) work as expected. If I again enable PlotlyTempGraph and restart Octorprint, the problem returns.

I am using PlotlyTempGraph 0.1.5 and Octoprint 1.9.2.

Could this be related to the settings/template change in 0.1.5? Maybe a problem with settings retrieval by the addon? In case it is relevant, I added a manual edit to config.yaml with 0.1.5, creating a custom hover template for the identifier "Exhaust actual". That works fine (it is displayed correctly on chart), but perhaps there is some syntactical issue? Replacing that custom template with the default (two single quotes) does not resolve the issue.

The "Exhaust actual" identifier comes from a customized version of the "PlotlyTempGraph_SystemCmds.py" addon in your examples section. Disabling or uninstalling that addon does not resolve the issue.

Any ideas?

Here are all my PlotlyTempGraph settings from config.yaml:

  plotlytempgraph:
    _config_version: 5
    name_map:
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: tool0 actual
      label: tool0 actual
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: tool0 target
      label: tool0 target
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: bed actual
      label: bed actual
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: bed target
      label: bed target
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: chamber actual
      label: chamber actual
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: chamber target
      label: chamber target
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: X actual
      label: Heat Break
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: true
      hover_color: ''
      hover_template: ''
      identifier: X target
      label: ''
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: A actual
      label: Buddy PCB
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: true
      hover_color: ''
      hover_template: ''
      identifier: A target
      label: ''
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: ''
      identifier: Enclosure actual
      label: Enclosure
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      hover_template: <b>%{y:.0f}%</b>
      identifier: Exhaust actual
      label: Exhaust Fan
      use_fahrenheit: false
      use_sub_plot: false
    - color: ''
      hidden: false
      hover_color: ''
      identifier: W actual
      label: ''
      use_fahrenheit: false
      use_sub_plot: false

[jneilliii]

Looking at your developer tools in the browser (preferably chrome) would help to see if it's settings change issue or not. Sometime else reported this in discord, but after disabling the plugin and trying to figure out if another plugin was conflicting, after all plugins were revealed it still worked.

[thomas82kj]

I have seen the same behavior with the close and save button. I believe that it happens after fiddling with the settings of which values to show. I have made it go away several times by clearing the data of the plotlytempgraph plugin. (eraser icon in plugin manager)

[jneilliii]

If you can figure out specific, reproducible steps that would help drastically.

[ScottWell1]

I had the problem once before -- when testing PlotlyTempGraph 0.1.5RC. At that time, deleting all settings and starting over (and ostensibly putting all settings back as they were) eliminated the issue. But now it's back.

This error shows up in browser console and sounds related, but I have no idea what it means.

I also noticed that in the last block of my settings (posted above in earlier message), there is no "hover_template" defined for the "W_actual" identifier. Could that be related?

[ScottWell1]

I manually added a hover_template: '' to the last block of settings, where it was missing, and restarted Octoprint. That resolved the issue with the Octoprint Settings dialog.

So, the question is, why didn't that identifier's settings have a hover_template defined? Maybe not reliably created during initialization, or somehow getting deleted later?

[jneilliii]

Yeah, the settings migration appears to be broken based on comment in https://github.com/jneilliii/OctoPrint-PlotlyTempGraph/issues/50. That's why this occurred during upgrade process I think and broke the settings window. You're fix is what that settings migration process should have done for you.

[jneilliii]

I believe I've fixed this in the latest 0.1.6 update. Please verify your saving issue is still resolved after this update.

[ScottWell1]

I reverted my manual change (removed the hover_template: '' line) to bring the problem back.

Then I updated to 0.1.6. That did not correct the problem. Should it have?

I again manually added the hover_template: '' line, and all is good with 0.1.6 (as it was with 0.1.5 after the manual fix).

[jneilliii]

you would have also had to revert the _config_version setting to 4.

[jneilliii]

I just released version 0.1.7 with fix for the other issue, so you might want to force check for updates in plugin manager to get the latest version too.

[ScottWell1]

With 0.1.6 installed... I reverted the manual change again (removed the hover_template: '' line) AND changed the config_version to 4, then restarted Octoprint. Upon restart, 0.1.6 added the missing hover_template: '' line and incremented config_version to 5 as expected. The Settings dialog works fine.

The only collateral damage was that the custom hover_template: <b>%{y:.0f}%</b> I had on another identifier was replaced with the default (empty) template. That seems unexpected.

I added back the custom hover_template: <b>%{y:.0f}%</b> and restarted again (still with 0.1.6). The identifier was shown correctly with the custom formatting on the chart, and the Settings Dialog still worked correctly.

Next, I did a force update, grabbed 0.1.7, and restarted again. All still good: The Settings Dialog is still working, and the custom hover_template is still working.

So, the only anomaly was losing the custom_template on an identifier when 0.1.6 migrated from v4 to v5 (while it simultaneously fixed the missing custom_template on another identifier). I may be the only person using custom_template, and presumably that's a one-time migration issue, so not a big deal.

In any case, my Settings Dialog is working -- so I am happy. Thanks for looking into it!!

[jneilliii]

So, the only anomaly was losing the custom_template on an identifier when 0.1.6 migrated from v4 to v5 (while it simultaneously fixed the missing custom_template on another identifier).

Yeah, I could see that being the case. The settings migration would only truly handle the case properly when those fields didn't exist from the prior version that didn't have the hover_template option at all.

At least we were able to work it all out and led to helping in fixing the other issue as well I hope.