Gotcha! Many thanks, Gary! I've tried this
echo "SELECT datetime(dateTime,'unixepoch','localtime'),max,datetime(maxtime,'unixepoch','localtime') FROM archive_day_rainRate WHERE (max>500);" | sqlite3 /home/pi/weewxcopy.sdb and the result is 2020-07-04 00:00:00|516.0236188995|2020-07-04 09:33:45 This is exactly the bad value. My question is now, do I NULL this entry or do I delete this value? What is the correct SELECT statement for this? Regards, Andre Am Mittwoch, 8. Juli 2020 04:28:42 UTC+2 schrieb gjr80: > > I suspect you will find the offending value in the rainRate daily summary > table, the following can be used to check: > > echo "SELECT > datetime(dateTime,'unixepoch','localtime'),max,datetime(maxtime,'unixepoch','localtime') > > FROM archive_day_rainRate WHERE (max>13);" | sqlite3 /home/pi/weewxcopy. > sdb > > One mechanism that could cause this is if under [StdArchive] you have > loop_hilo > = true (the default). This will cause WeeWX to include loop packet data > when determining the high and low value for each observation for the day. > The vantage stations emit rainRate in each loop packet. According to > Davis application note 28 rainRate is calculated every time the rain gauge > bucket tips and is based on the elapsed time since the previous bucket tip. > It is not clear how rainRate is calculated in a console generated archive > record, but I think it would be fair the say it would be some sort of > averaged value. Consequently in a given archive period some loop rainRate > values will be higher than the archive record rainRate and some will be > lower. If loop_hilo = True then WeeWX will record the highest loop > rainRate value in the max field in the applicable days row in the rainRate > daily summary. On the other hand the archive table will only record the > rainRate value from the corresponding archive record and the max rainRate > value is not used (recorded) at all in the archive table (note that if > software record generation was used WeeWX would calculate the archive > record rainRate value as the average of the loop rainRate values seen in > the archive period). > > So seeing a rainRate value in the daily summary tables that is > substantially higher than the highest rainRate value in the archive table > is quite possible, in fact I would say almost certain. A similar effect > happens with other observations but the effect tends to not be noticed very > much as temperatures, pressures etc tend not to vary much between loop > packets whereas rainRate can and does vary significantly. A similar > effect will likely exist for wind speeds where there can be a rapid change > in speed between loop packets. > > So it comes down to is 1300mm/hr an unreasonable figure. Using the the > application note 28 informtion and a 0.2mm rain bucket a rain rate of > 1300mm/h would equate to 6500 tips/hour or 0.55 seconds between tips. Is it > possible to have 0.55 seconds between two tips (remember based on the Davis > method of calcualting rainRate it only takes two tips 0.55 seconds apart > to register 1300 mm/hr)? I don't know, probably unlikely but I don't think > you can say impossible. > > In any case I guess it is up to you whether you leave it or clear it. > Simply rebuilding the daily sumamries will clear the 1300 mm/hr value and > re-calaculate the rainRate max/min/maxtime/mintime based on the archive > data. > > Of course I could be completey wrong and this culd be a totally bogus > value that has somehow appeared in the rainRate daily summary, but given > it occurred on a day when you had a good bit of rain..... > > Gary > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d3518274-44d9-47c5-8aa0-4bae7bf5cb68o%40googlegroups.com.
