If you find out any more I’d appreciate if you can share.
I was only able to do a quick test upon seeing your post and found the output at the time was 22. Upon looking outside the coverage was fairly low which is why I assumed how it works. Hopefully we get some confirmation sooner than later. I guess for now I will keep my eye on it but not officially start using it in script.
In the meantime, I can say that the AccuWeather built in cloud coverage is quite accurate… The half dozen times I have randomly compared the two numbers they were between 30-50 points difference. This is why I have not used the ‘sky’ code yet in my pistons.
I have started an analysis running every ten minutes comparing AccuWeather’s cloud coverage to WUnderground’s ‘sky’ number. I will report back here in about 24 hours with my findings
Alright, so here is the update. I logged two data points every ten minutes for 3 days here.
You be the judge…
Blue (built-in code) $weather.hourly.hourly_forecast.sky[0]
Red (Accu-Weather plugin) Cloud Cover
*PROS (BLUE) WUNDERGROUND:* | *PROS (RED) ACCUWEATHER:*
Updates more frequently | No False reads
―――――――――――――――――――――――――――――|―――――――――――――――――――――――――――――
*CONS (BLUE) WUNDERGROUND:* | *CONS (RED) ACCUWEATHER:*
Many false data reads at 0 | Less frequent updates
| More 'blocky' data
Side note… The 4 times I went outside happened to be when the two data points were fairly close to each other… so I cannot speak on accuracy yet… It does seem like both data points are trying to convey the same trends though…
That’s a great post! Thanks for putting in the effort to log and share your findings. It’s tough to say which route to go at this point. I like the idea of less devices and more updates by weather underground but the more frequent 0’s is tough as well.
Yes, I agree. Also be aware that WUnderground has also warned us that they plan to pull all free API calls… (not sure if that affects us webCoRE users though or not, but I would venture to guess that it will)
If you decide to go the WUnderground route, here is my strategy to bypass the incorrect data points.
Hi,
is it possible to get the value for Quantitative Precipitation Forecast from yesterday?
the code for today is:
integer($weather.forecast.forecast.simpleforecast.forecastday.qpf_allday.mm[0])
tomorrow:
integer($weather.forecast.forecast.simpleforecast.forecastday.qpf_allday.mm[1])
but for yesterday?
$weather.yesterday.precipi
Or
$weather.yesterday.precipm
I believe
Check out weather underground api documentation pages. It gives all the weather options tgat you can use. You just don’t need the api address and key, tgat is substituted by $weather
Nevermind that doesn’t work. Sorry
But this does.
$weather.yesterday.history.dailysummary[0].precipi
The 0 is for yesterday. If you change tgat to go back even further in days
what is the difference between precipm und precipi?
okay. so this is yesterday:
$weather.yesterday.history.dailysummary[0].precipi
and this is two days ago:
$weather.yesterday.history.dailysummary[1].precipi
because it rained all day, 4 days ago. and the count from the statement is 0
Ok, first thing that needs to be stated. Weather underground is very unreliable when it comes to certain reporting, in my opinion. The information is being supplied from airports, and private users. If a particular station does not repor info fast enough, or enough info your results will vary. That is from what I have found at least.
Now, precipi is imperial or inches, precepm is metric or mm I believe.
There is also a precip, not sure if that is suppose to be the qpf or not.
I guess, since current conditions qpf from today seems to be a little more accurate, I would set up a piston to grab a snapshot at 11:59pm and have it save that to a variable named {yesterdayRain}.
**** Shameful plug here **** I wrote a custom device handler that allows you to monitor up to 3 locations, besides your home hub location. You can get the info by zip, lat/long, state/city. And sometimes airport Cor, or actual weather station code will work pws;{code}
It also lets you gather just about all the different data via webcore drop down for the physical device attributes. I always hated trying to remember all the different syntax to get what I wanted. So now it’s point and click for me
Let me know if you want link to device handler it’s on github. I basically adapted weather station tile device handler and added locations and exposed more of the weather condition data to the device handler
yes of course.
yes I would like to try it with your device handler.
do you have a manual or something else?
Here is the github location.
Found this on weather underground. You could add the info from this into the zip code preferences for each location you are setting up
I just wanted to give you all an update…
I pulled up my Fuel Streams, and it appears the two data sources are getting a bit closer to agreeing with each other. (written every 10 minutes for the past 7 days)
Blue (built-in code) $weather.hourly.hourly_forecast.sky[0]
Red (Accu-Weather plugin) Cloud Cover
The analysis hasn’t changed much, but the two percentages (and trends) are more in agreement than before. (although there are still short periods of time where there was +35% difference between the two)
*PROS (BLUE) WUNDERGROUND:* | *PROS (RED) ACCUWEATHER:*
Updates more frequently | No False reads
――――――――――――――――――――――――――――――|―――――――――――――――――――――――――――――
*CONS (BLUE) WUNDERGROUND:* | *CONS (RED) ACCUWEATHER:*
A few false data reads at 0 | Less frequent updates
| More 'blocky' data
I admit, I like the rate of updates and the level of accuracy from the Wunderground (built-in) query, but I like the reliability of the AccuWeather plugin…
I am currently pulling both data points as conditions in my early sunset piston, but am contemplating only using one of them.
*sighs*
Decisions, decisions…
I wonder if averaging the two into a new number will give me better accuracy for cloud coverage…
@Gopack2 Thanks for creating and sharing the device handler! I just installed and boy am I impressed!
I like your structure @pauly, but wouldn’t it be more efficient to only pull data from $weather.hourly.hourly_forecast[0].icon ONCE instead of potentially 38 times?
Maybe something like this (based on your code)
This limits the external web request to only happening once per piston run. Notice this piston grabs the current data at the very beginning, and then all other references in that piston simply refer to the variable. This should keep duplicate requests from hammering their server. (which will hopefully encourage IBM to keep this information free to us)
In all likelihood, if we abuse it too much, they will start charging a fee to access the weather API.
(There is already talk about it happening)
I wasn’t, if you take a closer look I’m actually assigning to that string $forcastText, then just doing comparison in below
Maybe my eyes are failing me, but I only see ONE reference to $forcastText in your entire piston. Yes, you write to it, but none of your code refers back to it like my example above.
It is pistons like this that will practically guarantee that IBM starts charging money for the weather data.
OK I remember for the reason of doing this now, I tested with this and very often I don’t get the value in the forecast, that’s why I waited one minute and start checking again, it you test yourself you will only find the variable to be null.
Thanks for pointing out and me I’ll set the variable again to see if it gets the value
