Is webcore down no piston access [401 HTTP status codes]

#62

I’m also from EU and having exactly the same issues. Few of my pistons having serious delay issues (10-15 seconds) as well.

#63

Does anyone want to try the token reset instructions posted earlier? This is now clearly a widespread issue, but it would be helpful if one person can check whether it helps to generate a new token for accessing SmartThings that would be informative.

#64

You can add me to the list in the US.

NA02.

It seemed to get better last night and was fine this morning, but now I can only load about half my pistons.

[edit] Now it all seems to be working again.

#65

Can somebody braver than me try @ipaterson’s suggestion above please and report back. I’m too scared to.

#66

I’ll try the webCoRE update shortly and report back. For right now, I’m confirmig the ST Log (IDE) error that others have reported:

image
image.png1687×209 52.3 KB

#67

More context here: when you install webCoRE, ST generates a token that allows communicating with your specific smart apps. The token has a far future expiration date, something like 50 years, so normally you don’t need to refresh it but some people may choose to do so as a security measure. Some people have had account issues that required refreshing the token.

When you generate a new token, any browsers or apps that were logged in to the webCoRE dashboard have that old token and will no longer have access to your account until you re-authorize the browser for webCoRE. The token is also included in the external links for triggering a piston from a third party system, so any external links will become invalid when the token is reset. Otherwise, this does not have any effect on your pistons, GitHub integration, or other ST settings.

Thanks for following up everyone, I’m still monitoring my own account for these issues.

#68

No longer necessary. I was able to get the 401 error consistently on my scrap instance of webCoRE and resetting the token had no effect. Time to reach out to SmartThings; status page currently showing no issues.

#69

It seems like ST is having some internal issues with incidents. If you need access to the dashboard and pistons before this is resolved on their end, stay tuned for code tweaks. It is unclear whether this is isolated to incident lookup, but the issue is anecdotally resolved on my end when incident lookup is skipped.

#70

Issues here with EU aswell. Can’t open pistons.
Sorry, an error occurred while retrieving the piston data.

#71

Maybe related to the issues at ST, maybe not - ignore as needed:

Although less than I’ve seen for the past three weeks or so, I’m still getting quite a few of these in my piston logs:

"Error while executing physical command [my_device_name].refresh([]): java.lang.reflect.UndeclaredThrowableException"

@ipaterson Thanks for your continued efforts on this.

#72

The temporary code patch is now available, see all changes here. Copy and paste in place of the corresponding smart app, then save and publish changes.

While active, this code patch will eliminate any incident tracking in webCoRE since the incident lookup is what seems to be failing. Only install if you are aware of this limitation and will revert the changes once the problem is resolved.

If your piston uses $incidents or $shmTripped directly those values will report null regardless of current incidents. The patch also logs a warning as a reminder to revert once the problem is resolved.

webCoRE SmartApp
webCoRE Piston SmartApp

#73

Thanks @ipaterson, I will wait a little while and see if things get fixed on their end. I don’t really need to modify anything right now.

Most of my pistons seems to be working but I have seen some things things that were delayed or did not complete. So this not only effects editing but operations as well?

#74

This could affect any pistons that use incidents, such as with $incidents or $shmTripped. It is not clear whether any other operations would be affected.

#75

I made copies and saved both existing apps (webCoRE and webCoRE Piston) to my hard disk and then and copied and pasted your patched versions in place. I’ve now tested it on my PC, iPhone nad iPad and they all work fine. Thank you! I’ll put the old versions back whenever ST fixes their end - or I notice any functional issues with existing pistons.

#76

@Mckenph @smartie @Alwas @Ervin @kevinsunny if you need access to the webCoRE dashboard and pistons before SmartThings resolves this issue please see the temporary code patch here:

#77

Everything in the last 30 minutes appears to have sorted itself out on my end, I can access all pistons it seems. Even though it’s not present now, the banner “There was a problem loading…” has been an annoying part of my WebCoRE experience for the past 6 months, on all devices.

#78

Don’t see anything in the REPO but I will get them from the site

#79

These changes are not published for pulling in through the GitHub integration. Instead, the earlier reply includes links to the patched code.

#80

SmartThings is now aware of and investigating this issue.

#81

Update:
As I mentioned above, I pasted the patched webCoRE and webCoRE Piston in place and the ‘401’ issues disappeared and I was able to load the webCore and all pistons without a problem.

However, as I tested some pistons, I discovered (so far) that (2) pistons/Alexa routines that use (2) Alexa Buttons to toggle two ceiling fans - and the patched code causes the pistons to not function properly. As an experiment, I put the original webCoRE/piston code back in place and the pistons continue to work as they did previously (i.e., they work well). Neither of those things are really surprising. However, I then went back to see if I could load webCoRE and its pistons with the original webCoRE/Piston code in place - and so far, at least, I’ve been able to do that too. Interesting.