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
I ran that through "fmt -1 | sort -u" and these are the only references to
rain(.*) seen:
'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)
> On Apr 13, 2019, at 1:10 PM, Leon Shaner <[email protected]> wrote:
>
> 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)
>
>> On Apr 13, 2019, at 11:23 AM, Thomas Keffer <[email protected]> wrote:
>>
>> 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
>>
>>> On Sat, Apr 13, 2019 at 8:10 AM Leon Shaner <[email protected]> wrote:
>>> 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)
>>>
>>>> On Apr 13, 2019, at 11:06 AM, Thomas Keffer <[email protected]> wrote:
>>>>
>>>> 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
>>>>
>>>>> On Sat, Apr 13, 2019 at 7:18 AM Leon Shaner <[email protected]> wrote:
>>>>> 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)
>>>>>
>>>>>> On Apr 12, 2019, at 8:43 PM, Thomas Keffer <[email protected]> wrote:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>> On Fri, Apr 12, 2019 at 12:28 PM Leon Shaner <[email protected]> wrote:
>>>>>>> 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 :
>>>>>>> https://www.wunderground.com/dashboard/pws/KMIDEARB5/graph/2016-07-12/2016-07-12/daily
>>>>>>> Above 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/daily
>>>>>>> NOTE: 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)
>>>>>>> --
>>>>>>> [email protected] - Dearborn, Michigan
>>>>>>> --
>>>>>>> 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].
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>> --
>>>>>> 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].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> 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].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> 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].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> 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].
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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].
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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].
> For more options, visit https://groups.google.com/d/optout.
--
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].
For more options, visit https://groups.google.com/d/optout.
