Huge Rainrate

[Karen K]

Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So I searched the database using sqlite3 command. In archive table there is no such high value. But in archive_day_rainrate table I found a value of 50.3937007874016. If that were in inch/h, than it would correspond to the value above. It is one single value on 2021-01-18 at midnight (00:00:00). 

The next highest value in that table is 1.09317644333333. It is much smaller.

I wonder if that has to do with the time switching from 23:55:00 to 00:00:00 in that very archive interval.

It is version 4.2.0. No other problems observed.

Is that a known issue?

I will try to re-calculate summaries tomorrow.

[Karen K]

Now I found time to run 

  wee_database --rebuild-daily --from=2021-01-17

After that, the value was much lower.

[Karen K]

The new value was much lower, but still very high. So I looked into the database and found that:

sqlite> select dateTime,rain,rainrate from archive where dateTime>1610960000 and dateTime<1610964000;
1610960100|0.0|0.0
1610960400|0.0|0.0
1610960700|0.0|0.0
1610961000|0.0|0.0
1610961300|0.0|0.0
1610961600|0.0|0.0
1610961900|0.015748031496063|5.79576771653542
1610962200|0.0|0.0666010498687663
1610962500|0.0|0.0385498687664041
1610962800|0.0|0.0131233595800525
1610963100|0.0|0.0
1610963400|0.0|0.0
1610963700|0.0|0.0
sqlite> 

As I did not find the word 'rainrate' within the driver file weatherlinkliveudp.py I guess that the rainrate value is calculated by weewx.

I still wonder what causes those high values.

[Karen K]

From /etc/weewx.conf:

[Station]
    station_type = WeatherLinkLiveUDP

# Options for extension 'WeatherLinkLiveUDP'
[WeatherLinkLiveUDP]
    wll_ip = XXX.XXX.XXX.XXX 
    poll_interval = 10
    driver = user.weatherlinkliveudp
    hardware = Davis Vantage Pro2

[Tom Keffer]

I'm not familiar with the WeatherLink, but if it's like the other Davis products, it emits its own version of rainRate. 

By default, this is what will get used unless you have weewx calculate it in software. See the section [[Calculations]] in weewx.conf

--
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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%40googlegroups.com.

[Karen K]

Your are right. I looked for "rainrate" but it is "rainRate" (case sensitive). And "rainRate" is set from the data the WeatherLinkLive device sends. So it is nothing inside weewx.

On the other hand the huge value in the summeries table (that the topic started with) did not come out of the device. And it disappeared by the rebuild of the daily summeries. 

[Tom Keffer]

Do you recall which field in archive_day_rainRate showed the high value? The schema for that table is

CREATE TABLE archive_day_rainRate (dateTime INTEGER NOT NULL UNIQUE PRIMARY KEY, min REAL, mintime INTEGER, max REAL, maxtime INTEGER, sum REAL, count INTEGER, wsum REAL, sumtime INTEGER);

If you were looking at column 'max', it would be the maximum value seen during the archive period. This could have come from some LOOP packet. When you rebuild the daily summaries, this value would not be used, explaining your results.

-tk

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/b4d73f19-e627-480b-a389-3b3d91f44a22n%40googlegroups.com.

[Karen K]

It was the "max" field.

[Tom Keffer]

Ah, there you go. Unless you ask for it, that's not what is going to get plotted or reported. 

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/17d7d43d-b217-4503-9ef1-2935e116bebfn%40googlegroups.com.