Can you alter the enumerated values for a control -- specifically, the "set speed" control?

🚧 Developers Code Share
1

Is it possible to alter the list of enumerated values displayed by one of the pre-defined controls, and is it possible to 'hide' controls that aren't desired?

Specifically, when I include the "FanControl" capability, I'd like to remove "auto", "medium-low", and "medium-high" from the enumerated types so that the setSpeed control doesn't present those options. I'd also like to be able to hide the cycle speed control, if possible.

2

Unfortunately, there is no way that I know of to change the list of possible values for setSpeed() command. What I do, instead, is to simply map the 'unsupported' speeds to other speeds that are supported properly. So, if a user selects "medium-low", I simply interpret that as "medium", same with "medium-high". "Cycle Speed" is simple to implement, by just changing to the speed to the next higher supported speed, wrapping around to 'off', and then starting over.

3

It's possible to override command enums in a driver, I'll post an example of that shortly, it's not possible to hide capability generated commands.

1 Like
4

Very much appreciated. Also, if it can be specifically done for a "child" device from the parent that would be helpful (i.e, so I can alter the command enums for the set speed control of the pre-defined "Generic Component Fan" driver. Thank you.

5

that's not possible.

Also, this won't be completely sorted until 2.2.6 is out.
in platform 2.2.5, the capability enums are merged and de duplicated with whatever you have added, in 2.2.6 the local command definition will completely override the capability provided one.
The platform doesn't enforce any constraints on the enums passed to methods, so you will have to handle any values that you aren't expecting.

import groovy.transform.Field

@Field static Map operatingModes = [
    "1":"off"
    ,"2":"heat"
    ,"3":"cool"
    ,"4":"auto"
    ,"5":"emergency heat"
]
@Field static Map fanModes = [
    "1":"auto"
    ,"2":"on"
]
@Field static Map operatingStates = [
    "0":"idle"    //last state heat
    ,"1":"heat"   //stage 1
    ,"2":"heat"   //stage 2
    ,"5":"idle"   //last state cool
    ,"6":"cool"   //stage 1
    ,"7":"cool"   //stage 2
    ,"8":"off"
    ,"9":"emergency heat"
]

metadata {
    definition (name: "Lutron HVAC Controller",namespace: "hubitat",author: "Mike Maxwell") {
        capability "Actuator"
        capability "Sensor"
        capability "Temperature Measurement"
        capability "Thermostat"

        attribute "supportedThermostatFanModes", "JSON_OBJECT"
        attribute "supportedThermostatModes", "JSON_OBJECT"

        command "setThermostatMode", [[name: "Thermostat mode*",type:"ENUM", description:"Thermostat mode", constraints: operatingModes.collect {k,v -> v}]]
        command "setThermostatFanMode", [[name: "Fan mode*",type:"ENUM", description:"Fan mode", constraints: fanModes.collect {k,v -> v}]]
    }

    preferences {
        input(name:"logEnable", type:"bool", title: "Enable debug logging",defaultValue: false)
        input(name:"txtEnable", type:"bool", title: "Enable descriptionText logging", defaultValue: true)
    }
}
6

That's tremendously helpful. Thank you.

And I understand the point about the platform not enforcing any constrains on the enums. I had realized that if a command was received over Maker API which then called the method, for example, I'd still have to have the methods accept the full set of enums so I could logically respond even if the choices were not displayed on the web interface version of the command, but I wanted to limit the drop-downs on the web interface -- thanks to the example, I can now do this.

Also, it looks like it makes sense to wait until 2.2.6, which I'll do. If you are making changes in 2.2.6 to the controls, please consider also adding a bitmap type. It would be helpful for entering z-wave parameters specified as a bitmap. What I'm thinking is a simple extension of the "enum" type, but you enter the enum values like 0b00000001: "choice 1", 0b00000010:"Choice 2" and if multiple items are selected, the bitmaps are all and-ed together.

7

that's a reasonable request, but not feasible at this time.

8

OK - maybe on a future update then. I tried doing this with the "enum", multiple:true input control, which produces the choices as an array of individual numbers -- I thought I could just & the numbers togeter, but due to a bug in that control, was unable to get it to work properly. The bug was cited here: https://community.hubitat.com/t/2-2-4-158-bug-input-control-type-enum-multiple-true-bug-c7/57899/12 and is pretty easy to reproduce, as documented.

9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.