Topic: API tag for precipitation

[sho23]

Hi all,

We currently poll the weatherlink API to get our data. For the most part it's been good, but I'm not understanding the precipitation.

When I am backfilling our database via manual browse-export feature, there are these parameter for rain:
Rain, Rain Rate.

But on the API, it's all totalized and reset at certain time length:
<rain_day_in>0.0000</rain_day_in>
<rain_month_in>0.0000</rain_month_in>
<rain_rate_day_high_in_per_hr>0.0000</rain_rate_day_high_in_per_hr>
<rain_rate_hour_high_in_per_hr>0.0000</rain_rate_hour_high_in_per_hr>
<rain_rate_in_per_hr>0.0000</rain_rate_in_per_hr>
<rain_rate_month_high_in_per_hr>0.0000</rain_rate_month_high_in_per_hr>
<rain_rate_year_high_in_per_hr>0.0000</rain_rate_year_high_in_per_hr>
<rain_storm_in>0.0000</rain_storm_in>
<rain_year_in>0.0000</rain_year_in>

So I am unable to reconcile the script that grabs the rain value using the API, and the rain value that I manually generate via export. Certainly, the one from export is more preferable because I can totalize it however we need. Is there a tag for basic "rain" that just reports for that 15 mins?

[sho23]

Bump

 

[Mattk]

Rain is typically cumulative and broken down into period values not individual packets and totalled and this way if packets are lost then rainfall is not lost as it is determined based on the running totals. To save period rain values for whatever archive interval set etc then this would need to essentially be done in realtime in order to determine running sequential intervals.

There would be so many different archive type intervals users could use it would be a little unrealistic to provide one that suits all.

[sho23]

Rain is typically cumulative and broken down into period values not individual packets and totalled and this way if packets are lost then rainfall is not lost as it is determined based on the running totals. To save period rain values for whatever archive interval set etc then this would need to essentially be done in realtime in order to determine running sequential intervals.

There would be so many different archive type intervals users could use it would be a little unrealistic to provide one that suits all.

I fully understand.

I'm just having a small confusion as to how we should be storing it in our database since the manual backfill export from Weatherlink is not cumulative, while the webscrape is cumulative. Hard to reconcile them as 1 time series. Which option is better?

1. Totalize the historical export log from weatherlink so it's same as API. We don't do backfilling that often so this may be okay to do.
2. Divvy up the webscrape API so it's now 15 mins data. The benefit is that we will be able to totalize it however we want later, albeit an extra step for each incoming webscrape.
3. I guess I can make a 2nd time series so they are totally separate and only process it together when needed.