It seems like none of my weather variables are working as of some time today. I have not made any changes to ST or WebCoRE in over a week.
Is anyone else experiencing issues as well?
i.e. {$weather.conditions.current_observation.temp_f} returns no value.
The ST logs are showing this:
4:11:19 PM: error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 83246859701685 @line -1 (error)
I have had a few down for about an hour. It usually fixes itself fairly quick…
(Although they have warned us they plan to pull the plug on all free API calls)
Well that would be bad if they pulled the plug. Unfortunately, some of my devices are going nuts, because I close doors (garage) etc based on the temps.
I wonder if there is a way to disable the pistons if there is no response from the weather calls. At least my phone wouldn’t be blowing up 
Here is a visual of every ten minutes in the past 3 days for the query:
$weather.hourly.hourly_forecast.sky[0]
It has pulled bad data about a dozen times a day (way more often than normal)
It is usually down for only one data check, but you can see the past hour it has not resolved yet…
I have other pistons programmed to compare current numbers to previous numbers, and then depending on the variances, do different things… But it requires a bit of coding in any piston that uses that service.
Well this is pretty crappy…
I have live local weather temps for those pistons I mentioned via various other sensors such as my Ecobee or outdoor sensors. I am just going to flip them all now.
In the past, I could usually expect 3-4 bad data points out of 1,000 queries…
This was somewhat acceptable… but 12 a day ain’t gonna cut it!
(should we blame IBM?)
The work around I have done in the past is basically:
Define variable wuThreshold = 10
Set variable wuDataOld = wuData
Set variable wuDataOldMin = wuDataOld - wuThreshold
Set variable wuDataOldMax = wuDataOld + wuThreshold
Set variable wuData = $weather.hourly.blahblahblah
If wuData is between wuDataOldMin and wuDataOldMax then do good stuff
Else, set variable wuData = wuDataOld
End If
This method basically allows for the occasional bad data to come in, and webCoRE will just re-use the previous data. (it works well if Weather Underground is only down for an hour or so)
The threshold at the top has to be tweaked to fit your location & query. I usually monitor the data point for a week to see what is the fastest the number has dropped (or risen) in a given time period, then add 20-30% to calibrate that number.
This has been very annoying lately. Since the weather data is provided by SmartThings’ getWeatherFeature we don’t have any direct control over error handling with the Wunderlist API.
The only solution I can think of here is to keep track of the last good value and return that when SmartThings returns a null value. I am assuming that it actually returns a null and doesn’t try to convert the value to something that would be difficult to distinguish from real data, like a number or empty array. I think that would require storing the entire weather data (or a reasonable subset of it excluding alerts and almanac data) and then handling the mapping for the $weather.forecast10day.forecast.simpleforecast.forecastday.qpf_day[2].mm format. When SmartThings fails to provide data it is pulled from the backup. My fear is that it will very likely be too much data to store.
With that in place, if you only use weather once a day the data would be very outdated. In that situation a piston could be set up to pull from $weather every half hour or so to ensure that the global weather backup data is recent.
Personally, I have never noticed a null response… From what I have seen, the bad data is usually either 0 (zero) or some arbitrary number that is out of place like this:
.................... High and low temps ....................
This is why I use the threshold method described in my last post.
(The fuel stream shown above I have not coded in my “threshold-reuse-old-data” yet)
Oh ok so it’s not necessarily zero each time, are those averaged in any way or just coming directly from $weather? If there is some incorrect but nonzero value coming back I’m afraid this seems more like a wunderground API bug…
All my live tests using the console always pulls the real data. I only notice the occasional drops if I use the fuel stream. (and 99% of the time, there is never two bad data points in a row)
To further elaborate, I think every error I have seen was always LESS than the real numbers. (don’t recall ever seeing it spike upwards) And I would venture to guess that about half of the data points are occasionally showing up as 0, and about half are just spiking downwards, but not reaching zero. (like the high/low example above)
Yes, this happens on about half of the queries… Although I want to say it is dependant on which data I am pulling. (ie: todays high and low are never zeros to my recollection)