All Endpoints Now Invalid!


(Convinced ST will never be unbroken…) #1

First of all let me say… THIS JUST SUCKS!!!

Yesterday I noticed I lost connectivity with my CA3750 controlling my water heater (that was one cold shower!). I am guessing this was caused by a power failure we had two days before. Note that the hub never lost power (UPS), just the CA3750 and all of my other ZWave/Zigbee devices.

In trying to restore the connectivity I did two things:

1.) Reboot the hub (didn’t work).
2.) Removed the CA3750 from the hub, dragged the hub down to the garage and re-paired it, moved the hub back upstairs and repaired the Z-Wave network.

Now, all of my endpoints are broken (“This request is not authorized by the specified access token”). So can the powers that be tell me what caused this? And what other operations would cause this to happen in the future so I can avoid them.


(Carlos Perez) #2

Where you ever able to figure this out? planning on installing this week a CA3750 to control my water heater.


(Chrisb) #3

Was it all your endpoints or all the endpoints to this device?

So far I’ve only had to remove/re-add a device that I was using endpoints with once and I know it screwed up my endpoints. Which sorta makes sense in a way I guess. I mean as far as SmartThings knows, this is a brand new device, so it needs to create new endpoints to it.

I’m assuming you tried a repair of the z-wave network… did you have any other devices that wouldn’t respond after this happened?


(Convinced ST will never be unbroken…) #4

Nope. But all I get back from any of my endpoints now is:

{“error”:true,“type”:“AccessDenied”,“message”:“This request is not authorized by the specified access token”}


(Chrisb) #5

[quote=“scottinpollock, post:4, topic:5343”]
Every endpoint to every device (I had 17 of them; both zwave and zigbee).[/quote]

Ouch! That’s a lot manual labor there repairing that. I have no clue why it would kill the other devices. Like I said, I only had to do this once and while I did need to re-create for that device (expected), it didn’t knock out any of my other devices’ (I wanna say around 10 at the time) endpoints.


(Convinced ST will never be unbroken…) #6

Ouch, indeed! I had these 17 endpoints referenced on 4 different devices, and it would take the better part of a day to update them all. Because of this, and now that groups are officially supported in the Hue API, I will control them from it instead of SmartThings endpoints, so that just leaves a limited amount of zwave stuff.

Not happy at all with SmartThings right now!


(Geko) #7

I’m curious if you talked to support and what did they have to say? Looks like there was a server-side software update in the past few days. I wonder if that had something to do with invalidating access tokens.


(Convinced ST will never be unbroken…) #8

Sent them an email yesterday. So far… nuthin’.

Happy to post back here if they ever get back to me but recently I have not had much luck getting answers from them.


(Ben Edwards) #9

Your questions are too technical for our support, @scottinpollock - they often have to pass them off to engineers and then the request is fighting with a bunch of other priorities. Not saying this is right, just letting you know. We are looking into this for you.


(Convinced ST will never be unbroken…) #10

Thanks @Ben,

One response I got was that the tokens expire by their very nature, and that I should be employing a number of methods in my app to refresh them.

Problem is I am not using them in conjunction with an app. I generated the urls via http://labs.smartthings.com/exampleOauth.php and am calling the urls from HAM Bridge, iRule, and Tasker.

So what is the default expiration on these URLs? IIRC, mine were less than 45 days old.


(Patrick Stuart [@pstuart]) #11

Learning Oauth lately, and it appears there needs to be far better documentation (shock, I know) on how to do this properly within the ST ecosystem.

I think you need to incorporate a token renewal method in the login portion of your code. There should be a flow where it will check to see if the token is going to expire and renew / get new token.

This is a kind of keep alive that if isn’t done, the token will expire.

Just doing the website url and getting the token isn’t good enough to sustain the Oauth token over time.


(Geko) #12

This approach works for social networks where users are required to authenticate themselves now and then. It’s not suitable for the IoT where devices can not authenticate themselves through standard OAuth flow. Most device clouds today allow users to create/revoke access tokens in the management console.


(Ben Edwards) #13

FWIW I don’t think token expiry is the issue here (it is set to 50 years). We are looking into this a bit more for a more thorough response.


(Convinced ST will never be unbroken…) #14

That’s worth a lot… waiting enthusiastically for more info.


(Luke) #15

It looks like your copy of the Endpoint Example SmartApp was installed at 2014-09-29 20:47:24 UTC, which is pretty recent, so I’m guessing as part of repairing your network, rejoining devices, etc., you ended up deleting those devices and then also uninstalling your existing Endpoint Example SmartApp. Is that correct? The URLs that you copy/paste from that “exampleOauth.php” page have the id of the installed SmartApp in your account built in, so when you uninstall that SmartApp, those URLs will no longer function, as that id has been deleted on our side. Our error messaging of “This request is not authorized by the specified access token” doesn’t make that particular scenario clear, admittedly. The access token should still be valid, but your URL’s would have to be altered to contain the new installed SmartApp id. For reference, here is an example URL I just copied off of that page for a switch, with identifiers substituted with colon-prefixed placeholders:

https://graph.api.smartthings.com/api/smartapps/installations/:installed_smart_app_id/switches/:switch_id/off?access_token=:access_token

The :installed_smart_app_id placeholder would have to be substituted with a new value, and probably also switch_id if it were a device that had been deleted, in order for that :access_token to still cause the same effect as before.

If you want to go this route and need to know which id to substitute for the :installed_smart_app_id, we have an endpoint setup for such a purpose (https://graph.api.smartthings.com/api/smartapps/endpoints), documented here in Step 8, which should work with the access token you already have: http://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/implementation.html

You also could reenter that OAuth flow initiated here http://labs.smartthings.com/exampleOauth.php and copy/paste the new URL’s.

So in summary: http://labs.smartthings.com/exampleOauth.php causes a SmartApp to be installed to your location, and if you uninstall it, issues will arise in the places you have related URL’s hardcoded.


(Convinced ST will never be unbroken…) #16

Thanks Luke,

A couple of things here:

The copy of the Endpoint Example SmartApp that was installed at 2014-09-29 20:47:24 UTC was to replace the ones that were broken.

Based on your description, I uninstalled this mystery SmartApp. I could have only done that when removing the unconnected CA3750, as removing a device from SmartThings forces you to delete all apps associated with that device beforehand. That/those was/were the only device/apps removed.

If this is indeed the case, I have to say that this is quite the mess. It seems to mean having to re-pair a device that lost connectivity would destroy all of the user’s current endpoints (correct me if I am wrong).

So where does this app live (and what is its name), so I can be sure not to delete it again going forward?


(Jody) #17

I believe this happened to me today as well. I was under the impression that uninstalling a SmartApp for a single device would not delete that smart app for all of my devices. The only way I could remove a problematic sensor was to uninstall the SmartApp, which in turn destroyed all of my endpoints.


(Luke) #18

Re-pairing a device involves first deleting a device, which makes it impossible to address it in the same way as before (because the identifier used to reference that device was deleted…not much we can do here). Meaning any API endpoint that did something with that particular device by its id would be affected, but other API endpoints would not.

Uninstalling a SmartApp, however, is different. The platform currently forces deselection of devices from SmartApps before allowing deletion as they very well could be integral to the correct functioning of the SmartApp. You aren’t forced to necessarily uninstall the SmartApp, but can instead deselect the device from the SmartApp’s preferences, which would preserve the id’s necessary to keep all API endpoints functioning as before (except any endpoints which reference the deleted device). This can be more complicated when the SmartApp in question is connectable via OAuth, as it is in this case, since it is not visually obvious what the ramifications of uninstalling the SmartApp may be.

The app is called “Endpoint Example”, it is installed for everyone who follows the OAuth flow initiated by http://labs.smartthings.com/exampleOauth.php , and it doesn’t show up in the main Dashboard area of the mobile app after being installed, but can be seen in the web UI at https://graph.api.smartthings.com/ if you click “My Locations”, then “smartapps” (under the location in question).


(Convinced ST will never be unbroken…) #19

Ok… I see it there. So just to be clear, how did I delete it? By deleting all apps associated with the CA3750 in the mobile app?


(Luke) #20

Yes, that would be my guess. For reference, here is what this would look like from the mobile app perspective. I’m hoping these render correctly and in the order that I am hoping for. :slight_smile: