No outTemp/outHumidity value creates rainRate records of 655.35 in/hr

[Jared]

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.

[Tom Keffer]

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.

-tk

--
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/2dbc9618-d9f1-4533-80fc-f642d8e4f5aan%40googlegroups.com.

[Jared]

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?

[Tom Keffer]

Good point, but then you also said that rainRate had values of FFFF. Where are you seeing that?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/34dfb434-72ef-4772-8878-15cc11e2e58fn%40googlegroups.com.

[Jared]

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>

[Tom Keffer]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c70fe151-0b9c-4057-bb7f-96e50f03e0ecn%40googlegroups.com.

[Jared]

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

[Tom Keffer]

It just takes a single value in a LOOP packet for it to show up in "max" in the daily summaries. 

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/56d340f3-9067-4ca1-ad4a-277f663bc676n%40googlegroups.com.

[Jared]

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?

[Tom Keffer]

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? 

Yes, that would work, and would have the advantage of not deleting otherwise good rows in the archive table.

 

Is record_generation = hardware playing a role as well?

Yes, it is, because the value of rainRate is being obtained from the hardware. That's usually a good thing: it guarantees that the value you see on the webpage will match what you see on the console. I would fix the problem of your intermittent bad values before resorting to software generation.

-tk

[Jared]

Thanks Tom, really appreciate your replies here, and I'll take the opportunity to thank you for all your work on Weewx.  It's great software, and a ton of fun to run and work with.  Happy 4th :)

[Jared]

Oh I meant to add, for whatever it's worth, the Vantage console doesn't show anything strange in its hi/low records.  I think the sensors might be having an issue for whatever reason.  I admit I'm not the best about maintaining it, so I'll try to break it down, clean it, and see how it goes.  Thanks again.