naugehyde - Little help! Is there any way to ge...
Little help! Is there any way to get a plugin's config (if it exists) during plugin load? I know how to get it during plugin.start but the readPluginOptions() function isn't a part of the app object until plugin.start().
11 Replies
i don't think there is. why would you need that?
hey Teppo. I have a plugin that on startup dynamically determines the JSON schema (using 'oneOf') based on communication with a resource (a Bluetooth device) that may not be available at runtime. When the plugin is disabled I can not determine the dynamic config without access to the plugin config which will have stored the various properties for the BT device in previous sessions. As a result when the plugin config is disabled and a configured BT device is unavailable, the config appears blank for that BT device. Not a good look. Not a disaster but it'd be nice not to freak out users with an apparently missing configuration.
A plugin.init() function with an app object complete with the various API functions that's invoked before plugin.start() might make sense for some plugins (certainly mine).
i think you are looking at it a little bit wrong
if the device is not going to be available at runtime how is it going to be available precisely when the server starts or is rebooted?
calling start (and stop-start sequence when the config changes) is tied to the plugin being enabled. if it is not enabled the plugin should do nothing
especially not access possibly exclusive resources
the user would expect the plugin to be totally passive when it is disabled
what i suggest you do is
- do everything when the plugin is enabled = after start is called
- accumulate and persist the data about available devices, if they are not going to be there always (persist under getDataDirPath)
Server API - Signal K Server Documentation
A Guide for users and developers.
yes, the user would need to first enable, then wait and and then reconfigure, but it is kind of unavoidable with the current setup
if the devices are not there 100% of the time that is always going to be the case, right?
Yes, it's true that with the current SK setup I can only reliably present configuration data when the plugin is enabled. That's kinda the problem. (Also: yes, I am persisting all the device data in the plugin data directory. )
While it's not unreasonable to expect a user to configure my (or any) plugin when it's disabled, it's definitely unreasonable to present a user with a partially blank configuration if the plugin happens to be disabled 1) it will appear that some of their configuration is lost and 2) in my case, if they wanted to make changes to a different device managed by the plugin, the schema check would fail for the missing device, preventing the submission of data for the other device.
Now while I have you, on a related issue, it's especially problematic for my plugin that changes to the JSON-schema do not automatically update the config page. As it stands, my plugin's users have to open and close the config page to refresh the view after I update the enums in the device dropdown list or make other schema changes upon device discovery. It's a bigger problem than the disabled config issue as it's not an edge case.
Aaaand... it's also a problem that on submit SK calls plugin.stop but does not wait for plugin.stop to finish before calling plugin.start. But I have an ugly hack in there to wait some arbitrary amount of time before plugin.start executes.
As for the disabled configuration issue, the only solution I can think of is to force the user to enable the plugin before configuring it. I'd do this by hiding the UI schema at both initial load and plugin.stop while putting up text that tells the user to enable the plugin to see the config and then unhide the UI schema at plugin.start. Not ideal but better than where it is right now.
i am not particularly fond of it, but have you noticed https://demo.signalk.io/documentation/develop/plugins/server_plugin.html?highlight=enabled%20by%20default#making-a-plugin-enabled-by-default
Plugins - Signal K Server Documentation
A Guide for users and developers.
PRs related to refreshing the schema are welcome - we could add the plugins' schemas to the data model and get updates over ws. But there are caveats: you would not want the schema to refresh when you have in flight edits
there's always the escape hatch of providing a custom configuration edit panel https://demo.signalk.io/documentation/develop/webapps.html?highlight=embeddable#embedded-components-and-admin-ui--server-interfaces, see https://github.com/SignalK/calibration
GitHub
GitHub - SignalK/calibration: Signal K Node Server plugin to alter ...
Signal K Node Server plugin to alter incoming data based on a set of calibration values - SignalK/calibration
WebApps - Signal K Server Documentation
A Guide for users and developers.
not waiting for plugin to stop we should fix - if plugin.stop returns a Promise we should wait for it and then call start. should be easy - please add an issue for this?
and I really appreciate the comms about these problems! I ~was young and needed the money~ just put something together when I started with the plugin APIs / lifecycle, so it is what it turned out to be
dude, it's a helluva good thing you've created with SK. always happy to help to make it a little better.
will do
totally agree. the refresh shouldn't be intrusive.
Happy to look into it. Any pointers on where the config panel code is located and where it might be documented?
Custom config panel is where my project needs to go-- probably won't be me that implements it tho. Up to my eyeballs in core plugin code as well as device code as it is. Hoping someday someone with a little more knowledge of react programming takes a stab at it.