Determine a SmartApps installed mode settings

I’m trying to determine if a SmartApp is being called only for the mode it was defined for.

I know I can find the location modes, but I’m trying to access the modes that are optionally set when you install a SmartApp (located under the assigned name, labeled “Set for specific mode(s)”). Is there a way to retrieve those modes a SmartApp is defined to run in?

Alternatively, if I subscribe to a mode change (subscribe(location, modeHandler)), and I installed the SmartApp to only run in ‘Home’ mode, will that modeHandler only be called when the mode changes to ‘Home’?

To answer these types of questions you can always use Live Logging with log.debug "message $variable" in your app to see what’s going on.

If you use a single page preference declaration, you won’t be able to access the modes that are selected. I’m pretty sure that the app will only run in one of the selected modes, and not the others. Again, easy to test with logging.

If you use a multiple page preference declaration, you would have to provide your own input for the selected modes, and your own execution filtering. In that case you would know the modes selected.

Check the documentation here: http://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html

3 Likes

So from what I can see and tried, there’s no way to find out which modes the user has selected for the app.

Not if you use a single preference page app. But it you use multiple pages, your app will have to process the selected modes, which are in a list input to the app. So if you need access to the modes, just go the multiple preference page route, and you can do what you need with them.

That’s absolutely correct @bravenel. Just so we are the same page, this is the code recommended by ST:

section([mobileOnly:true]) {
    label title: "Assign a name", required: false
    mode title: "Set for specific mode(s)", required: false
}

If one were to log.debug:

log.debug "Selected Modes -> $mode"

The results in the live logger is:

Selected Modes -> mode

Infact according to the docs there is a object called “mode”. https://graph.api.smartthings.com/ide/doc/mode

But there doesn’t seem to be any way to access it, when I try $mode.name as suggested by the documentation, it gives me an error.

groovy.lang.MissingPropertyException: No such property: name for class: java.lang.String

If one looks at another page in the documentation, reference to SmartThings it says there is a reference to an attribute “Mode”
https://graph.api.smartthings.com/ide/doc/smartApp

quoting:

String
text, mode, or time preference name
Returns the value entered during app installation or update. In the case of mode preferences the value is the mode name. In the case of time preferences the value is a full date string of the form 2013-07-04T08:00:00.000-0400. These values can be passed directly to the schedule method or converted to a Date object with the timeToday, timeTodayAfter, or nextOccurence methods.

But I can’t seem to figure out how to access this.
Hence my assumption that there is no way to get the user selected modes. Let me know if I’m missing something.

@Jim looping you in , could you please explain the documentation on this page:
https://graph.api.smartthings.com/ide/doc/smartApp - what is this attribute mode?

Look at this:

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

followed by:

private getModeOk() {
	def result = !modes || modes.contains(location.mode)
//	log.trace "modeOk = $result"
	result
}

So how about this:

modes.each { log.debug "modes are: $it}

hmm that’s interesting, in the documentation page http://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html?highlight=input I don’t see “mode” as a type of input. @Jim back to you on this one.

I did however notice something else in the documentation:
http://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html?highlight=input#mode

 mode(name: "modeMultiple",
             title: "pick some modes",
             required: false)

This does seem to imply that one can stores the modes in a variable just like your code above.

Question for you, with the code you posted about, while it allows the user to pick the mode, does that mean the system also registers those modes? I.e. say I pick night mode with the code above, does that mean the system will only raise events on the app when in night mode or does the app need to take care of that?

however would like to add on testing the above code, $modeMultiple leads to a “null” so that doesn’t work either.
And to answer my own question above, while your code allows the users to pick from the list of available modes, it does not register with the system (the way the single app mode or the multi page app with the mode section does) and the app needs to handle mode checking.

But back to the original question - is that any way to get the “modes” registered with the system? (single or multi page app)

I think you can have one or the other, either what you’re calling “registered” or not. The reason I posted the getModeOk() code is because with the multiple page option, the modes are not “registered”, and your code has to do the work. With the single page option, your app can’t see the list of modes, but ST handles the mode restriction.

Just a small correction, when using multiple page apps, if you use the following code:

section([mobileOnly:true]) {
label title: "Assign a name", required: false
mode title: "Set for specific mode(s)", required: false

}

While you can’t retrieve the modes selected by the user (as in with your code and thanks for the pointers), this however does “register” with the system, i.e. it won’t raise events on the app when in a mode not selected by the user.

So yes, you’re right, one can only have one or the other, either get the list of modes and handle the mode selection yourself or use the built in mode registration but can’t get the list of user selected modes.

Kinda silly though ST won’t let you retrieve the list of user selected modes on the built in options.

But necessary to stick to the model of user input of preferences.

Just to answer this point on my original question… I did some testing. When a SmartApp is installed for a specific mode, it will only receive a mode change notice when that mode begins (i.e. if the app is defined for ‘Home’ only, the modeHandler for subscribe will only be called when ‘Home’ is activated).

Thanks to the community for first raising this question and then replying to it. You guys are awesome! I just wanted to let you know that I did add a blurb about this topic to the mode section in our docs. Any positive input can be directed to me, and concerns can go to @Jim :smile:

Well played, sir.

20 chars.