WMR300A -> Wunderground, no rain data
109 views
Skip to first unread message
Leon Shaner
Apr 12, 2019, 3:28:39 PM4/12/19
to weewx...@googlegroups.com
Hi, hi.
For unknown reasons, Wunderground isn't showing any rain-data for my KMIDEARB5 station.
I used sqlite3 to query the weewx.sdb, to confirm that there is rain and rainRate data and there is.
But what's interesting is that there are positive rainRate values for today, but in the rain data it shows values of 0.0, everywhere except count (which presumably is the number of times weewx reported the 0.0 values, today).
The WMR300A console itself does show 0.09" of rain today.
Is it just that the amount of rain today was too minuscule to register?
WU seems to be looking at the data corresponding to the archive_day_rain, in the first table weewx table, further down in this e-mail, and if the numbers there are 0, it seems to ignore the rain rate.
For example if I go back to 2016-07-12, there is data showing on the WU side for both precip accumulation and precip rate :
Really just asking about the last row of data from today, and why does WU not show any rain?
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, min, datetime(mintime, 'unixepoch', 'localtime') as mintime, max, datetime(maxtime, 'unixepoch', 'localtime') as maxtime, sum, count, wsum, sumtime from archive_day_rain;"
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, min, datetime(mintime, 'unixepoch', 'localtime') as mintime, max, datetime(maxtime, 'unixepoch', 'localtime') as maxtime, sum, count, wsum, sumtime from archive_day_rainRate;"
Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
For unknown reasons, Wunderground isn't showing any rain-data for my KMIDEARB5 station.
I used sqlite3 to query the weewx.sdb, to confirm that there is rain and rainRate data and there is.
But what's interesting is that there are positive rainRate values for today, but in the rain data it shows values of 0.0, everywhere except count (which presumably is the number of times weewx reported the 0.0 values, today).
The WMR300A console itself does show 0.09" of rain today.
Is it just that the amount of rain today was too minuscule to register?
WU seems to be looking at the data corresponding to the archive_day_rain, in the first table weewx table, further down in this e-mail, and if the numbers there are 0, it seems to ignore the rain rate.
For example if I go back to 2016-07-12, there is data showing on the WU side for both precip accumulation and precip rate :
https://www.wunderground.com/dashboard/pws/KMIDEARB5/graph/2016-07-12/2016-07-12/dailyAbove is for reference.
Really just asking about the last row of data from today, and why does WU not show any rain?
https://www.wunderground.com/dashboard/pws/KMIDEARB5/table/2019-04-12/2019-04-12/dailyNOTE: The below is all the data I have, locally in WeeWX, which is because I didn't realize that sending a "kill -HUP {weewxd_pid}" to make the debug = 1 setting take effect would abort the initial ingestion of archive data from the WMR300A unit. :S
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, min, datetime(mintime, 'unixepoch', 'localtime') as mintime, max, datetime(maxtime, 'unixepoch', 'localtime') as maxtime, sum, count, wsum, sumtime from archive_day_rain;"
| day | min | mintime | max | maxtime | sum | count | wsum | sumtime |
| 2012-01-01 | 0.0 | 2012-01-01 12:01:00 | 0.0 | 2012-01-01 12:01:00 | 0.0 | 189 | 0.0 | 11340 |
| 2014-09-10 | 0.0 | 2014-09-10 09:39:00 | 0.0 | 2014-09-10 09:39:00 | 0.0 | 325 | 0.0 | 84938280 |
| 2016-07-01 | 0.0 | 2016-07-01 17:51:00 | 0.0 | 2016-07-01 17:51:00 | 0.0 | 369 | 0.0 | 141994320 |
| 2016-07-02 | 0.0 | 2016-07-02 00:01:00 | 0.0 | 2016-07-02 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-03 | 0.0 | 2016-07-03 00:01:00 | 0.0 | 2016-07-03 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-04 | 0.0 | 2016-07-04 00:01:00 | 0.0 | 2016-07-04 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-05 | 0.0 | 2016-07-05 00:01:00 | 0.0 | 2016-07-05 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-06 | 0.0 | 2016-07-06 00:01:00 | 0.0 | 2016-07-06 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-07 | 0.0 | 2016-07-07 00:01:00 | 0.0 | 2016-07-07 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-08 | 0.0 | 2016-07-08 00:01:00 | 0.04 | 2016-07-08 00:29:00 | 0.41 | 1440 | 24.6 | 86400 |
| 2016-07-09 | 0.0 | 2016-07-09 00:01:00 | 0.0 | 2016-07-09 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-10 | 0.0 | 2016-07-10 00:01:00 | 0.0 | 2016-07-10 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-11 | 0.0 | 2016-07-11 00:01:00 | 0.0 | 2016-07-11 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-12 | 0.0 | 2016-07-12 00:01:00 | 0.0100000000000001 | 2016-07-12 22:04:00 | 0.0500000000000001 | 1440 | 3.0 | 86400 |
| 2016-07-13 | 0.0 | 2016-07-13 00:01:00 | 0.02 | 2016-07-13 20:01:00 | 0.0399999999999999 | 1440 | 2.4 | 86400 |
| 2016-07-14 | 0.0 | 2016-07-14 00:01:00 | 0.0 | 2016-07-14 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-15 | 0.0 | 2016-07-15 00:01:00 | 0.0 | 2016-07-15 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-16 | 0.0 | 2016-07-16 00:01:00 | 0.0 | 2016-07-16 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-17 | 0.0 | 2016-07-17 00:01:00 | 0.0 | 2016-07-17 00:01:00 | 0.0 | 55 | 0.0 | 3300 |
| 2018-12-31 | 0.0 | 2018-12-31 06:00:00 | 0.0 | 2018-12-31 06:00:00 | 0.0 | 17 | 0.0 | 220817760 |
| 2019-04-10 | 0.0 | 2019-04-10 14:08:20 | 0.0 | 2019-04-10 14:08:20 | 0.0 | 105 | 0.0 | 31500 |
| 2019-04-11 | 0.0 | 2019-04-11 00:00:01 | 0.0 | 2019-04-11 00:00:01 | 0.0 | 288 | 0.0 | 86400 |
| 2019-04-12 | 0.0 | 2019-04-12 00:00:01 | 0.0 | 2019-04-12 00:00:01 | 0.0 | 173 | 0.0 | 51900 |
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, min, datetime(mintime, 'unixepoch', 'localtime') as mintime, max, datetime(maxtime, 'unixepoch', 'localtime') as maxtime, sum, count, wsum, sumtime from archive_day_rainRate;"
| day | min | mintime | max | maxtime | sum | count | wsum | sumtime |
| 2012-01-01 | 0.0 | 0 | 0.0 | 0 | ||||
| 2014-09-10 | 0.0 | 0 | 0.0 | 0 | ||||
| 2016-07-01 | 0.0 | 2016-07-01 18:08:00 | 0.0 | 2016-07-01 18:08:00 | 0.0 | 353 | 0.0 | 21180 |
| 2016-07-02 | 0.0 | 2016-07-02 00:01:00 | 0.0 | 2016-07-02 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-03 | 0.0 | 2016-07-03 00:01:00 | 0.0 | 2016-07-03 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-04 | 0.0 | 2016-07-04 00:01:00 | 0.0 | 2016-07-04 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-05 | 0.0 | 2016-07-05 00:01:00 | 0.0 | 2016-07-05 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-06 | 0.0 | 2016-07-06 00:01:00 | 0.0 | 2016-07-06 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-07 | 0.0 | 2016-07-07 00:01:00 | 0.0 | 2016-07-07 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-08 | 0.0 | 2016-07-08 00:01:00 | 2.7199999972256 | 2016-07-08 19:23:00 | 28.6199999708076 | 1440 | 1717.19999824846 | 86400 |
| 2016-07-09 | 0.0 | 2016-07-09 00:01:00 | 0.0 | 2016-07-09 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-10 | 0.0 | 2016-07-10 00:01:00 | 0.0 | 2016-07-10 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-11 | 0.0 | 2016-07-11 00:01:00 | 0.0 | 2016-07-11 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-12 | 0.0 | 2016-07-12 00:01:00 | 0.6599999993268 | 2016-07-12 22:06:00 | 5.09999999479799 | 1440 | 305.99999968788 | 86400 |
| 2016-07-13 | 0.0 | 2016-07-13 00:01:00 | 0.5399999994492 | 2016-07-13 20:05:00 | 3.4899999964402 | 1440 | 209.399999786412 | 86400 |
| 2016-07-14 | 0.0 | 2016-07-14 00:01:00 | 0.0 | 2016-07-14 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-15 | 0.0 | 2016-07-15 00:01:00 | 0.0 | 2016-07-15 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-16 | 0.0 | 2016-07-16 00:01:00 | 0.0 | 2016-07-16 00:01:00 | 0.0 | 1440 | 0.0 | 86400 |
| 2016-07-17 | 0.0 | 2016-07-17 00:01:00 | 0.0 | 2016-07-17 00:01:00 | 0.0 | 55 | 0.0 | 3300 |
| 2018-12-31 | 0.0 | 0 | 0.0 | 0 | ||||
| 2019-04-10 | 0.0 | 2019-04-10 14:08:19 | 0.0 | 2019-04-10 14:08:19 | 0.0 | 105 | 0.0 | 31500 |
| 2019-04-11 | 0.0 | 2019-04-11 00:00:01 | 0.0 | 2019-04-11 00:00:01 | 0.0 | 288 | 0.0 | 86400 |
| 2019-04-12 | 0.0 | 2019-04-12 00:00:01 | 0.4199999995716 | 2019-04-12 08:46:14 | 1.40269840736274 | 173 | 420.809522208823 | 51900 |
Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
-- le...@isylum.org - Dearborn, Michigan
Thomas Keffer
Apr 12, 2019, 8:44:19 PM4/12/19
to weewx-user
Let me clarify something: the WU wants the total rain that fell in the last hour. So, obvious archive fields such as rain, or rainRate, are not used. Instead, WeeWX calculates the total rain over the last 60 minutes for every post, using the archive table. The daily summaries are not involved at all.
Two suggestions:
- Do a similar sqlite query, but this time against the table 'archive'. See if those values are non-zero.
- Another thing you can do is set debug=2. This will cause WeeWX to log the exact URL that is being sent to the WU. See if it fits your expectations.
-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.
For more options, visit https://groups.google.com/d/optout.
Leon Shaner
Apr 13, 2019, 10:18:27 AM4/13/19
to weewx...@googlegroups.com
Hey, TK,
Thanks for the pointers. I didn't know about the archive table and it wasn't obvious, just grepping for rain in the .dump output.
Do you know if there is a difference in the way that "real time" data is read from the WMR300A vs. reading the historical data?
I wonder if the "bug" is in reading the "real time" data... Could be a WMR300A bug, because one reason I have been exploring different software options is because no software I have tried has worked for reporting the rain data. :-(
So, by inspecting the "archive" table in weewx.sdb, it is proven that WeeWX didn't extract any rain on 2019-4-12; only the rainRate has a non-zero value.
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, rain, rainRate from archive where rainRate != 0.0" | tail -20
2016-07-13|0.0|0.0899999999082
2016-07-13|0.0|0.0799999999184
2016-07-13|0.0|0.0799999999184
2016-07-13|0.0|0.0699999999286
2016-07-13|0.0|0.0699999999286
2016-07-13|0.0|0.0599999999388
2019-04-12|0.0|0.044692737384581
2019-04-12|0.0|0.314333333012714
2019-04-12|0.0|0.183352600969049
2019-04-12|0.0|0.131173184223745
2019-04-12|0.0|0.0929999999051399
2019-04-12|0.0|0.0899999999081999
2019-04-12|0.0|0.102011173080306
2019-04-12|0.0|0.092914285619513
2019-04-12|0.0|0.0669696969013877
2019-04-12|0.0|0.0599999999387998
2019-04-12|0.0|0.0599999999387998
2019-04-12|0.0|0.0599999999387998
2019-04-12|0.0|0.0589999999398198
2019-04-12|0.0|0.0452513966018882
It isn't as if reading the rain from the WMR300A is completely broken, because there is some data there from before the initial ingest got aborted:
pi@nixie:/var/lib/weewx $ sqlite3 -header weewx.sdb "select date(dateTime, 'unixepoch', 'localtime') as day, rain, rainRate from archive where rain != 0.0"
day|rain|rainRate
2016-07-08|0.01|0.0
2016-07-08|0.01|0.1199999998776
2016-07-08|0.01|0.0899999999082
2016-07-08|0.01|0.5099999994798
2016-07-08|0.02|1.0699999989086
2016-07-08|0.04|1.8299999981334
2016-07-08|0.01|0.8199999991636
2016-07-08|0.01|0.6199999993676
2016-07-08|0.01|0.199999999796
2016-07-08|0.01|0.0
2016-07-08|0.01|0.1199999998776
2016-07-08|0.01|0.149999999847
2016-07-08|0.00999999999999998|0.1699999998266
2016-07-08|0.01|0.2099999997858
2016-07-08|0.01|0.2399999997552
2016-07-08|0.00999999999999998|0.2099999997858
2016-07-08|0.00999999999999998|0.099999999898
2016-07-08|0.01|0.0799999999184
2016-07-08|0.01|0.0599999999388
2016-07-08|0.00999999999999998|0.0
2016-07-08|0.00999999999999998|0.0
2016-07-08|0.03|1.4299999985414
2016-07-08|0.03|2.7199999972256
2016-07-08|0.02|1.5399999984292
2016-07-08|0.02|0.8899999990922
2016-07-08|0.03|1.4699999985006
2016-07-08|0.00999999999999998|0.9099999990718
2016-07-08|0.00999999999999998|0.449999999541
2016-07-08|0.00999999999999998|0.6099999993778
2016-07-12|0.00999999999999998|0.0
2016-07-12|0.0100000000000001|0.4899999995002
2016-07-12|0.00999999999999998|0.5099999994798
2016-07-12|0.00999999999999998|0.6599999993268
2016-07-12|0.0100000000000001|0.0799999999184
2016-07-13|0.02|0.0
2016-07-13|0.00999999999999998|0.2799999997144
2016-07-13|0.00999999999999998|0.5399999994492
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Thomas Keffer
Apr 13, 2019, 11:06:44 AM4/13/19
to weewx-user
You can't look for rain where rainRate is non-zero, because the latter is only loosely connected to the former. Instead, do a simple query for rain:
select datetime(dateTime,'unixepoch','localtime'), rain, rainRate from archive where date(dateTime,'unixepoch','localtime')="2019-04-12";
See if any of those are non-zero.
-tk
Leon Shaner
Apr 13, 2019, 11:10:04 AM4/13/19
to weewx...@googlegroups.com
Hey, TK,
Sorry. I did query for rain already and it's all 0.0, except as shown in the second output I pasted.
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Thomas Keffer
Apr 13, 2019, 11:24:10 AM4/13/19
to weewx-user
I see. So, as far as the database is concerned, it has not rained since 2016? Unless you live in the Atacama desert, that's clearly not right!
The problem must be getting the rain value from the WMR300 and into WeeWX, and has nothing to do with the WU.
Did you try resetting the rain counter (see this post)?
Matthew wrote this driver (as he did so many others!), so he would be the expert.
-tk
Leon Shaner
Apr 13, 2019, 1:10:18 PM4/13/19
to weewx...@googlegroups.com
Hi, TK,
Haha. Well certainly it has rained. One reason the DB rain data is so sparse with that huge gap after July 2016 is that the rain data hadn't been cleared in years and upon installing weewx for the first time, last week, the ingestion was taking forever...which I was happy to allow, but got interrupted when I did a kill -HUP {weewxd_pid} to enable "debug = 1" to find out why no data was being posted to WU, whatsoever. That kill -HUP had the unexpected side-effect of aborting the long-ago history ingestion. As a result of the debug and just as a "guess" on what to do, I found that in addition to "rapidfire = True" I also had to set "archive_post = True" in order for any data to post to WU. Probably a bug there that Wunderground-PWS and Wunderground-RF are somehow bound together, but it is what it is and I don't mind because I want both.
Meanwhile, I noticed that weewx was telling me that my maximum rain counter was exceeded and that I should reset the data, so I did that on the 9th or 10th.
It rained for the first time since on the 12th.
Thanks again for all the insights.
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Leon Shaner
Apr 13, 2019, 2:14:31 PM4/13/19
to weewx...@googlegroups.com
Well, this is interesting. From the logs...
Apr 13 13:57:23 nixie weewx[368]: wmr300: sensor map is {'outHumidity': 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill', 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex': 'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7': 'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6', 'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4': 'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3', 'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6': 'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2': 'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1': 'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2': 'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4': 'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1', 'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust': 'wind_gust'}
Apr 13 13:57:23 nixie weewx[368]: wmr300: history limit is 20%
Apr 13 13:57:24 nixie weewx[368]: wmr300: communication established: {'station_model': 'A004', 'latest_index': 32736, 'station_type': 'WMR300', 'mystery1': 44, 'mystery0': 73, 'history_cleared': False, 'magic1': 88, 'magic0': 159, 'packet_type': 87}
Apr 13 13:57:24 nixie weewx[368]: engine: StdConvert target unit is 0x1
Apr 13 13:57:24 nixie weewx[368]: wxcalculate: The following values will be calculated: barometer=prefer_hardware, windchill=hardware, dewpoint=software, appTemp=prefer_hardware, rainRate=hardware, windrun=prefer_hardware, heatindex=hardware, maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, cloudbase=prefer_hardware
'rain_rate',
'rainRate':
rainRate=hardware,
Mine is an out-of-box config, so if there needs to be a reference to "rain" (not rainRate), then can someone please advise how it should look?
Here are the only references to rain(.*) in my conf file:
pi@nixie:~ $ grep -i rain /etc/weewx/weewx.conf
# The start of the rain year (1=January; 10=October, etc.). This is
rain_year_start = 1
group_rain = inch # Options are 'inch', 'cm', or 'mm'
group_rainrate = inch_per_hour # Options are 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
rainyear = %x %X
rain = Rain
rainRate = Rain Rate
rainBatteryStatus = Rain Battery
rain = 0, 10, inch
rainRate = hardware
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Thomas Keffer
Apr 13, 2019, 2:44:46 PM4/13/19
to weewx-user
rain is not supplied directly by the WMR300, so it is not in the sensor map. It is calculated from differences in rain_total (see line 1295 in the driver).
If you want the driver to emit rain_total (not a bad idea, IMO), then it could be added to the sensor map.
[WMR300]
[[sensor_map]]
rainTotal = rain_total
This way you could see what WeeWX is working with.
-tk
Leon Shaner
Apr 13, 2019, 3:05:31 PM4/13/19
to weewx...@googlegroups.com
Hey, TK,
Gah. Embarrassing. :S
So it turns out, I am still getting this message in the logs, after all. :-(((((
Apr 13 14:46:16 nixie weewx[1182]: wmr300: possible missed rain event: new=10160.0 old=None
Apr 13 14:46:16 nixie weewx[1182]: wmr300: rain=None rain_total=10160.0 last_rain=None
Apr 13 14:46:16 nixie weewx[1182]: wmr300: rain counter at maximum, reset required
And that post you linked was me talking about holding the MEM button. Apparently it didn't work.
I just figured it out, though... I had to touch the RAIN indicator on the WMR300 a few times until I saw HHH ACCUM, (for which I presume "HHH" means "High High High").
Then I held the MEM button and that cleared the RAIN display to 0.00 in. ACCUM.
I think that should solve this one! Thanks for all the help!
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Cameron D
Apr 13, 2019, 4:05:32 PM4/13/19
to weewx-user
Hi Leon,
it seems you still have a problem with the archive data. As far as I recall the history in the console does not wrap around, so once it is full then the console never saves any more.
Your version of the driver is set to clear the history after it reaches 20% however your last index value looks to me greater than mine was when it was classed as full.
I suspect there is a bug in the code that means the unexpected high index count results in it not clearing at all.
Your firmware version A04 is the same as mine. Did you ever do a firmware update?
I would recommend a factory reset because I can't be sure how to tackle a history clear that has to read beyond what I think is the end of the buffer.
Cameron
Leon Shaner
Apr 14, 2019, 1:13:33 AM4/14/19
to weewx...@googlegroups.com
Hey, Cameron,
You are absolutely right! I did some digging and determined that my WMR300 is set to 1 minute internal data logging interval, which is good only for 22 days and has been full since 2016! I confirmed this by moving my SD card to a faster RPI and starting from a fresh weewx.sdb, and watched as it pulled in less than a month's worth of data from July of 2016, then said it was done processing the data from the unit.
I found the right doc on how to clear the WMR300's internal data log.
I'll set a reminder to do so every other Sunday.
It would be nice if the WeeWX WMR300 driver could automatically do a weekly purge of the oldest 1 week's worth of data. That would keep it well below the default 22 day limit.
I saw mention in the comments in the driver that the protocol does support purging of records after reading them.
Of course what is unclear is if you do purge the oldest 1-week worth of data does that actually free up space to allow the next week going forward?
Probably deserves some experimentation. :-/
Anyway, thanks for the note. =D
Here's that doc. Bear in mind the rain counter is reset separately by touching the rain display a few times until it say "ACCUM" and then you can hold the MEM button there to reset it. If it's full it says HHH for the total accumulation of rain.
I think I will write a mod and submit it via github to have a warning when the rain limit is at 90%. =D
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
--
Cameron D
Apr 15, 2019, 8:29:58 AM4/15/19
to weewx-user
Hi Leon,
I too use 1 minute intervals.
I wrote the code changes to automatically clear the history when it reaches x% full. The current version has these changes in, so you should be OK for now.
But search through the list archives to find the threads about WMR300 hanging - I have posted a patched driver that seem to fix those problems. For some users the WMR300 stops reporting but it has never been clear why this happens in the first place.
Warnings about the rain and the date mismatch would be great things to have, but I can't recall how far they have progressed. I am not at home to check.
Cheers,
Cameron
Leon Shaner
Apr 15, 2019, 11:41:27 AM4/15/19
to weewx...@googlegroups.com
Hey, Cameron,
First off, Matt did take my diff for adding a rain counter warning message to the wmr300.py already. =D It's a start in that it logs a warning. See my other note on what I did to trigger an e-mail via cron and mailx. =D
As an aside, 1% of the maximum rain-counter is something like a meter of rain, which is more than we get here in a typical year in Michigan. So that 90% warning will likely not come for several years. I have my warning set to 1% currently, just to make sure my code is doing what I expect. I tried it with 0% and it did log the message at least. =D
As for the WMR300 timing out / going non-responsive, I've had that happen just once so far and it seems to be happening at the USB driver level, because restarting weewxd was no help. The only symptom was that the weewx logging stopped (e.g. no further messages after a time).
I had to actually reboot the RPI to correct the issue (like I said a restart of weewx was no help -- it couldn't properly read from USB). :S
Fingers crossed that it doesn't happen again now that I've got things stabilized and am not bombarding the unit with history downloads. =D
After I used the *correct* procedure to clear the history, I do now see some helpful messages in the logs:
Apr 14 13:14:15 nixie weewx[6906]: wmr300: history limit is 20%
Apr 14 13:14:30 nixie weewx[6906]: wmr300: get history complete: count=0 last_index=762 latest_index=763
Apr 14 13:14:37 nixie weewx[6906]: wmr300: history buffer at 2.2%
Whereas, before I reset it, I saw:
Apr 13 20:48:56 nixie weewx[424]: wmr300: get history complete: count=0 last_index=32735 latest_index=32736
Apr 13 20:51:59 nixie weewx[424]: wmr300: history buffer at 100.0%
Apr 13 22:33:11 nixie weewx[1215]: wmr300: history limit is 20%
Apr 14 00:15:17 nixie weewx[1215]: wmr300: get history complete: count=32685 last_index=32735 latest_index=32736
Apr 14 00:15:36 nixie weewx[1215]: wmr300: history buffer at 100.0%
Apr 14 00:17:57 nixie weewx[1458]: wmr300: history limit is 20%
Apr 14 00:20:09 nixie weewx[1458]: wmr300: get history complete: count=0 last_index=32735 latest_index=32736
Apr 14 00:20:25 nixie weewx[1458]: wmr300: history buffer at 100.0%
Apr 14 00:45:35 nixie weewx[362]: wmr300: history limit is 20%
Apr 14 00:52:08 nixie weewx[362]: engine: Caught WeeWxIOError: Init history failed after 5 tries
Apr 14 00:53:08 nixie weewx[362]: wmr300: history limit is 20%
Did you see that error above? Looks like it tried to reset the history and couldn't. :S
And upon the actual reset (which I did using the *correct* procedure from the WMR300 unit itself):
Apr 14 01:02:30 nixie weewx[362]: wmr300: get history complete: count=0 last_index=30820 latest_index=32
Apr 14 01:02:50 nixie weewx[362]: wmr300: history buffer at 0.0%
The weewx attempt to clear the history must have done *something* after all, because you can see that before I reset it, the number had dropped from 32736 to 30820.
We can see that 32736+32 is 32768, a "magic" power of 2, so even the empty memory must contain 32 reserved records.
Anyway, I've set a reminder to check the history every two weeks in case the automatic clearing via weewx isn't working. :S
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)
Alberto Sánchez
Dec 12, 2019, 4:01:12 AM12/12/19
to weewx-user
I have had the same issue and I have solved it in the same way...
To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages