Accessing a parent device Field variable in a component

[jvm33]

Is this possible ...

I have a parent device with a variable defined as an '@Field static' variable, for simplicity, let's call it

@Field static Map myVariable = [1:"first", 2:"second"]

I'd like to access that in a Component child device.
I've tried accessing it using

myVariable

as well as

parent?.myVariable 

both return only a null.

Is there any way of accessing a parent devices @Field static variables from within a component device?

[gopher.ny]

Not at the time. Try wrapping it in a non-static getter.

[jvm33]

Thanks. I'll give it a try.

[jvm33]

@gopher.ny

Not at the time. Try wrapping it in a non-static getter.

For anybody else reading this who might be interested in how this worked out . .

Wrapping the variable in a getter function will work for simple variable types like a Map. So for 99% of the cases, that's the solution.

However, I was trying for the 1% more complex than that case. What I wanted to do was pass a SynchronousQueue handle between parent and child. The goal was to call a function in the parent to set a z-wave parameter value, and then pass the result from a configuration report to the child device as it arrived. However, when I tried to pass the SynchronousQueue handle, it passes as a null.

I was able to come up with another solution that I think is better in that it is simpler and less error prone.

The solution I came up with was to define a new event type named "parameterUpdate" that can be sent from the parent to child using sendEvent or sent to the child's parse(List) routine.

In my code, the child device can now call the parent function to set the Z-wave parameter and, in the parent function's ConfigurationReport report handler, I generate this new event and send it each child using

(childDevices + this).each{ it.parse([[name:"parameterUpdate", cmd:cmd]])}

Each child device that is interested in the parameter change can then handle it in its parse routine how it wishes or ignore it. The SynchronousQueue method probably has less overhead, but these updated happen so rarely, that this method works fine.