Matching rain corrections with weewx and Weather Underground

[J]

Hi,

I'm trying to apply some corrections to my rain data but am running into an issue with getting Wunderground data to match.

I want to adjust my rain corrections based on wind data -- I'm compensating for undercatch during high winds due to my rain bucket's higher than typical elevation above ground. I'm using a Davis VantagePro2.

Making corrections to rain and rainRate using windGust works great in weewx. Each 0.01" tip is adjusted by current wind conditions. However, Wunderground values are uncorrected. From some reading of past threads, it sounds like Wunderground data may instead use dayRain and hourRain values directly from archive records, instead of simply pushing up the weewx values. I run into the issue that if I try to adjust dayRain and/or hourRain based on wind from the archive records, not only will the totals differ because of wind values from different periods, but it seems like the entire day total would be repeatedly scaled up and down based on whatever the last wind reading was.

Is there a way to have the data sent to Wunderground based on the totals stored by weewx? Or otherwise keep them synced in a sane manner?

Thanks!

Jesse

P.S. I'd also love to be able to use windDirection and rainRate as factors in the corrections, but that's probably overly ambitious without support for conditionals in corrections.

[Thomas Keffer]

The value sent to wunderground is calculated directly from the database. It's the sum of all rain that fell during the last 60 minutes. So, if you're happy with the values of 'rain' in the database, then you should be getting the same at wunderground. 

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[J]

Hmm, perhaps I just didn't wait long enough then. My values definitely diverged, so I removed the correction so avoid having to correct a lot of data.  Does wunderground calculate an intermediate value from uncorrected values sent via rapidfire, which then get replaced once per hour by the database values? Or is the 60-minute sum sent with each update? If the latter, perhaps it was just a difference in wunderground's rounding (or lack thereof).

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[Thomas Keffer]

I have no idea how they factor in RapidFire values: they don't publish that.

RF is a black box, that they don't seem to be paying much attention to.

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

[mwall]

On Friday, January 13, 2017 at 9:21:39 PM UTC-5, J wrote:

P.S. I'd also love to be able to use windDirection and rainRate as factors in the corrections, but that's probably overly ambitious without support for conditionals in corrections.

jesse,

you can use conditionals in corrections:

[StdCalibrate]
    [[Corrections]]
        outHumidity = 99 if outHumidity > 100 else outHumidity

each correction must be a single line of python

m

[J]

Thanks for your responses and please pardon my late reply -- I wanted to wait until some more rain fell to confirm observations and gather more detailed logs.

It appears that the standard Wunderground-PWS archive method posts the corrected values, but Wunderground-RF rapid fire submits a combination of corrected and uncorrected values. I'm unclear on where the uncorrected value is being pulled from.

For reference, the uncorrected value (as displayed by Davis console) at the time of the below logs is 0.6 inches. With the weewx corrections it's (rounded up to) 0.7. The discrepancy has persisted and widened as more rain has fallen throughout the day.

Wunderground-PWS:  both dailyrainin and rainin show the corrected 0.7:

Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=YYY&PASSWORD=XXX&softwaretype=weewx-3.5.0&windgustmph=3.0&humidity=095&dailyrainin=0.07&winddir=270&tempf=50.8&windspeedmph=1.0&rainin=0.07&baromin=29.805&dewptf=49.4&dateutc=2017-01-19%2012%3A47%3A00

Jan 19 04:47:16 weewx[2009]: restx: Wunderground-PWS: Published record 2017-01-19 04:47:00 PST (1484830020)

Wunderground-RF rapid fire:  dailyrainin has the uncorrected value (0.6), but rainin uses the corrected one (0.7).  WU appears to use the dailyrainin value for it's displayed precipitation totals. Log:

Jan 19 04:47:16 weewx[2009]: restx: Ambient: url: http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=YYY&PASSWORD=XXX&softwaretype=weewx-3.5.0&windgustmph=5.0&humidity=095&dailyrainin=0.06&winddir=247&tempf=50.8&windspeedmph=5.0&rtfreq=2.5&rainin=0.07&baromin=29.807&dewptf=49.4&dateutc=2017-01-19%2012%3A47%3A16&realtime=1

If I enable both methods, I can see the displayed value on WU bounce down to 0.6 after the Wundergrond-PWS submission, then back to 0.7 with the next Wunderground-RF submission.  This bouncing back and forth is also reflected occasionally in the WU graphs.

mwall wrote:

jesse, you can use conditionals in corrections:  [...]  each correction must be a single line of python

Awesome, thank you!

- jesse

On Friday, January 13, 2017 at 6:40:17 PM UTC-8, Tom Keffer wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[Thomas Keffer]

The URLs you have posted show values of 0.06 or 0.07, but your narrative talks about 0.6 and 0.7. I assume the former is correct and the latter is just a typo?

The value for dailyrainin comes from field dayRain in the current record, which, in turn, is pulled off the Vantage weather station. This is why it matches what you see in the console.

If you want the dayRain to match the sum of 'rain' since midnight, it would have to be "corrected" by the same factor.

Frankly, correcting for the effects of high winds by boosting rain is no substitute for correct placement of your ISS. I also live in a high wind area (the Columbia River Gorge) and don't have any problems with rain. I would leave it alone.

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

[J]

Yes, 0.6 and 0.7 were typos, 0.06 and 0.07 are the intended values.

Thanks for the pointers -- I think I understand and am sorted now. Since dayRain is provided by Vantage console in the loop packet but not the archive packet, weewx uses the console's straight value for the former and generates a database-SUM-of-rain value for the latter.

Applying a matching correction to the loop packet's dayRain value wouldn't work out afaik for anything that depends on the value of second weather variable, as it'd keep applying the latest correction to the entire dayRain value. However with those pointers I was able to modify restx.py to generate dayRain from the database even for loop packets. I'm now getting consistent, corrected values for rapidfire (as well as archive_post, as was the case before) which match weewx's database.

I agree completely on corrections being no substitute for proper station siting or accurate, properly calibrated instruments. Alas, station siting in urban environments always involves some compromise. Luckily the amount of undercatch due to wind turbulence from increased height above ground level has been the subject of some study and papers over the decades and is relatively predictable. Much more so than the impact of heavy rain shadowing, my only other option. With the new rain corrections my readings are now in the same ballpark as my neighbor on the same block -- whose Vantage Vue is sited optimally for rain and temperature readings, but terribly for wind readings. 

Thanks again for the guidance and excellent software!