Parent-Child App and Device Logging Changes

[bflorian (Bob Florian)]

Today we deployed a release that corrects some long-standing issues when calling parent SmartApps from child apps or devices. Previously messages logged by the parent service manager app did not appear at all when called by a child device. Parent apps did log messages when called from a child app but the source of the messages was improperly attributed to the child rather than the parent. There were also some cases where parent state data was not being properly saved. Now you should expect to see all log messages, in order, from both the parent and the child as well as proper saving of parent state.

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

@bflorian

Now you should expect to see all log messages, in order, from both the parent and the child as well as proper saving of parent state.

Thanks Bob. So the logging from the parent app (when called from the child device) should show up on the context of the parent app or child app (since the child is calling)?

Also can you elaborate a little on what specific issue with the state of the parent was fixed (I had reported some a while back just checking in what should have been fixed)

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

@bflorian I’ll answer my question with the results I’m seeing.
What a child device calls a parent app and the parent app logs a message, it shows up in Live Logging under the parents context.

However I would like to report that it’s dropping close to 80% of the messages from the parent. How do I know this? You may have been I had posted a workaround sometime back on the community where the parent calls the child method to log the message through the child’s context. So what I see in my live logs:

• 10 messages printed from the parent through the child device context
• 2 of the above messages printed through the parents context

Great work on getting this fixed but it would be better if it printed 100% of the messages.

[bflorian (Bob Florian)]

Is there a relative small test app that you could post to replicate the issue? I would expect all the parent messages to be logged in the parent’s context

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

@bflorian

I would expect all the parent messages to be logged in the parent’s context

Just to clarify, the messages are being logged from the parents context, just that not 100% of the messages are showing up on live logging. What I had mentioned earlier was in reference to this piece of code I had written as a workaround before this fix was put into production.

Bug in Parent Child Devices

Yes I did but these are 2 different things. This is taking about sharing the State/AtomicState variables - which isn’t what I’m trying to do. I expect the State variable to be valid in the context of the Smartapp. I.e. I can access that variable anywhere in the SmartApp. In this case when the SmartApp is called the State variable always starts with null If you have a child parent just try this, in your SmartApp method called by the child try this: Device Handler (inside your refresh() command) callAppMethod(this) Also define this in your Device Handler to help see what’s going on def log(message) { log.trace message } SmartApp def callAppMethod(child) { child.log "BEFORE State: $state.testVar" if (state.testVar == null) { child.log "EMTPTY!!" state.te…

Essentially the parent would call the child device to log messages. So what my parent test app now does is:

log.trace "From childFunc"

child.log "From childFunc"

When this code is run 10 times, this should ideally print 10 messages from the child context and 10 messages from the parents context. My point was that I’m seeing 8 messages being dropped when the parent prints the log v/s all 10 showing up when the child prints the logs. The live logging is dropping messages.

Hope this clarifies it.

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

EDIT CORRECTION: BTW one more point if the parent app throws an exception while called from the child app, the exception shows up in the context of the child device @bflorian