This page describes how to setup and use properties Device Preferences | Developer Documentation | SmartThings but it doesn’t explain the traits of enum type. If I specify an enum type property and then try to access it via “device.preferences.myProperty” it returns the enum key not the value. How do I get the value?
Hi, @alex.49.98
It’s great having you back here in the Community!
Do you mean you want to get the label of the enum shown for the user?
You could configure something similar to:
- name: "selectIcon"
title: "select device icon"
required: false
preferenceType: enumeration
definition:
options:
"none" : "none"
"oven" : "oven"
"motionSensor" : "motionSensor"
"tv" : "tv"
"colorTemperature": "colorTemperature different range"
If this doesn’t help, could you provide more context on the use case you’re trying to build, please?
The idea of the enumeration preference type seems to be that the key is the unique identifier for the option and the value is the friendly label that is displayed in the mobile app, and which could be subject to translation. So when the user selects from the enumerated options the thing returned to the code is the key.
So for example in the Sonos driver the preference options have the keys Append, Insert, Insert_Next and Replace and it is those that they work with in the code. The values just make it look pretty in the mobile app.
3 Likes
I sort of agree with the idea behind, but the suggested approach doesn’t work. Even though my keys are now meaningful, like this
preferences:
- title: 'Type'
name: type
required: true
preferenceType: enumeration
definition:
options:
'passive': 'Passive'
'active': 'Active'
default: 'active'
when I try to get the property in the code
local type = device.preferences.type
the value is “key2”, not the expected “active”.
@nayelyz example shows a space on either side of the colon. You don’t have a space after the key. I think it should be:
'passive' : 'Passive'
'active' : 'Active'
Her example shows anything between 0 and 2 spaces… 
I’m too lazy now to try it, but device.preferences.type.value might work.
1 Like
Ah I see the issue now. I’m favouring something being broken as I can’t see anything wrong with what you are doing. Single and double quotes are generally unnecessary but valid, and spaces before the colon and more than one space after the colon in key/value pairs also so.
Indeed I am more suspicious of the extra indentation of the keys after name in Nayely’s example.
Why key2 anyway? That sounds manufactured.
1 Like
Hi,
Your preference is written fine and should work fine, but I think the name must be de index instead title
The problem may be that if you have changed something in the preference these changes are not updated automatically.
To force the changes to be updated in the preference you have to make a change in the text of description field, which your preference does not have:
description: “type”
example:
- name: "signalMetricsVisibles"
title: "Signal Metrics Visible in History"
description: "Signal Metrics Visible in App History (default: No Visible):"
required: false
preferenceType: enumeration
definition:
options:
"Yes" : "Signal Metrics Visible"
"No": "Signal Metrics No Visible"
default: "No"
Sorry I got that example from an old driver that I knew worked, I remember it’s a copy from someone’s profile to test an issue so those indentations are not meaningful I think. I’ll test it again just to make sure.
The issue may be due to what @Mariano_Colmenarejo says.
@alex.49.98, if you never configured an enum called “key2”. Then, we need your profile ID (seen in the device’s details) to check its configuration known by the platform.
In the initial post I referred to the documentation page Device Preferences | Developer Documentation | SmartThings. On that page title goes above name like
preferences:
- title: "IP Address"
name: ipAddress
description: "IP address of the Pi-Hole"
required: true
preferenceType: string
definition:
minLength: 7
maxLength: 15
stringType: text
default: localhost
that’s why I did it this way.
Then, regarding the keys the example from that page is this
{
"title": "string",
"description": "string",
"required": "boolean",
"preferenceType": "enumeration",
"definition": {
"options": {
"key1": "string",
"key2": "string"
},
"default": "string"
}
}
so, I assumed that keys must be named key1…keyN. Then I saw posts that people using different key names, I tried that but no matter what I tried the keys are still key1, key2, … as if they cannot be customized. I guess I’m missing something if the keys customization works for others.
Also, besides the key names the preferences page for the driver works fine.
Since it’s an enumeration, most drivers work with numbers:
preferences:
- name: "systemModes"
title: "System Modes"
description: "Select the modes the thermostat has been configured for, as displayed on the thermostat"
required: true
preferenceType: enumeration
definition:
options:
1: "off, heat"
2: "off, cool"
3: "off, heat, cool"
4: "off, auto, heat, cool"
5: "off, emergency heat, heat, cool"
default: "3"
I think I found a good example, because it’s a bit more complex:
Profile:
init.lua:
See what they are doing in info_changed()?
Are you sure your workflow is correct? You have to package, (assign and) install the driver after you’ve made a change. If you have multiple drivers assigned to a channel, it can get a bit confusing, so pay attention to the driver IDs. And it doesn’t hurt to delete and add the device in some cases.
I don’t understand. No matter what I do, it is still “key2”. I package, assign and install. I know the installation is successful. I see behavior changes in accordance with my code change. I see new enum items in the preferences if I add them. Everything changes expectedly except the keys of that enum. Are you sure I don’t need to declare that enum with the keys somewhere else?
Do you still get the ‘key1’ / ‘key2’ if you change the name of the preference, or create a profile with a new name in the Edge driver and use that?
As @nayelyz says, it would be good to monitor the profileId in the device object to see what the system thinks it is working with. It is a device profile in the /deviceprofiles endpoint of the API that should get used so the preference needs to look right there.
Unfortunately the AWA doesn’t seem to show that but it can be seen via the CLI or directly accessing the API. I think it may also be device.profile.id in the Edge driver.
I still don’t understand why it behaves so weird, but the key names suddenly changed now. I don’t know what exactly made that happen, I did many changes at once. I changed code, added infoChanged handler, I removed extra enum items that I previously added for testing purposes, I did some refactoring and cleaning and after another driver install it worked.
Even if you have no idea why it worked, using a hello, please and thank you, I think, will help you a lot more in this forum and in this life dominated by the current ultra-liberal egoists, who continually bombard us with me first, me later, and whoever has problems is because they don’t try hard enough and deserve it.
I’m sorry, it’s not personal to you, it’s just that I seem to see it more and more frequently in this forum and unfortunately in today’s society and I couldn’t contain this reflection
Regards
1 Like
Anyone trying to contribute something by developing a driver should not be classified as an egoist.
English is not my native language and I may not have expressed myself correctly or perhaps you may not have understood correctly since I believe that it is not your native language either.
I have not called anyone in this forum egoist, I was referring to the defenders of the ultra-liberal ideology, increasingly dominant in today’s society, which lacks historical memory.
