Gotcha, I didn't realize that. I've been deleting the rows where outTemp is null and then rebuilding the dailies and that's fixed the strange records, but I'm assuming that if I just rebuild the dailies that will do the trick without modifying the database? Is record_generation = hardware playing a role as well? Sounds like there's some drawbacks to setting this to software, but perhaps it's moot if I'm rebuilding the dailies anyway?
On Tuesday, July 4, 2023 at 1:12:18 PM UTC-4 Tom Keffer wrote: > It just takes a single value in a LOOP packet for it to show up in "max" > in the daily summaries. > > On Tue, Jul 4, 2023 at 9:53 AM Jared <[email protected]> wrote: > >> Ah, there it is, in archive_day_rainRate. I had to change from hex to >> int, and included maxtime so you can see the corresponding archive records. >> >> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >> rain, rainRate from archive where rainRate==0xffff; >> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >> min, max from archive_day_rainRate where max==0xffff; >> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >> min, max, maxtime, datetime(maxtime, 'unixepoch', 'localtime') from >> archive_day_rainRate where max > 10; >> dateTime datetime(dateTime, 'unixepoch', 'localtime') min max >> maxtime datetime(maxtime, 'unixepoch', 'localtime') >> ---------- -------------------------------------------- ---------- >> ---------- ---------- ------------------------------------------- >> 1572494400 2019-10-31 00:00:00 0.0 >> 24.0 1572573900 2019-10-31 22:05:00 >> 1581051600 2020-02-07 00:00:00 0.0 >> 11.76 1581081900 2020-02-07 08:25:00 >> 1688356800 2023-07-03 00:00:00 0.0 >> 655.35 1688357458 2023-07-03 00:10:58 >> >> >> Still not finding any smoking gun in archive though. >> >> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >> rain, rainRate from archive where rainRate > 10; >> dateTime datetime(dateTime, 'unixepoch', 'localtime') rain >> rainRate >> ---------- -------------------------------------------- ---------- >> ---------- >> 1572573900 2019-10-31 22:05:00 0.37 24.0 >> 1581081900 2020-02-07 08:25:00 0.19 >> 11.76 >> >> >> The records webpage says the 655.35 record occurred at 00:10 local time >> on 7/3/23, but there's nothing interesting there in archive. >> >> sqlite> select dateTime,datetime(dateTime, 'unixepoch', >> 'localtime'),barometer,outTemp,outHumidity,rain,rainRate from archive where >> dateTime > 1688356000 and dateTime < 1688361500; >> dateTime datetime(dateTime, 'unixepoch', 'localtime') barometer >> outTemp outHumidity rain rainRate >> ---------- -------------------------------------------- ---------- >> ---------- ----------- ---------- ---------- >> 1688356200 2023-07-02 23:50:00 29.879 >> 72.8 96.0 0.0 0.0 >> 1688356500 2023-07-02 23:55:00 29.875 >> 72.8 96.0 0.0 0.0 >> 1688356800 2023-07-03 00:00:00 29.874 >> 72.8 96.0 0.0 0.0 >> 1688357100 2023-07-03 00:05:00 29.875 >> 72.8 96.0 0.0 0.0 >> 1688357400 2023-07-03 00:10:00 29.876 >> 72.8 96.0 0.0 0.0 >> 1688357700 2023-07-03 00:15:00 29.879 >> 72.8 96.0 0.0 0.0 >> 1688358000 2023-07-03 00:20:00 29.879 >> 0.0 0.0 >> 1688358300 2023-07-03 00:25:00 29.875 >> 0.0 0.0 >> 1688358600 2023-07-03 00:30:00 29.873 >> 0.0 0.0 >> 1688358900 2023-07-03 00:35:00 29.875 >> 0.0 0.0 >> 1688359200 2023-07-03 00:40:00 29.872 >> 0.0 0.0 >> 1688359500 2023-07-03 00:45:00 29.868 >> 72.6 0.0 0.0 >> 1688359800 2023-07-03 00:50:00 29.867 >> 72.7 97.0 0.0 0.0 >> 1688360100 2023-07-03 00:55:00 29.866 >> 72.8 97.0 0.0 0.0 >> 1688360400 2023-07-03 01:00:00 29.865 >> 72.8 97.0 0.0 0.0 >> 1688360700 2023-07-03 01:05:00 29.866 >> 72.8 97.0 0.0 0.0 >> 1688361000 2023-07-03 01:10:00 29.867 >> 72.8 97.0 0.0 0.0 >> 1688361300 2023-07-03 01:15:00 29.869 >> 72.8 97.0 0.0 0.0 >> >> >> >> On Tuesday, July 4, 2023 at 9:48:24 AM UTC-4 Tom Keffer wrote: >> >>> I'm not familiar with records.inc. I assume the variable $archiveData is >>> a list of time spans? If so, $archive.rainRate.max would be coming from the >>> daily summaries. >>> >>> Let's try this: >>> >>> sqlite3 weewx.sdb >>> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >>> rain, rainRate from archive where rainRate==0xffff; >>> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), >>> min, max from archive_day_rainRate where max==0xffff; >>> >>> For the records webpage to show a value of 0xffff, it must be in the >>> database somewhere. >>> >>> On Tue, Jul 4, 2023 at 4:48 AM Jared <[email protected]> wrote: >>> >>>> I'm seeing it in the records webpage. Here is that part of my >>>> records.inc file: >>>> >>>> <tr> >>>> <td class="recordsLabel">$obs.label.rainRate</td> >>>> <td class="recordsHiLoLabel">High</td> >>>> #for $archive in $archiveData >>>> <td >>>> class="recordsData">$archive.rainRate.max.format(add_label=False)</td> >>>> #end for >>>> </tr> >>>> >>>> On Monday, July 3, 2023 at 6:23:53 PM UTC-4 Tom Keffer wrote: >>>> >>>>> Good point, but then you also said that rainRate had values of FFFF. >>>>> Where are you seeing that? >>>>> >>>>> On Mon, Jul 3, 2023 at 3:01 PM Jared <[email protected]> wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Thanks! The confusing thing for me is that the database is showing >>>>>> 0.0 for the rainRate in those bad intervals. Wouldn't I expect to see >>>>>> 655.35 in those archive intervals instead of 0.0? >>>>>> On Monday, July 3, 2023 at 3:58:05 PM UTC-4 Tom Keffer wrote: >>>>>> >>>>>>> I think these are all related. If your VP2 receives a "dash value", >>>>>>> that means the reading from the sensor is bad. The WeeWX Vantage driver >>>>>>> detects this, and emits a value of None, which becomes a null value in >>>>>>> the >>>>>>> database. For whatever reasons, the outside temperature and humidity >>>>>>> sensors are emitting dash values, so you're seeing corresponding null >>>>>>> values in their database fields. >>>>>>> >>>>>>> However, dash values are NOT detected for rain rate, so you'll see >>>>>>> 0xFFFF as the value. The documentation does not mention that a dash >>>>>>> value >>>>>>> is possible for rain rate, but obviously it is. That's a change that >>>>>>> needs >>>>>>> to be made to the driver. >>>>>>> >>>>>>> As for why these sensors are emitting null (aka, "dash") values, I >>>>>>> don't know. Something going on with your hardware. Because it is >>>>>>> happening >>>>>>> to 3 different sensors at the same time, it makes me think it must be >>>>>>> something they all have in common. Perhaps the battery, perhaps the >>>>>>> communications module, perhaps something else. It's worth asking Davis. >>>>>>> >>>>>>> Fixed in commit dea4b30 >>>>>>> <https://github.com/weewx/weewx/commit/dea4b30317fac63428ae47c1b08fe31433d0d232> >>>>>>> . >>>>>>> >>>>>>> -tk >>>>>>> >>>>>>> On Mon, Jul 3, 2023 at 4:59 AM Jared <[email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm running a Vantage Pro 2, and there have been four occurrences >>>>>>>> so far this year where it has failed to log an outTemp and outHumidity >>>>>>>> value in the database for a period of several archive intervals. >>>>>>>> >>>>>>>> If I run a query like this: >>>>>>>> >>>>>>>> select >>>>>>>> dateTime,barometer,inTemp,outTemp,inHumidity,outHumidity,windSpeed,windDir,windGust,windGustDir,rain,rainRate,rxCheckPercent,txBatteryStatus,consBatteryVoltage >>>>>>>> >>>>>>>> from archive where outTemp IS NULL; >>>>>>>> >>>>>>>> The station is logging everything normally except outTemp and >>>>>>>> outHumidity. This is going to format terribly but it may help: >>>>>>>> >>>>>>>> dateTime barometer inTemp outTemp inHumidity >>>>>>>> outHumidity windSpeed windDir windGust windGustDir rain >>>>>>>> >>>>>>>> rainRate rxCheckPercent txBatteryStatus consBatteryVoltage >>>>>>>> ---------- ---------- ---------- ---------- ---------- >>>>>>>> ----------- ---------- ---------- ---------- ----------- >>>>>>>> ---------- >>>>>>>> ---------- -------------- --------------- ------------------ >>>>>>>> 1688358000 29.879 76.9 42.0 >>>>>>>> 0.0 0.0 0.0 0.0 >>>>>>>> >>>>>>>> 99.4375 0.0 4.79 >>>>>>>> 1688358300 29.875 76.7 42.0 >>>>>>>> 0.0 0.0 0.0 0.0 >>>>>>>> >>>>>>>> 99.4375 0.0 4.79 >>>>>>>> 1688358600 29.873 76.7 42.0 >>>>>>>> 0.0 0.0 0.0 0.0 >>>>>>>> >>>>>>>> 99.4375 0.0 4.79 >>>>>>>> 1688358900 29.875 76.6 42.0 >>>>>>>> 0.0 0.0 0.0 0.0 >>>>>>>> >>>>>>>> 100.0 0.0 4.79 >>>>>>>> 1688359200 29.872 76.5 42.0 >>>>>>>> 0.0 0.0 0.0 0.0 >>>>>>>> >>>>>>>> 99.4375 0.0 4.79 >>>>>>>> >>>>>>>> First, I wonder if there is a problem with my station's sensor. >>>>>>>> I'll have to investigate that. Three occurrences of this happened >>>>>>>> over the >>>>>>>> winter, and just last night was the first time it's happened in >>>>>>>> months. >>>>>>>> Any tips here are appreciated, but I know that's well outside the >>>>>>>> scope of >>>>>>>> the forum :) >>>>>>>> >>>>>>>> But for whatever reason, this also messes up the rainRate records. >>>>>>>> As you can see there's no strange rain data in the archive, so I'm not >>>>>>>> sure >>>>>>>> how it's causing the rainRate records to have that value (FFFF in >>>>>>>> hex). >>>>>>>> All the other values and tables aside from archive are generated by >>>>>>>> Weewx, >>>>>>>> right? >>>>>>>> >>>>>>>> Any help is appreciated. I've just been deleting these bad records >>>>>>>> from archive and rebuilding the daily tables, but let me know if >>>>>>>> there's >>>>>>>> something I else I should be doing. >>>>>>>> >>>>>>>> -- >>>>>>>> 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/2dbc9618-d9f1-4533-80fc-f642d8e4f5aan%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/weewx-user/2dbc9618-d9f1-4533-80fc-f642d8e4f5aan%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 [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/weewx-user/34dfb434-72ef-4772-8878-15cc11e2e58fn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/weewx-user/34dfb434-72ef-4772-8878-15cc11e2e58fn%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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/c70fe151-0b9c-4057-bb7f-96e50f03e0ecn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/weewx-user/c70fe151-0b9c-4057-bb7f-96e50f03e0ecn%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 [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/56d340f3-9067-4ca1-ad4a-277f663bc676n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/56d340f3-9067-4ca1-ad4a-277f663bc676n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/127d192a-7f31-4858-bbd6-2adaac831b39n%40googlegroups.com.
