Child State Variables From Parent Device

[codahq]

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.

Parent function to return settings/state data to child app

Continuing the discussion from here: Parent/child app (post #59 - 63) UPDATE -- Resolved , see post 4 below for the working parent function. I'm trying to get variable data from a parent app into a child app for the child app's logic to use. For the most part, I have the function below working, except I have a parent variable that is a date. The function returns it as a string. I'm trying to find a way to detect that the string should be a date and cast it/return it as such. Any…

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?

[stephack]

@codahq

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
child.currentValue("switch")

[rob]

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

[codahq]

@stephack

currentValue("switch")

That's exactly what I was looking for.

[stephack]

I believe the same should apply.
child.currentValue("attributeName")

[rob]

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.

[stephack]

@rob

and even better, setting

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

[csteele]

@rob

Let's face it, we need documentation

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.

[aaron]

So adding to this question(s):

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

How would I go about this?

[rob]

@aaron

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.

[rob]

@stephack

@rob

and even better, setting

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

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

[stephack]

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) log.info "Hallelujah"

[rob]

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.

[codahq]

@rob

Let's face it, we need documentation.

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.

[codahq]

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.

[stephack]

@codahq

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

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

https://docs.smartthings.com/en/latest/smartapp-developers-guide/state.html

Also see the state section under Best Practices
https://docs.smartthings.com/en/latest/code-review-guidelines.html

[stephack]

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?). Smartthings documentation and working examples have helped me become fairly proficient.

@codahq

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.

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

[chuck.schwer]

@csteele

Chuck has suggested they are able to add documentation "on demand" for those things that come up.

Yep, you are correct. thanks for tagging me.

@rob

It would be nice to know what the methods are for a DeviceWrapper and/or ChildDeviceWrapper.

Please see this page: Device Object - Hubitat Documentation

@rob

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

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.

[rob]

@chuck.schwer

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.

Pretty sure I could help with that

[codahq]

@stephack

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?). Smartthings documentation and working examples have helped me become fairly proficient.

@codahq

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.

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

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!