atomicState usage in device types?

Devices & Integrations
1

The documentation — http://docs.smartthings.com/en/latest/smartapp-developers-guide/state.html?highlight=atomicstate#atomic-state — 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?

2

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

3

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

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

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.)

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?

6

How are you defining your atomic state?

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?)

8

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

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?

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:

1 Like
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?

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 … Beginner's Corner - Reentrancy

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

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”. http://docs.smartthings.com/en/latest/ref-docs/smartapp-ref.html#state

  2. Device Handler has no mention of state or atomicState … just the "state() property of Tiles". http://docs.smartthings.com/en/latest/ref-docs/device-handler-ref.html

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.

3 Likes
15

Thanks, Jim!

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

16

They are not.

Atomic states just aren’t included in the deviceType api

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…?

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
19
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…