Child State Variables From Parent Device

I swear I've seen some methods for getting and manipulating state variables but I can't find them. I found this thread and I could do the opposite of it and put a method on the child to return state variables but I thought I saw something else.

From the parent app if I have a reference to the device like so...

def child = getChildDevice(getDeterministicChildDeviceId(somevar))

child.state is null as well as child.switch (it's a switch) and child.getState() throws an exception (I saw this in documention I think). Wasn't there some method for for getting a state value by name and is it public?

Have you tried

1 Like

Is there an equivalent for getting (and even better, setting) attributes - although in my case for child devices of an app.

That's exactly what I was looking for.

I believe the same should apply.

1 Like

It would be nice to know what the methods are for a DeviceWrapper and/or ChildDeviceWrapper. The only properties I've been able to ascertain so far are label (string) and device (Map).

Let's face it, we need documentation. The SmartThings docs only take you so far.

Perhaps some of it could be user driven (well user-developers at least)? I'm sure a lot of us would be happy to help, but we'd need a bit of a peek inside.

1 Like

Forgot to mention
child.sendEvent(name:"attrubuteName", value:"value")

1 Like

Chuck has suggested they are able to add documentation "on demand" for those things that come up. @chuck.schwer Wouldn't hurt to ask and let him show us how amazing he is. :slight_smile:

1 Like

So adding to this question(s):

I need to store a variable for comparison later inside an app.

How would I go about this?

I haven't found a better way so far than using atomicState to store that sort of thing. Just don't mix it with state. It's a relatively expensive way (in terms of time) of storing a value though as it means a database update for every variable.

1 Like

Ah, now that really is exactly what I needed today. Thanks for that.

As @rob mentioned state variable can be used to store values for evaluation.

def myVariable = 5
state.myPersistentVariable = myVariable

Now you can use myPersistenVariable for comparison anywhere in the app.

if(state.myPersistentVariable == 5) "Hallelujah"

Although, as I said, in my case at least, state wasn't good enough since it's only written to when the app finishes execution.

For my use case (LIFX device discovery) I had to use atomicState.

I'd recommend wrapping the access to either state or atomicState in functions - then it's much easier to switch from state to atomicState if you find it necessary.

There are two distinct reasons I open a thread in community when I have a question. One, there is a chance that somebody here will see my question and answer it a lot quicker than I can find an example on github using doogel-fu. The second and even more important reason is that it is documenting for others.

I completely agree that we need documentation but I would much rather prefer the devs to work on development and only intervene when the community is exhausted. Once we have everything we could possible want and more then they document what they did. :slight_smile:

1 Like

So... what do you mean by atomicState? Is there another map literally called atomicState that is updated atomically and you can use it just like.... ?

atomicState.myvar = myval

Just out of curiosity, when are attributes written? I don't know why but it felt right to put the house-keeping variables in state and the ones that the end-user would be interested in inside attributes.

For example, inside the sprinkler device handler I'm writing currently I have whether or not the device is enabled in an attribute. I have stuff like last update, polling interval (pretty much everything else) in state.

When should I put things in attributes? I'm sort of just doing it on feel.

This is where I learned what I know about state and atomicstate.

Also see the state section under Best Practices

As with most programming information I provide, I have to give a disclaimer. What I say is based on knowledge gathered over the years with little programming experience outside of groovy (does BASIC, QBASIC count?:rofl:). Smartthings documentation and working examples have helped me become fairly proficient.

An attribute is written when an event is sent that updates it value (eg sendEvents). It's normally used to represent a specific "state" of a device and usually associated with a device capability.

SWITCH capability has the switch attribute built in that can have 2 state..on or off.

State/Atomic State variable can be used to store any information that needs to be accessed outside a specific function/method....or needs to be persistent after an instance of the app finishes execution. Details are in the links in the post above this one.

Also attributes can be viewed on the device page and are usually exposed to dashboards. They usually represent information you think the user would probably need to k ow at a glance.

State variables are usually just needed for logic or value storage and are not necessary for user to view.

.....At least that's my understanding

1 Like

Yep, you are correct. thanks for tagging me.

Please see this page: Device Object - Hubitat Documentation

This is the reason we set up a wiki instead of a static website. We would love to get help building out our documentation. If anyone would like to help filling in undocumented methods, please reach out to me.

1 Like

Pretty sure I could help with that

Atomic state appears then only to be available to apps. I can't use it in these device drivers. Also, best practice says that you should only use one or the other according to the ST links. Interesting.

So, are events written immediately (aka are attributes atomic) or does execution have to stop before they are written/triggered/persisted/whatever? I was pretty much on the right path for my feel of how to use them. They're mostly setup through capabilities but if you have something else important make one or that purpose (like whether the system on the sprinkler controller is sleeping or enabled).

Thanks for the responses!