Smart App runIn Command

(JIm) #1

I have a smart app that subscribes to a switch. When the switch is open I do something. Then I want to check a few minutes later to see if the switch is still open and if so do something else. There are several switches involved.

So what I am trying to do is pass the current switch info to my timed subroutine like this:
def handler(evt) {
do something
runIn(time, timehandler(evt))
}
def timehandler(evt){
do something
}

But it appears I can’t pass the evt? Is there another way to do this?

(John) #2

Check the documentation:

http://docs.smartthings.com/en/latest/smartapp-developers-guide/scheduling.html

(JIm) #3

I had already read the docs. Didn’t and still don’t see anything there that answers my question. I guess that means it can’t be done.

(Steve White) #4

There are a couple ways to solve this issue… You call it a switch, but list attributes for a contact sensor. I’m going to assume that’s what you mean.

Since you’re interested in knowing when a contact sensor. You can do this without having to worry about passing variables or storing states.

Start by subscribing only to the “open” event…

subscribe(contactSensor, "contact.open", openHandler)

Then in your openHandler function…

def openHandler(evt) {
    do something
    runIn(time, timehandler())
}
def timehandler(){
    if (contactSensor.currentContact == "open")
    {
        // Still open, do something.
    }
}
(JIm) #5

Problem with that method, if a different contact is open after the time delay I get something true when it’s not.

I solved the problem by storing the current contact name, then in the time handler iterate thru all the contacts and if the open matches the name then it’s true.

I just thought it would be nice to pass the evt itself, but apparently that is not possible.

Thanks for the help.

(Justin H) #6

Sounds like you need the feature described here. Is this what you’re looking for?

(Steve White) #7

I was also going to suggest passing a map as the data: parameter to runIn, but thought my way was cleaner. :slight_smile:

(JIm) #8

Justin, That is what I ended up doing.

Steve, I still don’t see how that would handle a different sensor after the timeout. It does look cleaner, but not sure it would work.

Thanks to all for the suggestions.

(Steve White) #9

Sorry, it wasn’t clear as to what your intent was for the multiple devices. I drew the assumption that they were to be treated as a group performing a group action.

(JIm) #10

No problem. I appeciate all the suggestions.