Potential issue in Capability Color Temperature

🛎️ Get Help
1

I think there is a problem with the color temperature capability update. The device edit tile has three value, Color Temp, Level, and Transition time. Using the code below (quick test), the error appears to be

  • If the Level is left blank and the Transition Time is entered
    • The transition time value is attributed to the value LEVEL in the metnod
    • The transition time goes to default.

Hub Version: 2.2.6.129
Hub HW: C-4

Below is the code and a capture of the entry tile used to get the results.

metadata {
	definition (name: "CT Test",
				namespace: "davegut",
				author: "Dave Gutheinz"
			   ) {
		capability "Color Temperature"
	}
	preferences { }
}
def installed() { updated() }
def updated() { }
def setColorTemperature(colorTemp, level=50, transTime=2) {
	log.trace "colorTemp = $colorTemp"
	log.trace "level = $level"
	log.trace "transTime = $transTime"
}

image

image

2

if you use the transition time parameter, level must be supplied, even if the value is null.
When we implement this in our drivers, if null is supplied for a level, then a level command will not be issued along with the color temperature command and the transition time value will be applied to the color temperature command.
If level is not null, and transition time is not provided, transition time will default to the transition time preference set in the driver

3

Mike,
Thanks for the information.
However, if the entered level is null, then the entered transition time is passed to the method as the level. The driver method has no way of knowing if the passed "level" was entered as level or transition time - so problems will arise.

4

maybe from the UI, but not command wise.
setColorTemperature(2500, null, 2)

5

Concur. But I will get anomaly reports based on the UI entry by users. Thanks. I will disable the level and transition time entry in my code for now and take the hits there.

1 Like
6

Its possible to override the UI display. Ill post the code for that shortly

3 Likes
7

add this:
command "setColorTemperature", [[name:"Color temperature*", type:"NUMBER", description:"Color temperature in degrees Kelvin", constraints:["NUMBER"]]]

This will force the UI to a single parameter, but any calls to an implemented three parameter version will work as expected.

8

This seems to be an odd side effect of the way the UI inputs work. This input:

image

gives this output:

image

with the simple myCommand() command/method defined below:

metadata {
    definition (name: "Testing Parameters", namespace: "Test", author: "Test") {
       capability "Actuator"
       
       command "myCommand", [[name:"param1*", type:"STRING"],
                             [name:"param2", type:"STRING"],
                             [name:"param3", type:"STRING"]]
    }
}

void myCommand(param1, param2=null, param3=null) {
    log.trace "param1 = $param1"
    log.trace "param2 = $param2"
    log.trace "param3 = $param3"
}

Since we're dealing with positional parameters here (not named/Map parameters), maybe the UI should provide null values for any parameters that are left empty if it's anywhere between two parameters that are provided? As-is, the later parameters get "bumped up" to the earlier position, which provides unexpected results. I'm not sure why no one noticed this before now, but my guess is there aren't many other commands with mulitple optional parameters (speak() is the only one I know of off hand).

I know this isn't the way most users should interact with devices, but someone will. :slight_smile: And it would still be helpful for developers testing, otherwise the only way to see how these commands run (e.g., if a level isn't provided for setColorTemperature() but a transition time is) is to write an app.

2 Likes
9

that seems a good solution, we can look into it

3 Likes
10