atomicState usage in device types?

(Cody Truscott) #1

The documentation — — indicates that

atomicState.fooState = now() 

is an acceptable substitute for

state.fooState = now()

However, in practice, I get this error in the live log:

java.lang.NullPointerException: Cannot set property 'fooState' on null object @ line 88

What gives? Are atomicState’s not actually allowed? Do I need to explicitly create an atomicState somewhere? If so, how?

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

My guess is that AS is only valid for SmartApps, not Device Type Handlers. Just a guess…

(Cody Truscott) #3

Seems to work as expected in SmartApps. What a bummer.

Who do I tag to get some clarification about that in the documentation?

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #4

My off-hand assumption us that Device Handler instances are running continuously and/or invoked at most once concurrently per Device Instance… So atomicState is unnecessary: state should always be consistent, no?!

(For Docs ping at Jim and/or at Unixbeast, or do a pull request on the GitHub for the doc source page.)

(Cody Truscott) #5

As I started discussing in the Enerwave ZWN-SC7 thread,

def parse(String description) {

is run twice (nearly always ~95%, although sometimes once, and rarely 3 or 4) per button press.

The handler code is unable to determine if there is already an existing duplicate parse() underway if the second parse() starts running before the first has finished.

Being able to use atomicState would solve this issue.

The documentation states that it works in Device Types, but so far I’ve had no luck. Either the documentation needs to be corrected (@Jim @unixbeast), or the functionality of atomicState needs to be fixed for Device Types.

Any ideas on sneaky workarounds @tgauchat or @slagle?

(Tim Slagle) #6

How are you defining your atomic state?

(Cody Truscott) #7
	atomicState.testString = "hello my one true value"

Seems to work in SmartApps, but not in Device Handlers (is it Device Handler or Device Type? the documentation and ide seems to use the terms interchangeably?)

(Tim Slagle) #8

That should for fine. So if you log the value it comes back null?

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #9

Definitely let’s followup with @slagle on this… Maybe even support@.

It sorta makes sense that parse() has to allow multiple concurrent calls… But, well, no… It should just queue them. Since I don’t know the actual architecture of Device Instance processes, I can’t say for sure what is happening (and why it is design that way…).

Don’t you think it should use queuing instead of multiprocessing?

So, really, while the documentation on atomicState needs clarification (or a bug has been discovered), some details on device processes / architecture would be extremely valuable (including to help solve the Enerwave problems we’re digging into!!!)…

Possibly @Tyler has clues or a path to the architect / engineer?

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #10

Slight tangent, but, yes please, please, please, documentation guys: 100% consistent terminology usage makes life 100% easier.

Strongly avoid writing “sometimes also referred to as or called …”.

A strong definition and a Glossary then makes it super easy to search :mag: for cross references and get an instant a wonderful “topic overview” of… “SmartDevice Type Handler”… (or whatever ONE name you decide to call them).

(So many Terms need to be solidified… ThingShield vs. Smart Shield? Thing Tile vs. Device Main Tile? Things vs. Devices, Mobile App vs. App vs. SmartApp, Marketplace vs. Store, Attribute, Command, variable, property, object, instance, method, …, …, …).

Thanks @jim, @unixbeast, @ben, @slagle! :smiley: :ok_hand:

(Cody Truscott) #11
 error java.lang.NullPointerException: Cannot set property 'testString' on null object @ line 73

Looks like the atomicState object does not exist by default? Is there a way to create one?

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #12

We can’t create variables with scope outside of a method (except those created in Preferences).

I swear, I really think it should not exist / not be applicable to Device Type Handlers at all (uh… because I think they shouldn’t run multiple instances for the same device concurrently, as mentioned above). In other words, if I’m using the correct terminology… Device Type Handlers should not be reentrant. And …

NB: The documentation for atomicState is in the SmartApp chapter!

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #13

Not that it is of any conclusive value, but also note that the Object API Reference Documentation for SmartApp and Device Handler are inconsistent.

  1. SmartApp discusses the state Map variable, but has no mention of “atomicState”.

  2. Device Handler has no mention of state or atomicState … just the "state() property of Tiles".

(Jim Anderson) #14

Sorry for the delayed response, been on vacation. I updated the docs to clarify that atomicState is only available in SmartApps, and also added atomicState to the SmartApp reference docs, and state to the device docs.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #15

Thanks, Jim!

Any word on whether or not Device Handler instances are reentrant / concurrent, or …?

(Tim Slagle) #16

They are not.

Atomic states just aren’t included in the deviceType api

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #17

Ummm… Thanks, but more details please!!! :sweat_smile:

If Device Handler instances are not reentrant, then there’s no need for atomicState in them, right?

Meanwhile, @codytruscott has been observing really strange / non-deterministic behavior in a Device Type he’s helping to refine… (the Enerwave 7 Button Scene Controller). The easiest way to explain his observations is reentrant calls, but … well, they aren’t reentrant, you say…?

(Cody Truscott) #18

working on a post in the other thread about my observations. I think it’s specific to how SmartThings deals with

class physicalgraph.zwave.commands.sceneactivationv1.SceneActivationSet

(Tim Slagle) #19

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #20


We’re not looking for official device support at this moment, just much better understanding and documentation and deterministic behavior of the APIs available to call in our own Device Handler.

@codytruscott has narrowed it down to one particular zwave method.

I totally understand if the device and even some of the Z-Wave methods are not officially supported, but it would help us out tremendously if we can get documentation and also know if the behavior is being modified right around now…