SmartThings Community

Weather API Changes


(SmartThings) #1

The WeatherUnderground (WU) APIs SmartThings has been using to access local weather data are being shut down at the end of this year. This means any Automations or Devices that use the getWeatherFeature() method will stop running or begin returning errors on January 1, 2019.

We are taking steps to ensure that the SmartThings SmartApps and the SmartWeather Station Tile device handler will continue to work by porting them to new APIs from The Weather Company (TWC). These will be released into Production this week and there will be no gap in performance. To maintain your SmartApps and device handlers, we have exposed the following methods for SmartApps and Device Handlers to replace getWeatherFeature().

def getTwcConditions(String locationString=null)
Current weather conditions

The optional locationString argument must be a 5 digit US zip code or a latitude, longitude string (e.g., "38.25,-76.45"). If it is not specified, the method will use the latitude and longitude of the location as set in the mobile app.

Example getTwcConditions response

def getTwcForecast(String locationString=null)
Daily weather forecast at the specified location

The optional locationString argument must be a 5 digit US zip code or a latitude, longitude string (e.g., "38.25,-76.45"). If it is not specified, the method will use the latitude and longitude of the location as set in the mobile app.

Example getTwcForecast response

def getTwcLocation(String locationString=null)
Location data, such as time zone and zip code at the specified location

The optional locationString argument must be a 5 digit US zip code or a latitude, longitude string (e.g., "38.25,-76.45"). If it is not specified, the method will use the latitude and longitude of the location as set in the mobile app.

Example getTwcLocation response

def getTwcAlerts(String geoLocation=null)
Current severe weather alerts at the specified location

The optional geoLocation argument requires a latitude & longitude string (e.g., "38.25,-76.45"). Zip codes are not supported in getTwcAlerts().

Example getTwcAlerts response

def getTwcAlertDetail(String alertId)
Detailed description and text of the specified weather alert

The alertId argument comes from the result of the getTwcAlerts() method.

Example getTwcAlertDetail response


Final note: If you are considering the development of an application that makes extensive use of detailed weather data, you should look into gaining direct access to APIs from a weather data provider such as TWC or others.


Weather Underground Web Smartapp: the "poor guy" weather station with event based switches automation
Smartweather Station Tile Update showing totally wrong data
(Brian) #2

Bummer. I assume this means we can’t point to an individual personal weather station anymore…


(Neil Oakley) #3

The first question that came into my head too. Only reason I like the Weather tile so much is it tells me the weather at my house, from my PWS on the roof that uploads to Weather Underground.


(Paul Haskins) #4

And Ditto…


(www.rboyapps.com - Make your home your butler!) #5

If I’m reading this correctly the changes would be transparent to the user and SmartApps which are using the WeatherTile. I.e. you should continue to be able to use the Weather Tile without any issues. It only affects apps which are using specific features of the weather tile API, getWeatherFeature.


(Working on a secret project, are we, sir?) #6

I would completely abandon WU… I have been in talks with them and the only way to get the same weather info after Dec. 31 will take 3 API calls from IBM’s new API.


(Neil Oakley) #7

I read it as ST are cutting links with WU, and moving to source data from TWC instead using a zip code or lat/long.

Within the current WU setup, you can call data from a specific weather station by using the PWS ID. TWC does have the same capability - so it’s another nail in ST’s coffin if you ask me, and another backwards step.


(www.rboyapps.com - Make your home your butler!) #8

If WU is shutting down the API not sure what ST can do about it. There are custom weather station devices also but they also depends on WU API - which if shutdown won’t work either. So the question is does TWC allow for more specific control in place for a zip code? I’m not sure since I haven’t researched it yet. The question is are you using the specific station because it provides additional data or more accurate data compared to zip code data?


(Neil Oakley) #9

Yes - specific name because it is hyper localised and more accurate. My weather station is on my roof and properly calibrated. It send data to WU and ST calls it back. There is still a support WU API, but requires work for ST to implement.


(Paul Haskins) #10

API and such are over my head, but doesn’t Weatherlink (Davis Instruments) have an API?

I know a lot of the PWS use Davis. I do and use it to post to WU and CWOPS.


(Benji) #11

As a slight side note, what weather station do you guys use and how well does it integrate with SmartThings directly (aside from through what was available with WU)?


(Jason "The Enabler" as deemed so by @Smart) #12

WU announced about a year ago they were doing away with the api, that is the same time that they stopped issuing new keys.

If you a WU key, you can modify the app to use that.

If you don’t, you can use something like the netatmo weather station.


(John) #13

IBM bought TWC, TWC bought WU.

Supposedly they are grandfathering people with a PWS and will provide us access to our own data. I’m not sure what that looks like yet.


(Working on a secret project, are we, sir?) #14

It looks like shit… IBM proposal is you will have to make 3 API calls for the same info the WU API single offered.


(John) #15

Do you have a PWS? It looks like they are basically leaving us alone.


(Working on a secret project, are we, sir?) #16

I have 3 stations…

According to Victoria from the TWC/IBM team member we will keep our free key but will have to use the same API’s to get our data.


(Neil Oakley) #18

I have two, both upload to WU and both are used with Smartthings Weather device. As long as there is a solution that means I can still get data from my weather stations into SmartThings, then i’ll Be happy.


(Neil Oakley) #19

So i guess I have to sit and wait and see what they come up with, then home someone builds a new Device Handler or SmartApp that can make use of the data?


(JIm) #20

I have a smartapp of my own that I was using to get weather alerts. Started playing around with the new stuff here and a little lost about 1 part. I can get things like temperature, etc with no problems. But when it comes to the alerts I’m not sure of the exact syntax. Could someone point out what it should be. Me not being that good a programmer. Here is what I have done.

def wxalerts = getTwcAlerts("36.67,-93.34")
log.debug "Alert = ${wxalerts.alerts.phenomena} Description = ${wxalerts.alerts.eventDescription} Office = ${wxalerts.alerts.officeCode}"

(Tony Fleisher) #21

Based on the examples in the documentation, it looks like the alerts property in the getTwcAlerts response is a list “alerts”:[…], so you need to either iterate the list or grab the first element (depending on your implementation needs) to get the structure that has the phenomenon and eventDescription properties.