As we prepare for increased SmartThings adoption across different geographies, we’re upgrading our infrastructure significantly. These changes will enable us to scale horizontally as new hubs and devices come online. We’ll have infrastructure located close (geographically) to new customers to reduce latency as much as possible.
One result of this is that SmartApps or Device Types which provide the URL http://graph.api.smartthings.com to external services will need to be updated (this is most typical in Service Manager SmartApps that connect with a third party service). Instead of hard-coding the URL for the graph server, developers should utilize the getApiServerUrl() or apiServerUrl() methods (discussed below). This will ensure that the URL returned is the correct, region-specific, URL.
Action Required by Developers
Hard-coded references to “http://graph.api.smartthings.com” should be updated to use APIs that will get the correct server URL for this installed instance of a SmartApp or Device Type Handler:
getApiServerUrl() returns the URL of the server where this device type or SmartApp is executing.
apiServerUrl(String path) returns the URL of the server where this SmartApp or Device Type is executing, along with the specified path appended to it.
Timeline
getApiServerUrl() and apiServerUrl() are currently available for use. Any references to http://graph.api.smartthings.com should be updated to use the APIs discussed above now.
These infrastructure changes will be rolled out in early-to-mid September 2015. At that point, if you are hard-coding http://graph.api.smartthings.com as discussed above, you will not be guaranteed that the SmartApp or Device Type is reachable at this URL.
As mentioned in another thread, I like where this is all headed… beefing up everything in preparation for what’s coming… perhaps especially after IFA, I cannot wait!
Honestly you’d be shocked at the BIG name companies who do nothing to bulk up their services in advance of a planned announcement, that they KNOW will generate a huge amount of traffic, then throw their arms up and cry foul when all their stuff goes down because it has been massively overloaded…
WOW, there are going to be A LOT of developers that are going to have to make updates to their code, myself included. I’m really happy we got a heads up on this and luckily the changes are minor, but as devices, and smartapps become more complex and numerous 30 days notice would be really appreciated. Not just for code update and testing but so that enough users have a chance to get it installed before they are potentially negatively impacted. I also hope our API docs get updated in time too, i know that the documentation guys have been busy rocking out all sorts of goodness.
I have a feeling September is going to be a really GOOD month!
How will that work with the upcoming v2 local processing? Will use of one of the above two API’s disqualify a device type (or smartapp) for local processing, will the API return “localhost”, or will it return a ST server that will somehow communicate with the locally processing code?
Hi @garyd9,
This changes only affects SmartApps or Device Types that require external services and if that’s the case they can’t run locally since they depend on an internet connection.
Hope this helps!
Thank you, @juano2310. However, as was just recently announced, it’s a completely moot point as user apps (or device types) won’t be allowed to run locally anyway.
We will add more details about local SmartApps in the coming days to make it super clear. The goal is for anything that is possible to run locally (ie everything but cloud-to-cloud connected devices) to be able to operate even when your internet connection goes down. Beyond that, the goal is to enable them to work for a period of time when your power goes out for all local, battery operated devices.
If Community created device types require cloud to operate, then individual devices using those device handlers won’t operate if the Internet is down right? That’s a really big deal. ( thinking of door locks on rental homes, for example)
yep. That’s why I’m “having a cow” in various threads right now. We’ve been waiting so many months for the promise of local processing… (because, honestly, what else does v2 really offer that’s enabled other than video? )
I also hope our API docs get updated in time too, i know that the documentation guys have been busy rocking out all sorts of goodness.