naugehyde - API question (for @Teppo Kurki ? @S...
API question (for @Teppo Kurki ? @Scott Bender ?): How does a plugin developer save the "enabled" = true key for a plugin's json? ServerAPI::savePluginOptions only saves the configuration not the plugins enabled and debug state.
This becomes a problem when a plugin manages its own configuration state in a custom panel AND is enabled by default.
Under such circumstances, the configuration is never properly enabled (even though its enabled by default) and therefore every time the user restarts, the configuration the plugin gets on startup appears empty. (See interfaces/plugins.ts:576) I realize this is an edge case but in the case of my bluetooth plugin, I can't find a non-hacky way to ensure that the enabled state is stored in the plugin json. There are only awkward and counter-intuitive end user workarounds (saving the config then disabling/re-enabling or turning debug on and off). Thanks for any help.
Under such circumstances, the configuration is never properly enabled (even though its enabled by default) and therefore every time the user restarts, the configuration the plugin gets on startup appears empty. (See interfaces/plugins.ts:576) I realize this is an edge case but in the case of my bluetooth plugin, I can't find a non-hacky way to ensure that the enabled state is stored in the plugin json. There are only awkward and counter-intuitive end user workarounds (saving the config then disabling/re-enabling or turning debug on and off). Thanks for any help.
5 Replies
sounds like a bug, if it is enabled by default, then it should stay enabled?
The plugin is enabled by default but the enabled state never gets written into the config unless you work around as noted. savePluginOptions which is all I have at my disposal doesn't write the enabled state.
The problem results in users not seeing their configuration after restarting (not great) because although the config is on the disk the
enabled: true key is never set and SK thinks the plugin hasn't been configured and initialized.Yeah, I think k there’s a pretty simple fix for this
Can you open an issue for the server?
There is a hack you can do to fix it now
You can just write the whole file instead of calling savePluginOptions
the idea originally was that the server manages the plugin's enabled/disabled state, but the enabled by default kind of broke that, but that logically works only for plugins that don't need configuration
why do want it enabled by default? to get discovery started?
I honestly don't remember why. It wasn't to get discovery started though having devices show up without user input is pretty neat.
To your first point, 99% of the time the bluetooth plugin shouldn't need user input to get started showing devices.
I'm aware that there are other ways to architect the plugin so it's not enabled by default. Just not going to pursue rewriting it in the short term in the interest of stability.
Done! https://github.com/SignalK/signalk-server/issues/2040