[Solved] Issue with enum inputs not showing current values

[Darrren]

Okay, so I'm having a hard time getting enum inputs to work properly.

If I set an enum input using its dropdown list then it works as expected, but when I use device.updateSetting() then the new value I set is present in the settings map, but it's not displayed in the gui after refreshing the page. I am able to set other input types just fine, like number, string, bool. What the heck am I missing here? I'm running on v2.2.8.152.

Here's a test driver that I'm using with a virtual device for testing. When the device page is first loaded, all inputs should show the default of "1", and the boolean input is enabled. Click Configure which will set all inputs to a value of "5", and the boolean to false, then refresh the page. What I'm seeing is that only the enum inputs don't show the set value, and instead they all show the default value of 1. The settings map shows all of the correct values, which you can see if you click Refresh.

If you manually select a value of say 2 in an enum and update the prefs then this value is shown in both the gui and the settings map. However, if you click Reset to remove all of the settings, then refresh the page, this value of 2 is still present in the gui, when it should go back to the default value. And likewise, after the Reset the settings map is empty, but the gui still shows the prior settings?

So in summary, I'm seeing two issues for just the enum inputs:
1} device.updateSetting() updates the settings map, but not the gui.
2} device.removeSetting() updates the settings map, but not the gui.

[code was updated to add another input test]

metadata {
	definition (name: "Test Inputs", namespace: "test", author: "test", importUrl: "") {
		capability "Configuration"
		capability "Refresh"
		command    "reset"
	}
	preferences {
		input name: "enumStrL", type: "enum", title: "enumStrL", defaultValue: 1, options:["1","2","3","4","5","6"]
		input name: "enumInt", type: "enum", title: "enumInt", defaultValue: 1, options:[1:"1",2:"2",3:"3",4:"4",5:"5",6:"6"]
		input name: "enumStr", type: "enum", title: "enumStr", defaultValue: 1, options:["1":"1","2":"2","3":"3","4":"4","5":"5","6":"6"]
		input name: "enumIntM", type: "enum", title: "enumIntM", defaultValue: 1, options:[[1:"1"],[2:"2"],[3:"3"],[4:"4"],[5:"5"],[6:"6"]]
		input name: "enumStrM", type: "enum", title: "enumStrM", defaultValue: 1, options:[["1":"1"],["2":"2"],["3":"3"],["4":"4"],["5":"5"],["6":"6"]]
		input name: "number", type: "number", title: "number", defaultValue: 1
		input name: "string", type: "string", title: "string", defaultValue: 1
		input name: "bool", type: "bool", title: "bool", defaultValue: true
	}
}

void configure() {
	logInfo "Configure"
	device.updateSetting("enumStrL", [value: "5", type: "enum"])
	device.updateSetting("enumInt",  [value: "5", type: "enum"])
	device.updateSetting("enumStr",  [value: "5", type: "enum"])
	device.updateSetting("enumIntM", [value: "5", type: "enum"])
	device.updateSetting("enumStrM", [value: "5", type: "enum"])
	device.updateSetting("number", [value: "5", type: "number"])
	device.updateSetting("string", [value: "5", type: "string"])
	device.updateSetting("bool", [value: "false", type: "bool"])
	runIn(1, "refresh")
}

void reset() {
	logInfo "Reset"
	settings.each { name, data ->
		logInfo "Removing $name = ${settings[name]}"
		device.removeSetting(name)
	}
}

void updated() {
	logInfo "Updated"
	runIn(1, "refresh")
}

void refresh() {
	logInfo "Refresh"
	logInfo "settings: $settings"
}

void logInfo(String msg) {
	log.info "${device.displayName}: ${msg}"
}

[Darrren]

A question and some updates...

Is this enum input thing a known issue? I've searched here a bunch but I don't see anything relevant.

This issue basically breaks the ability to copy settings from the device to its driver, since the enum inputs are displaying and effectively using the wrong values, and these old values are overwriting the settings on the driver and the device when the prefs are saved. So if the user (or the device itself) changes a setting on the device then you can't sync that to the driver. Well, you can, but it eventually gets overwritten, and it never displays the new values in the gui.

This also means that, during initial device setup, you can't copy existing values from the device and have them reflected in the gui, thus losing some or all of your current configs on the device.

After some more testing, it seems that those "ghost values" that the enum inputs are displaying (after the settings map is reset) are due to how the hub remembers each enum input's selection, which seems to be via an index value for each input, rather than via the input's name. If you change the order of the inputs in the driver code then the ghost value does not move with the related input, it stays at the input with the original position on the page.

Btw, I tested this on other devices, using other community drivers written by other people, and the same issue happens with these drivers as well, so I don't think it's just me.

[jtp10181]

I am on 2.2.8.156 firmware and I don't have any issues with it using my own driver that uses that command. The syntax is a little screwy I had to play around with it and do some searching before I got it to work right. It looks like you are using the same syntax as me. Maybe try updating to .156?

device.updateSetting("configParam${param.num}",[value:"${paramVal}", type:"enum"])

[Darrren]

Hey thanks. I did just update my hub to 156, but the issue is still happening.

Yours is one of the drivers I'm testing with. I click Set LEDMode to change the mode, let it sync and then refresh the page, but the LED Indicator (#2) input does not change to the new value. You're seeing this input's value change on yours?

[Darrren]

Aw crud, it's a browser issue! I'm using Firefox v88, and pressing ctrl-R or F5 to refresh is not updating the dropdown boxes, aka the enum inputs. I tried this on a fresh Firefox profile. However, if you hit Enter on the page url to resubmit it, or use ctrl-F5 to do the same, then the page is correctly updated. Arggh, the time I've spent on this issue.

[edit]

After some research, it seems that Firefox is, by design, caching form elements between page refreshes. So its intended behavior is to remember all select options -- thus this issue. The only way to override this behavior is to use ctrl-F5 to do a hard refresh.