What am I doing wrong with Mode Selection not working?

In my smartapp I added the app name and mode control fields which are supposed to allow the user to change the name to select which modes the app executes in.

The name change piece works. However when I change modes manually to test modes out the smartapp continues to run as if the mode never changed although ST is reporting the mode changes from Home to Away?

Any thoughts of why mode isn’t stopping the app from executing ?

section ("Change SmartApp name, Mode selector") {
		label title: "Assign a name", required: false
		mode title: "Set for specific mode(s)", required: false

The ST documentation refers to two methods of “Allowing Users to Select Modes” and I think I am using the right way to turn the smartapp “off”?

Please describe this behavior in much more detail … I don’t understand the question. Thanks!

Sorry, I will post up the screen shot and point it out . Give me a few minutes

My bad, my description of the problem stunk. What I was trying to say was the code for changing the smartapp name in that section of code was working fine. In the screen shot I am able to change the smartapp name to Evap T’stat using the label title: “Assign a name”, required: false

The code I can’t seem to get to work is the next line; mode title: “Set for specific mode(s)”, required: false (see below). I am supposed to be able to use the mode() method to allow a user to select a mode that this SmartApp will execute for. Based on my screen shot, anytime I am not in Home or Away(ARM) mode this SmartApp is not supposed to execute but it still does?

section ("Change SmartApp name, Mode selector") {
		label title: "Assign a name", required: false
		mode title: "Set for specific mode(s)", required: false

I guess I am not sure what this mode() line of code does? I want all my outputs to shut off and stop anytime I am outside of my selected modes. If I remember right when I was using the Virtual Thermostat that is how it worked and I just wanted this app to do the same.

1 Like

Thanks for the details…

In the code snip you gave, the second method of Mode filtering is being used in preferences.

This means that the entire SmartApp will not execute if the Location is not in one of the selected Modes selected by the user, and that the developer does not need to explicitly check for Mode anywhere in the code. This includes, I believe, any scheduled events or methods that were subscribed while a selected mode was in effect, but is no longer active.

1 Like

That is correct! Thanks so much for helping me think this one through and helping to determine the bug.

1 Like

No problem.

This is pretty common functionality, so it will be interesting to see if there’s some quirk specific to your code that is causing it not to work (i.e., possibly a usage error on your part … that still might not be your fault if the documentation is not sufficiently detailed; do some more reading and perhaps look at other SmartApps in the SmartThings Public GitHub!; or it may be a quirk that exposes a real bug never discovered before or recently snuck into the platform).

Be sure to share the result! :wink:

If you provide your own mode selection you need to provide the logic. If it is a single page app and you don’t provide your own mode selection we will provide it for you. So in this case it doesn’t work because it looks like you dind’t provide it any logic to check against. Take a look at most of my apps for some examples of how this works. http://github.com/tslagle13

1 Like

Thanks for responding!

Did I miss that in the ST documentation? According to the link I posted out of the ST documentation on “Allowing Users to Select Modes” I thought I was doing it correctly?

However I will certainly take a look at your examples to see how to provide the logic since I didn’t see it in the documentation. Thanks!

@dalec… Tim is correct.

Dang… I misread your code, sorry, sorry, sorry :cry: :confounded: In my post above I said:

But, no, indeed, you are using the first method of Mode filtering.

Why not try using the second method?
i.e., use this method…

1 Like

Have you tried the original code today to see if it works now?

I could be wrong, but I thought I saw something about a global SmartThings problem with modes on the day that you posted this.

Thanks again @tgauchat @krlaframboise @slagle for looking at this issue with me.

I think the documentation is in error in the very least? I believe I am following this technique that is in the documentation as follows below. @slagle I don’t see anything about logic to check against?

But as I originally posted this code doesn’t work in my smartapp.

So I followed the specific syntax (that Terry recommended in the second method) below so I commented out the original code I had and then cut and pasted the exact code syntax in with the additional parenthesis as you see below and still it does not work

section ("Change SmartApp name, Mode selector") {
        label title: "Assign a name", required: false
        mode(title: "Set for specific mode(s)") 

So I am still stuck with a mode selector that isn’t working. So the last resort is I am trying to go down the road that @slagle recommended concerning logic checks [quote=“slagle, post:7, topic:51463”]
So in this case it doesn’t work because it looks like you dind’t provide it any logic to check against. Take a look at most of my apps for some examples of how this works. http://github.com/tslagle13

I went through a ton of the apps in the github and I can’t find what you are asking me to look at. Can you point me exactly to the code example using logic checks you are suggesting I do?

Thanks guys!

So right now, I think the “bug” is in the documentation for multiple page code? Maybe it has something to do with it being in a dynamicPage versus static page?

Using mode() (mode title: "set for specific mode(s)") should allow the user to select which modes the SmartApp executes for, without requiring any additional logic by the SmartApp.

Using input "modes", "mode", title: "only when mode is", multiple: true, required: false will also allow the user to select modes, but will not automatically prevent execution based on the current mode. In this case, the SmartApp would need to check the mode itself.

Here is an example showing using both methods.

It seems like you’re using mode(), but it isn’t working as expected. Would you mind sharing the entire SmartApp code, either inline here or in a gist?


1 Like

Thanks for looking at it Jim.

It is located here in my GitHub

I updated my example to follow the same pages pattern as your SmartApp. When I try it, it does not execute for any modes not selected, as expected.

Perhaps you could try my example to see if there’s something I’m missing about how to reproduce it? And if so, super-specific steps to reproduce might help.



I’ll give it a go!

So did you try loading my actual smartapp up on your local hub to see if reproduces the error?

I installed your SmartApp, chose “disarmed” for the mode, and when I trigger the motion sensors, it only writes to the live logging when the mode is “disarmed”.

When was the last time you tested this and how are you determining that the application is still executing while not in the specified mode(s)?

Thanks for looking at this Kevin. I haven’t been using live logging. I have live tested it every day because it actually is running my evap cooler now. At night when I put the system into Night mode I am expecting the fan to shut off but it all stays running.

And while it is in Night mode if I manually change the setpoint very high it turns off the evap fan motor, pump so it is still executing the smartapp control? And the same if I change the setpoint back down very low to call for cooling the evap fan motor and pump turn back on.

I think this function use to work in earlier versions of this smartapp BEFORE I made the modifications to dynamicPages. This smartapp is a derivative of the 3-speed Ceiling Fan Thermostat you helped me with.

You’re calling the temperature handler from within the update method so any time you save the settings that code will execute regardless of the mode setting.

To prevent the code in the update method from executing you’re going to have to make your code check the mode before executing. I doubt it’s related to dynamic pages.

I normally do something like:

input "selectedModes", "mode", title: "Only when mode is:", multiple: true, required: false

def doSomething() {
    if (currentModeAllowed(settings.selectedModes)) {
        // Executes if current mode matches one of the selected modes.

def currentModeAllowed(allowedModes) {
    return (!allowedModes || allowedModes?.find{it == location.mode}) 

It probably worked until you implemented the change I suggested for your original problem.


Got it! I obviously don’t understand what I did. I will look into how to make that suggested change. I am learning more about groovy from this one app then I ever thought I would thanks to you :grinning:

1 Like

Is everything clear now?