webCoRE Update v0.3.10a.20190223 - adds $twcweather to replace discontinued $weather, bug fixes


`$twcweather.forecast.temperatureMax[0]’ returns empty… using [1], all the way up to 8 (that I tested) returns valid values.

Is this a known issue?

Using $twcweather.forecast.temperatureMin[0] works as expected.


Depends on the time of day… index [0] relates to Daytime today, therefore if you are checking index [0] at nighttime, it will return null as that time has already passed.

Index [1] = tonight
Index [2] = daytime tomorrow etc. etc.


I have my dense hat on apparently.

I simply want to get a reading of the forecasted high for the day. I do my check at 3am. So what index should I use because yes, at 3am I get 0 if I use [0].

As reported above, Min[0] does return me a real value when I check at 3am.


Use $twcweather.forecast.temperatureMax[0] || $twcweather.conditions.temperatureMax24Hour for today’s high I guess.

The morning and night distinction only applies to the data under forecast.daypart (see forecast.dayOfWeek, $twcweather.forecast.temperatureMax is a 14 day forecast but dayparts splits night and day)

We don’t have any real documentation to tell us exactly what the values mean. I see the null on temperatureMax as well (night time currently). Is it possible that it changes to null once the high temperature has passed? That would really suck.


I think I’m going to have to patch in these missing numbers from $twcweather.conditions.temperatureMax24Hour. What a lousy API to drop values like that, it’s unreasonable to require everyone to tiptoe around those null values in pistons

I’m going on 27 hours without electricity but if I have power and internet tomorrow I’ll try to figure something out.


Thanks Ian. Hope you get power back soon.


Is there an API for conditions for .cloudCover? Right now it seems that there is only .cloudCoverPhrase. In the forecast.daypart there is .cloudCover that returns an integer.


My guess is that cloudCover indicates the percentage of cloud cover (i.e., 0-100).



returns null also.


For now all I can recommend for those of you who need forecast data for the current day is to set up a piston to run every morning after 7am and store the values you need to global variables then use those instead of the potentially null [0] slots.

If we’re able to patch over the missing data in webCoRE it still won’t cover a few metrics that do not have counterparts in the conditions data.

Would someone please search the ST community for discussions of this problem, or start a new discussion to make sure other smart app developers are aware of the data issues? Then link the thread back here for reference.


Yup. That was my guess. However, conditions.cloudCover is not available and is only available in the dayPart API. Was just wondering if this was whether the original API that ST gets does not have that field, or was accidentally overlooked on the webCoRe end.


We’re just using the ST functions directly so all the data is unmodified from what is available to all smart apps via ST. It looks like they pulled only some of the Weather Company data endpoints but I haven’t compared every field to see what was missed on any specific endpoint like conditions or forecast. It looked like they map snake_case_names to camelCaseNames so it’s possible that it’s not a 1-to-1 clone of the Weather Company data, but also possible that the source data is lacking.


Hi @ipaterson,

Greetings! I noticed you mention there’s no hourly forecast available for the new API, if so what would you recommend to get similar function with new API? I have a piston checking future 1 hour weather to decide the time for lights to turn on.

And also can you help to get a list of possible values for conditions.wxPhraseShort ?

Many thanks!


You will need to find weather smart apps to fill in data that is not available in the TWC API.

Sorry, but we have not found any public documentation for the API that SmartThings is using. Some fields seem to correspond to this Weather Company REST API documentation or this PDF or a few random Google docs that come up in searches, but nothing is 1-to-1 with the data we see coming from SmartThings (docs are for v1 API but I think ST uses the new v3).

That PDF describes the value of wx_phrase as “257 phrases” with no examples which is probably not helpful to you. It is also probably larger than the number of short phrases which may come from blunt_phrase or terse_phrase or a different API entirely.

I am reaching out to a few people who may have more info about this API so that we can track down docs and stop the guesswork!


Thank you for the information Ian, I just learned from another thread that AccuWeather provides hourly forecast for free registered users, might as well do an HTTP call to the API and get it, plus it’s well documented!


do you have a link to this? i might try to set this up as well


Here is the thread:


I used to use the snowfall.day, nighttime etc.

Now there for static values, there is only snow1Hour, snow6Hour and snow24Hour which is unfortunate, but what are the intervals in the array $twcweather.forecast.qpfSnow[0],$twcweather.forecast.qpfSnow[1], etc? I assume they are daily since they are in the forecast group.

What are the intervals for $twcweather.forecast.daypart[0].qpfSnow? i.e. hourly?

Also, the same for $twcweather.forecast.daypart[0].snowRange

We are currently going to get 7.3 inches (valiated by the $twcweather.forecast.qpfSnow[0]), but none of the 2 above (going out [1],[2].[3] + all come back with 0.


Based on the day names and day part names in the data we believe the forecast values to be daily for 14 days and the daypart values to be morning and evening always beginning with the morning of the current day. We don’t have access to any documentation for the data the SmartThings is using so operating on best guesses. No idea why the day part data would be so drastically different from the daily forecast.



daypart shows an array of:


So what are all the values? If they are day and night, I would think there would be only 2 array values.