Using the weather feature

[ChicoQuente]

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.

[WCmore]

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.

[newhere17]

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?

[Gopack2]

$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

[Gopack2]

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

[newhere17]

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

[Gopack2]

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

[newhere17]

yes of course.
yes I would like to try it with your device handler.
do you have a manual or something else?

[Gopack2]

Here is the github location.

Gopack2/A-Better-Weather-Tile-1.0

Found this on weather underground. You could add the info from this into the zip code preferences for each location you are setting up

[WCmore]

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…

[pauly]

I have the exact same intension for lights automation:

[tw1st3d7550]

@Gopack2 Thanks for creating and sharing the device handler! I just installed and boy am I impressed!

[WCmore]

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)

[pauly]

I wasn’t, if you take a closer look I’m actually assigning to that string $forcastText, then just doing comparison in below

[WCmore]

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.

[pauly]

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

[WCmore]

Your observation is correct.

I pull weather data fairly often, and for me, it returns a zero or null about 1% of the time.

Here is a sample of 504 data pulls. (every 20 minutes)
Notice the 3 failures on the far left came back 0.

If you are ok with a 1% failure rate (that’s about 4 times a year on daily pistons) then I would just roll with it, and point your code to the variable instead of the long link. Your piston structure is well written, so even on a bad data pull, it will default to -35 minutes, as seen in line 47.

---

Food for thought:
On a repeating piston, one work around that I do is to capture the new data in a different variable than the previous data. The piston then checks to see if the new data is within an acceptable range. If it is, it continues on with the code. If the new data is null or outside the range, then the piston will re-use the old data once. (I am sure there is a modified version of this that could work for you as well)

This works quite well, since it is VERY rare to have two failures in a row. (if enough time has passed)

[pauly]

Well, your observations may be true for constant calls daily, but I updated my piston to assign weather value to the variable twice, still it has no value…

Here’s the variable value:

[WCmore]

Your line 28 & 30 should be using an expression, not an argument.

---

Also, the variable will NOT update when you press the Test button.
It only updates it when the time matches.

[pauly]

Let me try, also it was running and did not update, I didn’t test.