Thanks for the detailed response! I'll try to elaborate on everything here. 1) Under StdArchive: record_generation = hardware 2) Units are in "inches/hour" 3) First sql query from archive is the same as the second from archive_day_rainRate. 9.44, which while high, is certainly plausible in Florida.
I don't know where it's getting that value. It was never written to the database. Same value each time when it happens. But I think your idea of using the StdQC service is a good one. We may just have to leave this one a mystery and move on. Thanks so much for your time! Ernie On Thu, Aug 26, 2021 at 3:08 AM gjr80 <gjroder...@gmail.com> wrote: > Hi, > > This is a real 'it depends' type answer. A few things to consider before > coming up with a way ahead. > > prefer_hardware. All prefer_hardware does is look for an observation (in > this case rainRate) from the driver and if it is present it is used. > Otherwise WeeWX attempts to calculate rainRate. The vantage driver emits > rainRate in both loop packets and archive records so WeeWX should be > using rainRate as it comes from the driver. The 'it depends' part here is > that if you are using software record generation (record_generation = > software under [StdArchive] in weewx.conf) then WeeWX will be calculating > the archive record rainRate value (this is the value stored in your > archive table in your database and used in reports) as the average of the > accumulated loop packet rainRate values (this is slightly different to > the approach used within the Davis console, and hence emitted by the > vantage driver, where archive record rainRate is actually the highest > rainRate value seen during the archive period). The upshot is you could > be seeing a value direct from the console or a value calculated by WeeWX > based on loop packet values from the console. In either case you should not > be seeing inordinately large and erroneous rainRate values. > > 655.35. You may or may not have 655.35 in your archive table but depending > on units you will have an equivalent value, perhaps in other units, in your > database. The fact that you can clear the daily summaries and force > regeneration of the output to fix the problem proves this. What units is > the 655.35 value being reported in? inches/hour, mm/hour or cm/hour? The > units used in a report do not necessarily match the units used in the > database. To cut a long story short a default WeeWX install will see the > database store rainRate data in inches/hour (rain is stored in inches). > You can force WeeWX to use one of two Metric variations where rainRate is > stored in mm/hour or cm/hour (rain is stored as mm or cm respectively) > but you would need to make specific changes to weewx.conf to do this, > most folks don't. Have a look at the target_unit setting under > [StdConvert] in weewx.conf. If it is set to US your database will store > rainRate in inches/hour, if METRICWX it will be in mm/hour and if METRIC > it will be in cm/hour. For example, if your 655.35 value is mm/hour and you > have a database using inches/hour then you need to be looking for a value > around 25.8 not 655.35. > > Also, where are you looking for the value? In the archive table or in the > rainRate daily summary table (table name archive_day_rainRate)? The daily > summary tables (archive_day_rainRate in this case) are based on data from > the archive table so you should not find anything in there that is not in > the archive table, but I guess it is possible there could be a > disconnect, I can't think of a likely mechanism though. > > How are you looking for the value? Assuming you are using a SQLite > database and have the sqlite3 package installed (if not install using sudo > apt install sqlite3 on Debian based systems) then something like the > following will show you the highest rainRate value in your archive table > along with the timestamp and date-time it occurred and the unit system used > by your database: > > $ echo "SELECT > dateTime,datetime(dateTime,'unixepoch','localtime'),MAX(rainRate),usUnits > FROM archive;" | sqlite3 /var/lib/weewx/weewx.sdb > > Note the above command assumes your database is /var/lib/weewx/weewx.sdb > (the default for a WeeWX package install). If you did a setup.py install it > will likely be /home/weewx/archive/weewx.sdb and you should change the > above command accordingly. Note also the usUnits value will tell you what > units rainRate is stored in in your database; 1=US=inches/hour, > 17=METRICWX=mm/hour and 16=METRIC=cm/hour. > > To look at the data in the rainRate daily summary table: > > $ echo "SELECT > dateTime,datetime(dateTime,'unixepoch','localtime'),MAX(max) FROM > archive_day_rainRate;" | sqlite3 /var/lib/weewx/weewx.sdb > > You should find the same max rainRate value as found in the archive table > but the timestamps/date-times will be different. This is because in the > daily summary tables each row holds aggregate data for each day (ie one > record per day), whereas the archive table holds each record (ie many > records per day). > > I would not expect you to find any rainRate data in the log, WeeWX does > not record observation data in the log nor does the vantage driver (other > drivers or addons may). > > The above might help you find the bad data but it isn't going to change > anything. Once you identify what bad data is coming in the obvious choice > for keeping it from polluting your database is to use the StdQC service > to set some min/max values > <http://weewx.com/docs/usersguide.htm#[[MinMax]]>. This can be quite > effective for wildly wrong spurious values (eg winds of 300km/hr) but not > much use if you are getting a plausible, but wrong value (eg on a warm day > of 29C you suddenly get a temperature that is 10C lower than the last). The > usefulness of StdQC should be clear once you know what units you are > using, but I am guessing a value of 655.35/hour is obviously high > irrespective of the units. One thing to remember about StdQC MinMax > settings is that they are in the units used in your database unless you > explicitly include units. > > Gary > > On Thursday, 26 August 2021 at 11:21:51 UTC+10 etji...@gmail.com wrote: > >> Weewx 4.5.1 >> Belchertown 1.3b1 >> Davis VP2 >> >> I don't think this is a true weewx or Belchertown issue since my rainrate >> is set to prefer hardware, but I'm getting some new behavior over the last >> few months that I hadn't seen before. >> >> Every once in a while, I will get a rainrate of 655.35, even if it didn't >> rain. That becomes the max for the day/month/year, of course. But when I >> check the weewx.sdb, there are no rainrates of 655.35. Nothing even close. >> I grep for 655.35 in the syslog and come up empty. >> >> I can stop weewx, rebuild the daily for that day, then rm everything from >> the /var/www/html folder, restart weewx and it's fixed. But where is it >> coming from? Any ideas? >> >> Thanks in advance, >> >> Ernie >> > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/f583faad-5dde-43be-90c2-acbfaf81ae92n%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/f583faad-5dde-43be-90c2-acbfaf81ae92n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAC5oUmNVr8jznM6d%2BX_1ggAf95EYmiQDy-wObmBQBrgszGSkMA%40mail.gmail.com.
