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?

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?

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

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?

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.

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.

###So…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.

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).

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

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?

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

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
[/quote]

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.

/*
Virtual Thermostat for Evaporative Coolers .
Copyright 2016 Dale Coffing, SmartThings
This smartapp provides automatic control for Evaporative Coolers (single or two-speed) using
any temperature sensor. On a call for cooling the water pump is turned on and given two minutes
to wet pads before fan low speed is enabled. The fan high speed is turned on if the temperature
continues to rise above the adjustable differential. There is an optional motion override.
It requires these hardware devices; any temperature sensor, a switch for Fan On-Off, a switch
for pump. For two speed control is desired another switch will be necessary.
I suggest a Remotec ZFM-80 15amp relay for fan motor on-off, if you desired both pump and fan speed
then Enerwave ZWN-RSM2 dual 10amp relays to control pump and the second relay to control hi-lo speed
via Omoron LY1F SPDT 15amp relay. For only pump control any switch could work like the Enerwave ZWN-RSM1S
or Monoprice #11989 Z-Wave In-Wall On/Off module
Change Log
2016-07-04 b. removed dynamic feedback section, bug preventing saving, minor grammitical edits

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.

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.

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.