I’ve been having fun with dynamicPage preference pages in SmartApps and noticed as a result of dynamicPages, you can end up with settings that aren’t being used anymore, but never go through the process of having the user click on the input, and clear it out. So I’ve been messing around with a setting engine to detect settings with dependencies (ie has device id in setting name, but device setting was changed and that device is no longer being used). If it detects a phantom setting it will remove it. I’ve noticed I can use the minus operator or remove the key name to have an affect on the settings object for the instance the script is being run, but the next time it runs it has the original settings again. I’m assuming there’s a wrapper around settings to protect them or something, so wondering if anyone’s successfully persist the removing of settings programatically.
I’m curious as to how to do this. My reading docs says settings.xxx are readonly.
Good to know, didn’t see that line in the docs.
Anyone know if there is a limit to the size of the settings like there is for states? Does this even matter? Still, seems messy to leave phantom settings around.
Obviously a work around would be to uninstall the app, and reinstall fresh. But that’s not very user friendly if you’re dealing with a remote control for instance where you have a lot of buttons and actions, devices, etc to store data about.
Ideally the Community should develop a good way to export & import “
settings” … but since settings are read only, you’d have to copy them to
state for use internally; and couldn’t display them for editing… blah blah!
SmartRules (by @obycode) is a good example of a SmartApp that is mostly configured entirely outside of SmartThings (via an iOS App / GUI). Then you don’t have to deal with many of the limitations of
True, but I feel it wouldn’t be hard to implement a good settings standard and better engine for managing it if SmartThings were interested in working with us. Does that kind of thing happen?
Settings configuration section for defining a template to use for your smartapp’s structure (ie, create a map base, device -> capability -> attribute, standard text setting, etc). Define the entityType your input is to store the setting name as.
Or even simpler, create a dependency argument to the input method, and it can check if that dependency exists, and if not, remove it.
Then the engine can handle cleanup automatically on install/updates after changes in the preferences page(s).
Not in known history. These type of discussions end up just being pedantic, wouldn’t it be nice if…
They have other priorities, and our ideas don’t make the list generally speaking.
And before our Dev Advocates disagree, be aware that I have dozens of examples of our recommendations ignored, including the recent debacle of zero discussion with the Community of proposed new Capability Types suggested by us 1 year ago.