childDevices: parent.someMethod(this)

(Mike Maxwell) #1

I see this all over the place in childDevices for ST service manager apps…
I get what it’s supposed to do (I think), however I’ve never been able to get it do anything with my own devices or apps.
Nothing ever fires on the app side.

Does anyone know how this works?

(Dan) #2

I haven’t seen this pattern and tried it with a smart app and child device type that I’ve been playing with on and off for a while now. For me, it appears to work, although I never get any logging out of the parent. So if I had just a debug statement in the parent someMethod(), it would have looked as if the function never got called. Also, I didn’t try to pass any parameters.

(Mike Maxwell) #3

Right, exactly, it would log if it was being called, so it’s not being evoked on the parent.

(Dan) #4

What I’m saying is, I do see the result of the parent executing the function, even though I do not see the log statement from the parent in live logging.

In my case, the parent function invokes a command on the child. I see the logging from the child, both where I call the parent function and then in the resulting command in the child. But I don’t see the log statement in the parent. Even though it must be working, because if I comment out calling the parent function, I don’t see the child executing the command.

(Mike Maxwell) #5

So you’re doing something like this:?

Child executes parent.someMethod(this) then
in the parent you have, 

Then at the child:
  Log.debug "and this is producing log output?"

[WITHDRAWN] MyQ LiftMaster/Chamberlain
(Dan) #6

Yes, except I am not trying to pass parameters in either the child or parent function. And the child function is defined as a command.

(Mike Maxwell) #7

Bizarre, PFM…
Thanks for having a look at this.

(Yves Racine) #8

@Mike_Maxwell, what you need to do is a trace with sendPush commands… You’ll then see that the parent function is actually called.

The child and parents functions are just called in different threads and you can’t see them in the IDE’s live logging.

My 2 cents.

(Mike Maxwell) #9

OK, there we go, that makes sense. I was starting to believe in ST sparkle ponies for a minute there…

(Yves Racine) #10

@Mike_Maxwell, a sparkle pony as in the Burning Man Festival or something else??

(Mike Maxwell) #11

Na, just make believe nonsense, fairy tales, magic. When it’s all unicorns and sparkle ponies, we aren’t living the real world so to speak, the land of make believe. BTW, burning man attendees are called “burners”, if you really wanna be hip at your next trip to the pub.

(Yves Racine) #12

@Mike_Maxwell, I’ve lived in San Fran for 5 years, so I know about the “burners”…

( - Make your home your butler!) #13

So here’s a neat workaround to capture the logging from the parent app.

In the child app (Device handler) include the following definition (in the definition section):

command "log", ["string","string"]

Now also define the following method in the child app (Device Handler):

// Print log message from parent
def log(message, level = "trace") {
	switch (level) {
    	case "trace":
        	log.trace "LOG FROM PARENT>" + message
    	case "debug":
        	log.debug "LOG FROM PARENT>" + message
    	case "warn":
        	log.warn "LOG FROM PARENT>" + message
    	case "error":
        	log.error "LOG FROM PARENT>" + message
        	log.error "LOG FROM PARENT>" + message
    return null // always child interface call with a return value

In the child app (device handler), any call to the parent where you want to capture logging should include the current instance. e.g.



In the parent app (SmartApp), in the function being called use this to capture the log in the IDE through the child app:

def someFunc(child) {
	child?.log "Some message printed at trace level by default"
	child?.log "Some message to be printed at error level", "error"

You can very the log level by using trace, debug, warn or error (trace by default if no level is specified)