Subscribe to location changes


(Steve S) #1

I have noticed when I do

subscribe(location, modeChangeHandler)

the mode returned by, location.mode is the mode it’s changing FROM, not the mode that’s being changed to… is this expected behavior?

I have an app set to turn on some lights when a door is opened but only if the mode has switched from Away to Home in the last 10 min. Took me a while to figure why this didn’t work:

def modeChangeHandler(evt) {
	def timenow = now()
        if (location.mode == "Home") {
           sendNotificationEvent("Porch Light: Mode Changed to ${location.mode} at ${timenow}")
           state.timemodehome = timenow;   
     }
}

When the system would switch from Away to Home, location.mode would evaluate to Away.


(Florian Z) #2

@stevesell, just shooting in the dark here, but the location class also has a field named currentMode. What value is this set to? Also, you can debug log the Event name and value fields, maybe there is more information in those.


(Steve S) #3

@florianz - no dice. Both location.mode and location.currentMode.name are the same. They both show the name of the mode I am leaving rather than the mode the system is changing into.

I guess I will shoot support an email to see if this is expected or not.


(Florian Z) #4

@stevesell, let me know what you find out.

Have you had a chance to check what evt.name and evt.value are set to in the modeChangeHandler?


(Steve S) #5

@florianz - yes. evt.name is “mode” and evt.value is the name of the mode that is being changed into. So this worked for me. I guess the apps get the event before the ST hub/server acts on it.


(Florian Z) #6

Yeah, this is sort of an age-old software engineering problem when it comes to events/notices/messages, isn’t it? Is it better to send out a WillDoX, or DidDoX or both?

Either way, it sounds like you can get by with just knowing the state you are transitioning FROM and TO, and having both bits of information available is great. Thanks for keeping me posted!