State variable data slow to update

Developer Programs Writing SmartApps
1

I’ve noticed that changes to the built-in state map sometimes seem to lag a bit.

I had some time today to try to poke at this a bit and created a simple SmartApp that subscribes to a button’s events. It also runs a scheduled function once per minute that prints the start time and saves it to state.start. When the event is received by the event handler for that button, it saves the time to state.finish and logs it along with the value it sees for state.start.

Here’s log output from two consecutive runs (per the IDE, read from bottom to top):

6:10:58 PM: state.finish: 1425939058247
6:10:58 PM: state.start: 1425939003071 - as seen from event handler
6:10:57 PM: state.start: 1425939057996 - as seen from scheduled function
6:10:57 PM: --------------------------------------
6:10:03 PM: state.finish: 1425939003160
6:10:03 PM: state.start: 1425939003071 - as seen from event handler
6:10:03 PM: state.start: 1425939003071 - as seen from scheduled function
6:10:03 PM: --------------------------------------

The first run sees consistent values for state.start in both the scheduled function as well as the event handler. The second run, however, sees a new value as the start time when the scheduled function runs, but when the flow reaches the event handler we’re back to the state.start value from the previous run.

Why is this? Am I doing something wrong or is this an issue with the way the platform is distributing the workload?

2

After a little more digging it seems that even if I add a pause in the event handler, it doesn’t get the updated state.start value. When the handler is executed, is it just forking a new instance of the app with the state information it has at that time?

3

Have you tried using atomicState? There’s some examples of it in the ecobee (connect) app…

2 Likes
4

Wow, thanks! I had no idea that existed. From a dozen or so iterations, it looks like that did the trick.

Hey @Jim! This would be a good thing to add to the developer docs. I know it would’ve saved me a good many hours over the last month or so.

5

Like so many other curious nuggets you find trolling the code around here, too many of them to keep track of.

6

Thanks for calling this out. I’ll check if this is something that we support for community development. If it is, I’ll document it.

7

I’ll reply here when I learn more. Thanks!

8

Ha!, that explains so much…
This is what I was somewhat cranky about at the last dev meeting, many of these “features” are in the ST published app/device examples, left there for the curious to discover.
When we find them, you can’t blame us for asking about them or hacking about with them can you?

9

I understand your frustration.

Nope. Not at all.

10

For what it’s worth, Ryan Applegate indicated it is in this thread: