Something badly broken when setting state keys?

General Discussion
1

During the last hour or so I have seen massive failures in my smartapps; the root cause seem to be that most state.[key] = null operations are failing to actually change the specified key to the new (null) value. Setting state keys to values != null seems to be working as usual.

Is anyone else seeing this?

2

…to answer my own question, yes, setting state keys to null has not been working since yesterday (10/11).
This simple test app proves it; you don’t even need to publish it, just test it in the simulator associating it to a virtual switch. Clicking the switch you will see this kind of output:
8:53:51 AM: debug [switchHandler] - state set to null
8:53:51 AM: debug [switchHandler] - state is 87
8:53:45 AM: debug [switchHandler] - state set to null
8:53:45 AM: debug [switchHandler] - state is 87

You can see that the state (for the “Something” key) is set to 87 initially; the switchHandler sets it to null - which seems to be working fine while in the context of the switchHandler callback; but next time you click the button, switchHandler goes back to seeing 87. The problem exists only when setting the key to null; if I set it to a different (non null) value, then things would work as expected.

I’m reporting this to support.

definition(
name: “test”,
namespace: “”,
author: “Minollo”,
description: “test”,
category: “”,
iconUrl: “https://s3.amazonaws.com/smartapp-icons/Convenience/Cat-Convenience.png”,
iconX2Url: “https://s3.amazonaws.com/smartapp-icons/Convenience/Cat-Convenience@2x.png”
)

preferences {
section("A switch "){
input “aSwitch”, “capability.switch”, title: “Switch”, multiple: false, required: true
}
}

def installed() {
log.debug “Installed with settings: ${settings}”

initialize()

}

def updated() {
log.debug “Updated with settings: ${settings}”

unsubscribe()
initialize()

}

def initialize() {
subscribe(aSwitch, “switch”, switchHandler)
state.Something = 87
}

def switchHandler(evt) {
log.debug "[switchHandler] - state is ${state.Something}"
if (state.Something == null) {
state.Something = 87
} else {
state.Something = null
}
log.debug “[switchHandler] - state set to ${state.Something}”
}

3

Multiple users reported a bug with one of my DTHs yesterday and this ended up being the problem.

I almost always use “if(state.val)” instead of explicitly checking for null so I was able to fix the code by setting them to false instead of null, but this is a serious issue that SmartThings needs to fix ASAP.

I’m really surprised we’re not seeing a lot more complaints about this problem.

1 Like
4

Yes, the silence is quite surprising.

I did workaround most of my problems similarly to what you did… Still, I’m quite sure that some corner of some of my apps is currently broken in unpredictable ways.

1 Like
5

I’ve written 3 SmartApps and 30+ DTHs so I’m sure some of them are broken right now, but I don’t have time to add temporary fixes to all of them every time the platform gets messed up because that happens way too often.

Hopefully they’ll have the problem fixed within a few days.

1 Like
6

I have been using ST for 4+ years now, and I’ve written or customized all the apps and device handlers that I have currently running. I can confidently say that 50%+ of the code in those apps is there just to add redundant paths in case some basic ST functionality stops working (most noticeably, scheduled time events; but also occasional issues with state settings, and atomic state handling). I must say that I didn’t plan for this particular one… shame on me…

2 Likes
7

We are currently expiring issues with eu01 with SmartApps running on schedules? What shard are you guys seeing this in?

Yesterday there were issues with na01 SmartApps :slightly_frowning_face:

8

How do I know which shard(s) are my apps running on? From what I can tell, all my apps (and a test app I played with today - and attached here) are seeing this bad behavior.

9

Shards are described in our documentation. In general most people look at the URI for our web portal.

graph.api.smartthings.com -> na01
graph-na02-useast1.api.smartthings.com -> na02
graph-na04-useast2.api.smartthings.com -> na04
https://graph-eu01-euwest1.api.smartthings.com -> eu01

2 Likes
10

I suppose I’m on na01.

1 Like
11

I’m also on na01

1 Like
12

I just ran into this problem with another one of my DTHs.

I’m not sure which shard the user that reported the problem is using, but I’m on na01 and I’m still unable to set state values to null.

Can you provide an ETA for fixing this problem?

13

I am also experiencing this on na02

EDIT: I also switched to using false instead of null as a workaround

14

This seems to have been resolved (at least for me on na01); my test app now works as expected.

1 Like
15

Getting reports of this affecting atomicState also, it isn’t able to keep objects assigned and instead is returning null for objects.

16

That sounds like a different problem - possibly related, but different; the specific issue discussed here is about state keys not storing the “null” value persistently. And that seems to be resolved right now; maybe something else got broken in the process?

17

I think may be related, when the an object in the atomicState is assigned a null value, the entire object disappears:

e.g.:

atomicState.authV = "X"
atomicState.authV = null
log.trace atomicState.authV

It throws an error that cannot get property 'authV' on null object

18

That’s very odd; also because the error suggests that atomicState itself is null…
I tried it myself, and the code snippet worked fine for me.

19

Yep, that’s what was confusing. Oddly the app was installed for over a year and working fine and then suddenly this popped up.

20

You mentioned “app”; but, just to double check, is this in the context of a device handler or an app?

1 Like