Same here - intermittent “unauthorized” failures. It’s wreaking havoc on the announcements that play on my speakers. Reauthorizing doesn’t seem to help.
Edit: So I Denied access to SmartThings and I was still able to get a Thing (a motion sensor) to trigger a rule I expected the rule to not be triggered since I denied SharpTools access to SmartThings. Am I wrong in my assumption?
I’ve seen a handful of reports of this in the past few days, but I haven’t seen any common thread across them. For a chunk of people, they just needed to reauthorize their SmartThings account and that fixed things. But there’s been a handful of cases like this where the rule runs fine most of the time, then intermittently the SmartThings API will respond with a HTTP 401 Unauthorized.
I haven’t been able to figure out and common thread between the devices / accounts that are impacted. At this point, I might need to reach out to SmartThings to see if they have any insights as to why it’s occurring.
IIRC, the events keep getting pushed for a period of time after the disconnect.
Can you please clarify that statement? What is happening to you? You had to manually reauthorize SmartThings and then your rules worked fine after that?
Or you are seeing rules run fine most the time, but intermittently report ‘Unauthorized’ for some SmartThings device conditions / actions?
Same here. It is intermittent. I have reauthorized several times this week and it comes back. Today, I got the error just a few minutes after reauthorizing and then a few minutes later it cleared. BTW - I reauthorized at time 11:16 for an error in a different rule than I’ve shown below. This is to show the intermittent activity after reauthorizing.
Thank you to everyone who has shared your rule examples.
We added some additional logging to the platform this afternoon to see what additional details we could gather. I wanted to make sure there wasn’t something funky going on our side (eg. tokens intermittently not getting read / passed through or something like that), but everything seems on the up-and-up with the requests themselves.
The SmartThings API is seemingly just intermittently returning HTTP 401 Unauthorized messages for no apparent reason and without a pattern that I can see. Clearly it shouldn’t be doing that as so many of your examples show where the same rule will run through fine one minute, fail the next, and then fine again.
I’m going to escalate this with our SmartThings engineering contacts to see if they can help track down what’s going on. It seems like much of this started within just the past few days – around the same time we saw a chunk of accounts authorization becoming invalid altogether requiring some people to reauthorize their accounts to get their dashboards and rules running again.
Maybe that is the same cause of “Error sending command” warning when tap a command tile in dashboards ? In the past days, happens sometimes (20% of taps)… after 2-3 attempts then commands work.
Unfortunately, there’s not a great way to distinguish between a ‘real’ 401 Unauthorized and these intermittent ones (at least not without some additional complexity of tracking historical responses and comparing against those and even that’s still a best-effort inference).
The SmartThings team responded on Friday that they are investigating, so I’m hopeful we’ll hear back from them shortly. If the issue continues to persist, I’ll revisit what options we might have.
–
I would note that for some people who are experiencing the 401 Unauthorized for rules that are checking state within IF conditions which are also the trigger, you can optimize your rule to avoid the state check altogether. Specifically, for rules that are checking the condition of the triggering device, you can use the Event Value Context Variable ($context.event.value) in the condition instead. Not only does this avoid the potential 401 Unauthorized response, but it’s much faster as it’s able to use the triggering event value directly rather than having to query SmartThings which might add hundreds of milliseconds to the rule processing.
In the example above, rather than using the VSwitch ST1 within the IF Condition, I use the triggering value (context variable) in the IF condition. Of course, this doesn’t solve cases where you might need to query different devices than the triggering device or multiple devices, but it can help some of the rules that were shared with me.
In the meantime, I’m thinking about how to use rules and variables to poll SmartThings for current sensor states. And how much time I want to spend putting a work around in place
My observation is that the initial action (usually the open trigger) works 100% of the time. The subsequent close trigger, which often is <2 seconds later, doesn’t trigger at least 1/2 the time. I think this is where the 401 error is causing the most issues.
I expected the rule to not be triggered since I denied SharpTools access to SmartThings. Am I wrong in my assumption?
