Behavior of required preferences (enum) and defaults IDE vs app

I noticed if that if I set up a preference with an enum data type, make it required, and provide an options list; in the IDE, the first option in the list is automatically entered as a default value. This is good, I thought. I was looking for a way to have a default value that was automatically entered that wouldn’t require user action . . . then I stumbled on this behavior. So I just ordered the options list such that the first item was the default value. In the IDE, this works and you don’t have to select a value since the first item on the list is already selected.

HOWEVER, in the app (Android), this is not the case. No value is selected automatically and the user does have to go in and make a selection. So, I would suggest one of 2 things:

  1. make the app behave like the IDE and automatically select the first item of the options list thus not requiring a selection if the default is OK, or

  2. have a way to define a default value from the options:[] list in a required preference enum input. I used the time honored trial and error method to see if this is already there with no success. Not 100% sure but I tried a few things like adding:
    , default: ["5"]
    Maybe this functionality is there and I just didn’t find it.

1 Like

Yes, it is.

defaultValue: "5",
1 Like

I’ve tried defaultValue: “squat”, for me it still wasn’t selected in the preferences on an android, nor instantiated in the code to the default value.

Works for me. I’m on iOS though.

Bingo! @geko, this worked for me in the app (Android). IDE is still taking the first item on the list (in one list, I made the default value NOT the first value). A bug in the IDE, I guess. Thanks for the quick response!

I noticed @Mike_Maxwell is not having success with this. I can verify the selection of the default value but I cannot verify the instantiation in the code (I can tonight, if I have time) although I don’t know how or why it could/would be correctly selecting but not passing the value into the variable properly.

Here is an actual code line that seems to be working for me:

input "DelayMinStr", "enum", title: "Bright time, minutes", required: true, 
        	options: ["1","3","5","10","15","30","60"], defaultValue: "5"

@AaronZON you’re getting preference selections in the IDE?
This is my typical preference section, and I’ve never gotten these to show in the IDE…

preferences {
       	input name: "param80", type: "enum", title: "State change notice:", description: "Type", required: true, options:["Off","Hail","Report"]
        input name: "param120", type: "enum", title: "Set trigger mode:", description: "Switch type", required: true, options:["Momentary","Toggle","Three Way"]
        input name: "blinker", type: "enum", title: "Set blinker mode:", description: "Blinker type", required: false, options:["Blink","Flasher","Strobe"]
    }

@Mike_Maxwell I added the line with ‘section’ to a dummy app:

preferences {
	section("Title") {
       	input name: "param80", type: "enum", title: "State change notice:", description: "Type", required: true, options:["Off","Hail","Report"]
        input name: "param120", type: "enum", title: "Set trigger mode:", description: "Switch type", required: true, options:["Momentary","Toggle","Three Way"]
        input name: "blinker", type: "enum", title: "Set blinker mode:", description: "Blinker type", required: false, options:["Blink","Flasher","Strobe"]
    }
} 

Save. Select location. and I get this:

The section on the right is what I’m calling ‘preferences in the IDE’. Are you not getting this? When I tried to save without adding the ‘section’ line, I got an error.

Thanks for that @AaronZON , I get no error without that line, but that indeed that was the issue, been bugging me for weeks, just assumed it was a “feature”…

That’s really strange, @Mike_Maxwell. You would think that error is being generated on the backend which should be the same for me as it is for you. . . .

@Ben - Do you think someone in ST should look at this? If it helps to know, I am running W7 and Chrome. Not sure about Mike.

well I spoke too early, your code works, however it doesn’t work when you include a metadata tag thus:

metadata {
definition (name: “aeonDimmer”, author: “Mike Maxwell”)
capability “Switch Level”
capability “Actuator”
capability “Switch”
capability “Sensor”
capability “Alarm”
capability “Polling”
capability “Refresh”
command “levelUp”
command “levelDown”
//aeon S2 dimmer (DSCxxxx-ZWUS)
fingerprint deviceId: “0x1104”, inClusters: “0x26,0x27,0x2C,0x2B,0x70,0x85,0x72,0x86,0xEF,0x82”
}
preferences {
section(“opts”) {
input name: “param80”, type: “enum”, title: “Set change notice:”, description: “Type”, required: true, options:[“Off”,“Hail”,“Report”]
input name: “param120”, type: “enum”, title: “Set trigger mode:”, description: “Switch type”, required: true, options:[“Momentary”,“Toggle”,“Three Way”]
input name: “blinker”, type: “enum”, title: “Set blinker mode:”, description: “Blinker type”, required: false, options:[“Blink”,“Flasher”]
input name: “dInterval”, type: “enum”, title: “Set dimmer button offset:”, description: “Value per click”, required: false, options:[“1”,“5”,“10”]
}
}

Can’t work out the syntax to include the metadata and get the pref to work, i like the metadata as you can define commands and attributes right in the code…

Can’t help you there, I’m afraid. Well beyond what I know. Hopefully someone else is watching and can help.

@AaronZON’s example is a smart app, while you’re writing a device type. Unfortunately, device input options are very limited (or broken, if you prefer.)

That explains it, didn’t realize he was writing an app…
Sorry to get everyone all spun up, i got excited there for a bit…
Maybe I’m being a bit optimistic by trying to include device specific options in the device, vs dinking with them in a smart app…

Ha! That shows you what a newb I am! It should have been obvious that Mike was talking about a Device Type Handler. Sorry.

Anyway, so the problem of not knowing how to define a default in a SmartApp preferences input statement is solved and I have verified. Thanks!

What is still open is the difference in behavior between the IDE environment and the actual mobile app. I suppose I will just consider it reported and move on.

1 Like

Thanks for sharing this question and discussion. I was trying to figure out how to use type "enum" for parameters in a SmartApp, but the example had these odd meta:[values[]] elements instead of options:[], so I was getting inconsistent behavior (the “meta” format worked on Android, but not on iOS).

So you indirectly helped me out with a loosely related problem. Thank-you!

1 Like