[weewx-development] Re: How to implement rain and rainRate fields in a new driver?

2020-03-08 Thread Bill Burton
Hello Gary,

Thank you so much for the thorough reply with all the tips on how to 
implement rain field functionality!

Just to be clear, the interval the driver receives a loop packet is 
controlled by the driver's polling interval, not by the station as the 
driver is polling the station's computer. So in the case of tracking rain, 
I'm thinking to go ahead and return the rain delta in the loop packet every 
10 seconds (every polling interval) as the eventual delta over the five 
minutes archive interval would be exactly the same as if I returned the 
delta only once a minute. The logic is also simpler to return the delta 
with every loop packet.

Best regards,
-Bill

On Saturday, March 7, 2020 at 7:37:08 AM UTC-5, gjr80 wrote:
>
> Bill,
>
> My two cents. This is a very common situation, many stations provide one 
> (or more) cumulative rainfall values. Since WeeWX requires a per-interval 
> or delta value all you do is pick one of the cumulative rain values (in 
> your case Rain Today is the obvious choice) and calculate the difference 
> between successive readings. There are a few things to be careful of, what 
> happens if one of the values (the current or the previous) is None, what 
> happens on startup when there is no previous value and what happens when 
> the cumulative value resets to zero (eg a midnight reset) or the counter 
> clocks over. All easily handled. You can probably pick just about any of 
> the drivers except vantage and find that is how rain is calculated. There 
> is even a function calculate_rain() in bin/weeutil/weeutil.py that will 
> do it for you.
>
> A cautionary word on rainRate, it means many things to many different 
> people but typically rain rate is expressed as a per hour value rather than 
> per five minutes. One other option to consider is to omit rainRate from 
> your driver entirely and let WeeWX calculate it as a derived observation in 
> the StdWXCalculate service. Or provide an option for the driver to either 
> provide it or omit it.
>
> Regards loop packets, some stations emit loop packets every so often, 
> others emit them irregularly and others have to be polled. Those that are 
> polled typically use a user defined interval and the results form the loop 
> packet. In your case I would expect to see your driver emitting loop 
> packets every 10 odd seconds. Just think of loop packets as higher 
> frequency packets of observational data from which WeeWX synthesises 
> archive records. The only thing to keep in mind is that if your sensors 
> update every two minutes there is little point in polling every two 
> seconds, but it sounds like you have are using an appropriate rate.
>
> Gary
>
> On Saturday, 7 March 2020 17:29:25 UTC+10, Bill Burton wrote:
>>
>> Hello,
>>
>> I'm implementing a driver for the Columbia Weather Systems MicroServer 
>> that supports a variety of their weather stations including the Pulsar 600. 
>> However, I'm still not clear on how the rain field is to be mapped. Right 
>> now, I only have rainRate mapped but I've not been able to find how to map 
>> the rain field. The available rain data fields that might be applicable are:
>>
>>- Rain Today (accumulated rain for the day in inches since midnight)
>>- Rain Last Hour (accumulated rain for the past hour in inches)
>>- Rain Rate (inches for past 5 minutes) --> currently mapped to 
>>rainRate
>>
>> Note that this weather station uses Doppler radar and does not have a 
>> bucket or other moving parts. There's also no concept of loop packets as 
>> each request for data returns XML with all the fields as a record which are 
>> returned as a loop packet by the driver. Right now I have the driver 
>> configured to poll the station every 10 seconds. That frequency is only so 
>> wind speed and direction can be displayed on a more frequent basis.
>>
>> If there are any existing drivers that handle rain in a similar way that 
>> I could reference, that would be very helpful to know.
>>
>> Thanks for any input,
>> -Bill
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/5244b730-f520-4f6f-8dbb-2f687ebe8d09%40googlegroups.com.


[weewx-development] Re: How to implement rain and rainRate fields in a new driver?

2020-03-07 Thread gjr80
Bill,

My two cents. This is a very common situation, many stations provide one 
(or more) cumulative rainfall values. Since WeeWX requires a per-interval 
or delta value all you do is pick one of the cumulative rain values (in 
your case Rain Today is the obvious choice) and calculate the difference 
between successive readings. There are a few things to be careful of, what 
happens if one of the values (the current or the previous) is None, what 
happens on startup when there is no previous value and what happens when 
the cumulative value resets to zero (eg a midnight reset) or the counter 
clocks over. All easily handled. You can probably pick just about any of 
the drivers except vantage and find that is how rain is calculated. There 
is even a function calculate_rain() in bin/weeutil/weeutil.py that will do 
it for you.

A cautionary word on rainRate, it means many things to many different 
people but typically rain rate is expressed as a per hour value rather than 
per five minutes. One other option to consider is to omit rainRate from 
your driver entirely and let WeeWX calculate it as a derived observation in 
the StdWXCalculate service. Or provide an option for the driver to either 
provide it or omit it.

Regards loop packets, some stations emit loop packets every so often, 
others emit them irregularly and others have to be polled. Those that are 
polled typically use a user defined interval and the results form the loop 
packet. In your case I would expect to see your driver emitting loop 
packets every 10 odd seconds. Just think of loop packets as higher 
frequency packets of observational data from which WeeWX synthesises 
archive records. The only thing to keep in mind is that if your sensors 
update every two minutes there is little point in polling every two 
seconds, but it sounds like you have are using an appropriate rate.

Gary

On Saturday, 7 March 2020 17:29:25 UTC+10, Bill Burton wrote:
>
> Hello,
>
> I'm implementing a driver for the Columbia Weather Systems MicroServer 
> that supports a variety of their weather stations including the Pulsar 600. 
> However, I'm still not clear on how the rain field is to be mapped. Right 
> now, I only have rainRate mapped but I've not been able to find how to map 
> the rain field. The available rain data fields that might be applicable are:
>
>- Rain Today (accumulated rain for the day in inches since midnight)
>- Rain Last Hour (accumulated rain for the past hour in inches)
>- Rain Rate (inches for past 5 minutes) --> currently mapped to 
>rainRate
>
> Note that this weather station uses Doppler radar and does not have a 
> bucket or other moving parts. There's also no concept of loop packets as 
> each request for data returns XML with all the fields as a record which are 
> returned as a loop packet by the driver. Right now I have the driver 
> configured to poll the station every 10 seconds. That frequency is only so 
> wind speed and direction can be displayed on a more frequent basis.
>
> If there are any existing drivers that handle rain in a similar way that I 
> could reference, that would be very helpful to know.
>
> Thanks for any input,
> -Bill
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/e1ebde1a-88d3-4088-8195-8aa9bf6f56c1%40googlegroups.com.