Seems like it's always the easy things. This question has been asked before but never a clear answer.
Parent app calls a function in a child device. Child device executes the command and creates a map of results (visible on the child) and returns to the parent. However, parent sees the return value as null.
This function is doing that part. I know I'm connecting to the child device because the command "getUnusedTiles()" is getting executed as witnessed by the logs.
I've gone through the docs but I don't see anything regarding return value. But I do notice a getState in "To be Documented Section" so I can try that.
Something else must be going on in your code. I'd suggest paring it down to a minimal, non-working example for yourself (perhaps in a new set of drivers you create to test this), which may help you discover whatever the problem is on your own, or sharing more of your code and pointing to the relevant parts in case anyone feels like wading through it.
Thanks for taking a look. As far as I can tell this is the biggest difference. I'm using the DNI as a string. The parent already knows the DNI because they created the child device by that name. You have a /1 which I'm assuming indicated the first child?
I will create a total bare bones config and see what I can figure out. thanks for your help.
That was just the DNI I know I created for this child device (I probably should have used the device ID and not the DNI, but as long as it matches, it works).
What does the called method in the children device code look like?
Is it also defined as a command in the child device? In my example, it was not. This could affect outcome; I've never tested and don't recall, but from a platform-level perspective, commands don't return values (they just...run, executing the Groovy method of the same name), so I'm not sure what their in-driver behavior would do.
I just tried it out at home and your educated guess was correct. After removing it as a command defined in the metadata section it began to behave as expected and I'm able to see the return values.
Sort of makes sense as many of the commands defined are used to interact with the devices and those responses are all returned to 39501 and make their way back to the driver via that route. So it makes sense that the commands are stateless.