[Resolved] SmartThings Intermittent "Unauthorized" errors in rule

This is happening to me too! I had to re-authorize 2 times in the last week. I don’t know what is going on hopefully one of “those things”

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?

I did the “re-authorize” thing several days ago, but keeps coming back. And it is intermittent – it just works when it wants to :frowning:

And it also seems to only be occurring on the MQTT Motion Plus device by TAustin:

2:48:18 PM Triggered by device event: MQTT MotionPlus motion is active
2:48:18 PM IF condition logic check failed for: Kitchen Lights switch; Unauthorized.
2:48:18 PM State retrieval failed for: Kitchen Lights switch; Unauthorized.

I checked the other rule logs and I am not seeing the error on any other ST devices.

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.

From earlier today:

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.

6 Likes

Thanks @josh for reviewing with ST team.

1 Like

In addition to the “Unauthorized” error, I’ve also been getting a bunch of these “Failed to send device command.”

That makes sense since it seems to be the broader SmartThings API that’s intermittently responding with 401 Unauthorized.

image

1 Like

I’m seeing the same. And I agree with Josh in that it’s related to the unauthorized issue. Pain in the ass to be frank.

1 Like

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.

Hey Josh-

Until this “Failed to send device command” issue gets sorted out,

is there something that can be added to a rule that will immediately resend the command? (If it sees this error)

1 Like

This is a great idea.

1 Like

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.

1 Like

Several posts over on the SmartThings Forum as well. Hopefully SmartThings will figure this out!!

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 :slight_smile:

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.

For my Motion sensors I just went with True/False variables. Kind of a simulated motion. As you said, ACTIVE is always 100%, it’s INACTIVE that gets hung up.

So ACTIVE sets TRUE, followed by the time out period (20 seconds) delay, sets FALSE. Motion again will Set TRUE again. Not ideal, but beats garage lights on all night.

Seeing the same thing on rules that have fun forever. Samsung motion sensor and leviton switch

what is interesting is it fails and then trigger, but then the switch fails with the same issue

I think this option, but I’ll explain more clearly. My sharptools automations do not run. I log into sharptools and re-authorize smartthings and then they run again without issue. I have had to do this a few times this week

Since the automations are running fine after these steps there isn’t a reason to check the logs

Thanks for the clarification! That sounds like a different issue. In reviewing system logs, it looks like it hasn’t happened since last week, but feel free to create a separate thread or send a note to support@sharptools.io with more details if it happens again and we can take a closer look. :slight_smile: