if (modes1) {
avaliableModesEnum = avaliableModesEnum.minus(modes1)
}
if (modes2) {
avaliableModesEnum = avaliableModesEnum.minus(modes2)
}
log.debug "availableModes(): avaliableModesEnum: ${avaliableModesEnum}"
return(avaliableModesEnum)
}
Basically, if modes1 has a mode selected, it shouldn’t be selectable for modes2. I’ve tried using enums and while the debug output is correct, the menu simply displays an empty text box.
The following code works, but it creates a situation where a user could mistakenly configure different things to happen for the same modes at the same time.
You could add other controllers to enable/disable the modes and then use these boolean values in a condition to avoid that situation.
Here’s the configuration I used in my DTH to have the options shown in the picture:
preferences {
section("Modes 1") {
input "mode1status", "bool", title: "Enable Mode 1", description: "Enable this if you want to use the mode 1 value", displayDuringSetup: true
input name: "modes1", type: "enum", title: "Modes 1", options: ["Option 1", "Option 2"], description: "Enter mode", displayDuringSetup: true
}
section("Modes 2") {
input "mode2status", "bool", title: "Enable Mode 2", description: "Enable this if you want to use the mode 2 value", displayDuringSetup: true
input name: "modes2", type: "enum", title: "Modes 2", options: ["Option 3", "Option 4"], description: "Enter mode", displayDuringSetup: true
}
}
Thanks, @nayelyz. It’s a good idea. But in this situation, both mode sets can be valid at the same time. They just can’t include the same modes. Let me explain:
This is for a mode based thermostat. I used to base these optional temperature settings on the status of Smart Home Monitor. But the new SmartThings app has made that value unavailable. I have decided to use modes as an alternative. The idea is, if the home is in a particular mode, say for example away mode, the thermostat can optionally enforce certain temperatures. Obviously the user can create several modes that would all be valid, and users may want the temperatures for some of the modes to be the same. But if one setting says to set the cooling setpoint at 75 if in away mode, and another says to set the cooling setpoint at 72 if in away mode - well obviously that doesn’t work. I used an IF, ELSE IF condition set in the code that will keep problems from happening, but it’d be cleaner if I could make it so that modes are only selectable once. Otherwise I expect users may eventually come to ask me why their configurations aren’t working as they expect.
The preferences’ values cannot be used to modify other parts of the DTH’s metadata or the input’s options.
From what you described, you could use the “Automations” function in the mobile app.
There you can set the location mode (away, home, etc.) as a condition and control devices when it’s met, see the pictures below.
Well that’s how it works. A user sets a particular mode, and then my app adjusts the temperature settings based on the modes selected. The only thing is, I would like to be able to create an enum or a collection of some sort that I can add all available modes to and then subtract them after they are selected for an app setting – and have them be recognized as modes when they are used.
You can get the idea from this example although this example doesn’t work:
Have you tried using this? When I use this, or when I attempt to use my code above, I end up with a text box that lists comma separated values of the modes. For many people, they won’t understand this. I really would like to get a drop down selection of available modes like when you do this:
