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
}
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.
###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.
That is correct! Thanks so much for helping me think this one through and helping to determine the bug.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
6
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).
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?
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
[/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.
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 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