Integrate rain24 with Packetsloop

[Remy Lavabre]

Good morning,

I created a [driver] for weewx to retrieve data from the Awekas API (my Bresser weather station does not have a USB port).

This works but regarding the rain, it is not the instantaneous rain (from a packetloop) that we recover but the rain over 24 hours since midnight.
Is there a "simple" way to tell WeeWX that the packetsloop rain data corresponds to the cumulative rain since midnight and not the rain that fell during the data retrieval interval (the time gap between two packetsloops) ?

Thank you so much...

[Tom Keffer]

Unfortunately (for you), WeeWX mostly uses observation type "rain", the amount of rain that fell since the last loop packet (what you are calling "instantaneous rain").

You should assign the rain since midnight to type "dayRain".

Then calculate "rain" as the difference between successive "dayRain" values. While this is a pretty simple calculation, there is an xtype that can do it for you.  See class Delta in weewx.wxxtypes. To use it, add this to weewx.conf:

    [StdWXCalculate]
        [[Calculations]]
            ...
        [[Delta]]
            [[[rain]]]
                input = dayRain

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9887101f-fcc1-45ce-948e-e03429bf7baan%40googlegroups.com.

[Remy Lavabre]

Hello Tom and thank you for your response.

     [StdWXCalculate]
         [[Calculations]]
             ...
         [[Delta]]
             [[[rain]]]
                 input = dayRain

This will calculate the rain difference between two records in weewx sql based on the principle that the counter is reset to zero at midnight -> PERFECT FOR THE RAIN 24H !

Small additional question: if we wish to constantly calculate the difference between two records values of a meter which never resets to zero (such as an electricity or water meter), how should we proceed?

THANKS

[Remy Lavabre]

And one more question....
Is it absolutely necessary to create a "dayRain" field in addition to the "rain" field in the weewx.sdb database?
If the database only contains the [rain] field but the Weewx driver returns a "dayRain" field (cumulative rain over 24 hours since midnight) with a real value in each packetloop, the class [[Delta]] [[ [rain]]] input = dayRain will it work??
(the accumulation of rain since midnight is useless to me in a database field since it is easily calculated)
Sorry for all the questions...and thanks again! ;-)

[Tom Keffer]

If an observation type never gets reset to zero, you have two choices.

1. Save the value. If you want to know daily use, take the difference of the value.

2. Save the difference. That is, the change in the value over an archive period. If you want to know daily use, you would sum all the small deltas. This is like rain

See the discussion Accumulated vs delta energy in the README of the Brultech driver for the pros and cons of the two approaches.

It is not necessary to save "dayRain". WeeWX mostly uses "rain". Besides, as you note, it can always be calculated.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/796eb84f-ad09-41bf-ad90-202ad6f05773n%40googlegroups.com.

[Remy Lavabre]

Hello Tom,

I followed your instructions:

1/“rain” field present in the database
2/ “dayRain” field not present in the database
3/ My driver returns “dayRain” values and not “rain” values in the packetsloop
4/ [[Delta]] [[ [rain]]] input = dayRain added in weewx.conf (under [StdWXCalculate]).

I did some tests : my driver returns 0.0 for dayRain but unfortunately the "rain" field in my database always remains NULL, even after several recordings in weewx.conf.
Shouldn't "rain" field go to 0.0?

THANKS

[Tom Keffer]

My apologies. I forgot one important detail. The "[Delta]" section tells WeeWX how to calculate rain, but you also have to include "rain" under [StdWXCalculations] / [[Calculations]] in order to get it to do the actual calculation. It looks like

[StdWXCalculate]
    [[Calculations]]
        ...
        rain = prefer_hardware

        ...
    [[Delta]]
        [[[rain]]]
            input = dayRain

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/4b738c28-b1f5-43ee-a268-8782eaec19a9n%40googlegroups.com.

[Remy Lavabre]

thanks Tom,

I had thought about putting rain = prefer_software but as this type of rain configuration is not documented in the Weewx documentation (or at least I didn't find it!) I didn't take the initiative. .. stupid I am ! :-(

little suggestion Tom, perhaps it would be good to document this point in the [[Delta]] rain class? 

Well, not everyone is ignorant like me!! :-))
Many thanks to you for your help Tom

[Tom Keffer]

Oh, it was the first thing I did after realizing my omission! Commit 9455fa1.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f07194ee-4de4-4948-8e38-9a4c97041942n%40googlegroups.com.

[Remy Lavabre]

Sorry Tom, I didn't notice how quick your insight was! ;-)

However (if I may!), I think that for a better understanding, there would be (perhaps?) another correction to make here: https://github.com/weewx/weewx/blob/master/ src/weewx/wxxtypes.py#L586

Indeed, you indicate in comments a "rain" field and a "dayRain" field. I quote "for calculating observation type 'rain' from a daily total, such as 'dayRain'" -> OK, thank's for the ifo

But below, dayRain "transforms" into "totalRain":

     [StdWXCalculate]
         [[Calculations]]
             ...
             rain = prefer_hardware
             ...
         [[Delta]]
             [[[rain]]]

                 input = totalRain

It's certainly not a big problem, but for a neophyte like me, it raises unnecessary questions when reading the manual... ;-)

Finally, I would like to take this opportunity to ask you if it would not be possible to provide a new class for a counter that never resets to zero (DELTA2 for example), which would simply calculate the delta between two packetsloops (delta2 = measurement2 - measurement1) and if the result is negative, then delta2 = measurement2 (obviously the counter has been reset).
That would be very cool... ;-)
A (good) idea for development... no ?
Thank you Tom