@nayelyz When preferences that are required:false, default:null are changed, the value is not saved and the infoChanged lifecycle handler is not called. I’ve tried with both explicit and embedded preferences to the same effect. After changing one of these preferences, changes to any other preference do not trigger the infoChanged lifecycle handler until the settings menu is exited and re-entered.
The simplest example is a driver using the two stock explicit preferences below. The tempOffset preference has a default value of 0 and properly triggers the infoChanged lifecycle. However, if the password preference, which has a null default, is changed it does not trigger the infoChanged lifecycle and renders the tempOffset preference non-functional until the settings screen is exited and reentered.
@nayelyz I’m trying to set up explicit preferences that I’ll be reusing, but it seems like updates after they’re first created aren’t taking effect. In my most exhaustive testing run I went through the following steps in the CLI:
Create preference.
Package and install driver. Create device.
Delete device. Uninstall, unassign, and delete driver.
Update preference.
Package and install driver. Create device.
The preference shown on the device after step 2 remains the same on the device at step 5. Is that expected behavior? The package and profile names were the same between the two installs, but both the driver and the device had different IDs. I saw in the developer docs where the profile will keep the same explicit preference version as when it was first created, but I would expect a fresh package/install of the driver to circumvent that.
Hi!
I will check this with the engineering team. In the meantime, you can check if changing the device profile’s name (and the references to it) before packaging the driver again helps with the update.
Please, allow me some time to check the issue of the first post.
Thanks for looking into these! Some other feedback on setting up explicit preferences using the CLI:
I found the terminology for enumeration options in the interview of smartthings devicepreferences:create to be confusing. I repeatedly ran into the error below until I realized that the key noted in the error was the name in the interview and not the value. I would recommend that the interview be changed to ask for the key and value for each enumeration option, or perhaps key and description.
? Preference name: pe653BoosterPump
? Preference title: Booster/Cleaner Pump Configuration
? Preference description: Booster/cleaner pump configuration
? Is the preference required? Yes
? Choose a type for your preference. enumeration
? Enter a name for the first option. No
? Enter a value for the first option. 1
? Enter a name for the next option or press enter to continue. Uses Circuit 1
? Enter a value for the option. 2
? Enter a name for the next option or press enter to continue.
? Choose a default value. 1 (No)
Error: Request failed with status code 422: {"requestId":"0334205E-1505-4E9A-8849-4B8FB110D979","error":{"code":"ConstraintViolationError","message":"The request is
malformed.","details":[{"code":"PatternError","target":"definition.options.key","message":"definition.options.key does not match the pattern ^\\w+$.","details":[]}]}}
Following up, I checked there’s a strange behavior with capabilities that have a value null in the default property, I suggest that you omit the property if you don’t want to assign a default value.
About this tool, I completely agree it’s confusing, I will report it to the engineering team.
I had deleted that test device, but have recreated and will send. I had some additional trouble this time around, since I also tried to add a preference of type integer with the default property omitted. When I did that, the entire settings menu failed to appear as an option for that device.