Or you can try the other version which is Gary’s original.
https://claydonsweather.org.uk Try " PYTHONPATH=/etc/weewx/bin:/usr/share/weewx python3 --test-driver --ip-address=device-ip-address" and see if that helps....
On Tuesday, August 26, 2025 at 6:35:07 AM UTC-7 Francisco Alonso wrote:
Hi guys.
I am trying to get this up and running in my RPi, but I am afraid I do not have the required knowledge to get it to work without a set of instructions. As there is no installation package like with the previous driver, I have read the README file in the fork from Werner.
My setup is Weewx with a package installation, which worked OK with the previous driver by Gary.
I have copied the ecowitt_http.py file from Werner's into my system and modified weewx.conf as per Werner's info on the README file and now the driver part looks like this:
[EcowittHttp]
# the driver to use
driver = user.ecowitt_http
# how often to poll the device
poll_interval = 20
# how many attempts to contact the device before giving up
max_tries = 3
# wait time in seconds between retries to contact the device
retry_wait = 5
# max wait for device to respond to a HTTP request
url_timeout = 10
# whether to show all battery state data including nonsense data and
# sensors that are disabled sensors and connecting
show_all_batt = False
# whether to always log unknown API fields, unknown fields are always
# logged at the debug level, this will log them at the info level
log_unknown_fields = True
# How often to check for device firmware updates, 0 disables firmware
# update checks. Available firmware updates are logged.
firmware_update_check_interval = 86400
# do we show registered sensor data only
_only_registered_ = True
# Is a WN32P used for indoor temperature, humidity and pressure - default = False
#wn32_indoor = True
# Is a WN32 used for outdoor temperature and humidity - default = False
#wn32_outdoor = True
#former debug_logging (here for wind) not more supported!:
#debug_wind = False
#debug_logging new with list:
#debug = rain, wind, loop, sensors, parser, catchup, collector, archive
debug = parser, sensors, catchup
catchup_grace = 0
ip_address = 192.168.1.201
api_key = 440cd2c9-8919-4836-a2e8-xxxxxxxxxxxx app_key = D7FB394F84DFAB3345E6C3Bxxxxxxxxx
mac = 5C:01:3B:42:xx:xx
[[catchup]]
# source = either, both, net, device ## not set = None, default is then either or both
The log attached shows all the errors, but I am pretty lost on whatever is not correct as it references files and processes and I do not understand weewx internal protocols to make it work.
Lastly, a python3 /etc/weewx/bin/user/ecowitt_http.py --test-driver --ip-address=device-ip-address returns the following:
Traceback (most recent call last): File "/etc/weewx/bin/user/ecowitt_http.py", line 199, in <module>
import weecfg
ModuleNotFoundError: No module named 'weecfg'
If anyone can point me on the right direction, please. I am quite lost as you can see.
Thank you. This interval (300s) had only 0.1mm p_rain with the old ecowitt gateway driver.
Just caught a LOOP package:
LOOP: 2025-08-21 20:17:16 CEST (1755800236) 'p_rain': '0.10000000000002274',
Which looks correct. The value written to the database in this interval: 0.00344827586206975
Werner Krenn schrieb am Donnerstag, 21. August 2025 um 20:10:43 UTC+2:
Ok, I use hail instead of p_rain and with hail the value has to be multiplied by a factor of 25.4 to get a correct display,but only for the graphs, the value is always correct.
[[[dayrainbar]]]
yscale = None, None, 0.02
plot_type = bar
y_label = "mm"
[[[[rain]]]]
aggregate_type = sum
aggregate_interval = 600
label = Rain WH40 (10min)
[[[[hail]]]]
data_type = hail * 25.4
aggregate_type = sum
aggregate_interval = 600
label = Rain Piezo (10min)
[[[[ET]]]]
color = "#edba21"
aggregate_type = sum
aggregate_interval = 600
label = ET (10min)
steepleian schrieb am Donnerstag, 21. August 2025 um 16:46:03 UTC+2:
I am actually working on a complete re-write which will also incorporate live data output in a json file. It will also have the option of subscribing to to MQTT topic published directly from the gateway device using the new Ecowitt in built MQTT weather service. No, the WS90 itself has a resolution of 0.1mm, but I get increments < 0.01mm in the database, which shouldn't be possible. It's with with Werner's v0.2.2. When receiving LOO data emitted through weewx_mqtt, I receiver the correct 0.1mm increments.
steepleian schrieb am Donnerstag, 21. August 2025 um 16:17:16 UTC+2:
Michael, Are you describing the fact there are an insufficient number of decimal places to record small quantities of rain? Ian I still have an Issue with storing p_rain values in the database. In the database (metricwx) are values well below 1/10mm, while from the Loop p_rain values of x/10mm are reported.
Currently (and the next hours) it is raining, the live chart rises in x/10mm steps, when the values are loaded from the db after a refresh, p_rain ist much lower than rain from the traditional gauge.
OK, I've set
[StdWXCalculate]
[[Calculations]]
rainRate = software
Setting it to
[StdWXCalculate]
[[Calculations]]
rainRate = prefer_hardware
And it's there. The question now is, how is the hardware calculating it compared to weewx? The WS28xx did it on a hourly basis, weewx afaik on a 15min basis. Indeed. A quick test shows the value are now being backfilled. But for "rain" the "rainRate" doesn't seem to be calculated correctly, or at all: it is zero. Interestingly "p_rainRate" is calculated correctly when backfilled. But to be honest: I don't know if the issue is only when being backfilled, I'll check that real quick. It's raining cats and dogs, so it won't take too long :D
Werner Krenn schrieb am Samstag, 2. August 2025 um 17:02:55 UTC+2:
>
When backfilling data from the GW3000s SD Card, no rain is imported into the database.It seems that you are not using the current version 0.2.0
When backfilling data from the GW3000s SD Card, no rain is imported into the database. There is no "rain" in the REC. I'm not so familiar with the process, but I guess there is something missing in my weewx.conf that is calculation rain from the RECs. By the way, is there a documentation what the [Accumulator] is all about and when and how it is to be used?
REC: 2025-08-01 17:18:00 CEST (1754061480) 'altimeter': '1013.6569194849516',
'appTemp': '23.50738354280469',
'barometer': '1011.2',
'cloudbase': '1372.254710571006',
'co2': '342.0',
'co2_Hum': '59.0',
'co2_Temp': '22.9',
'dateTime': '1754061480.0',
'dayRain': '0.6',
'dewpoint': '14.8',
'drain_piezo': '0.0',
'erain_piezo': '0.0',
'ET': '0.015721295892854044',
'eventRain': '15.1',
'extraHumid1': '51.0',
'extraHumid2': '70.0',
'extraHumid3': '64.0',
'extraHumid4': '64.0',
'extraHumid6': '49.0',
'extraHumid7': '66.0',
'extraHumid8': '66.0',
'extraTemp1': '20.2',
'extraTemp2': '21.5',
'extraTemp3': '21.7',
'extraTemp4': '21.9',
'extraTemp5': '21.1',
'extraTemp6': '19.7',
'extraTemp7': '21.9',
'extraTemp8': '21.6',
'hailRate': '0.0',
'heatindex': '22.314444444444444',
'hourRain': '0.0',
'humidex': '26.22374343350731',
'inDewpoint': '15.474126948319904',
'inHumidity': '63.0',
'inTemp': '22.9',
'interval': '5',
'lightning_dist': '20.0',
'lightning_distance': 'None',
'lightning_disturber_count': '1754038860.0',
'lightning_strike_count': '0.0',
'lightningcount': '0.0',
'luminosity': '31810.569',
'maxSolarRad': '481.7560939781643',
'monthRain': '0.6',
'mrain_piezo': '0.0',
'outHumidity': '62.0',
'outTemp': '22.4',
'p_rainrate': '0.0',
'p_rainyear': '0.5',
'pm2_5': '2.9',
'pm10_0': '3.2',
'pressure': '961.8',
'radiation': '251.07',
'rainRate': '0.0',
'rrain_piezo': '0.0',
'soilMoist1': '52.0',
'soilMoist2': '42.0',
't_rain': '15.1',
't_rainRate': '0.0',
't_rainyear': '235.2',
'usUnits': '17',
'UV': '2.0',
'vpd': '10.3',
'weekRain': '89.8',
'windchill': '22.399999999999995',
'windDir': '285.0',
'windGust': '1.0',
'windrun': '0.18',
'windSpeed': '0.6',
'wrain_piezo': '0.0',
'yearRain': '235.2',
'yrain_piezo': '0.5'
Werner Krenn schrieb am Samstag, 26. Juli 2025 um 20:20:45 UTC+2:
@Michael,>
Did you have BBQ for dinner?
No ;) It is this problem, described on the Ecowitt homepage: ★★Note: 3.The sensor is sensitive to liquid droplets - rain/fog/sprinkling. When the Dew Point is close to the outdoor temperature(T - D < = 2C), the PM2.5 reading will be very high(which is not the real condition).
Not too far away from my location. Did you have BBQ for dinner?![2025-07-26 19_58_10-Das Wetter in Lackenhäuser .110 - Brave.png]() By the way, fuzzy-archer is currently at 4.4 :) Werner Krenn schrieb am Samstag, 26. Juli 2025 um 19:12:27 UTC+2:
@Ian,
1) Rain
I know this behavior (also with lightning) when the gw1000 driver also is started
as a service or the original ecowitt_http driver (0.1.0a28) is used
and data is read from Ecowitt.net (Cloud) or SDcard
2)Ecowitt special database schema:
At the very beginning, I used wview_extended.
However, as more and more sensors were added, I expanded this schema into a new database schema, wview_ecowitt.
This contains all possible Ecowitt sensors. However,
self-selected signals are assigned to the existing fields signal1..signal8 in
[StdCalibrate]
[[Corrections]]
and extrapolated to 0..100 percent (*25).
And since 'hail' or 'pb' were present but unused, I mapped Piezo Rain or Heap to them.
There is also a script file (add_ecowitt_allsignaldata_v5.sh) that can add all signals to the database.
The same applies to all new RSSI values with the script file
add_ecowitt_allrssidata_v5.sh
The script files and schema file can be found on Github
Skins with the data from ecowitt_http (in German!)
Skin Seasons Ecowitt: https://www.pc-wetterstation.de/wetter/weewx8
Skin Bootstrap: https://www.pc-wetterstation.de/wetter/weewx8/bootstrap/index.html
My issue with p_rain is that the driver uses p_rainrate and my database has the column p_rainRate (camelCase), which is the WeeWX db style to name columns, thus I need to configure:
[StdCalibrate]
[[Corrections]]
p_rainRate = p_rainrate
I still have the one or the other issue with p_rain, but that's very special to my ssetup running ecowitt_http as a driver and GW1000 as a service. And I so far couldn't confirm how the lightning detection works out with my settings.
Ian Millard schrieb am Freitag, 25. Juli 2025 um 16:36:35 UTC+2:
@Michael, @Werner, @Vince,
I have the WeeWX-Ecowitt_http working flawlessly in driver mode now. So much so that I have confidently moved it across to my live server.
There are just a couple of things to mention: -
1. Using the rain column to generates day, week, month etc gives some rather bizarre results as @Michael discovered. The safe way to go is dayRain, weekRain etc which give the expected results. 2. It makes sense to me that if a dedicated Ecowitt database schema is the way to go. If this is the case, the examples of this that are already out there need to come together to agree a standard. The example I quoted in an earlier post of using the hail column for piezo rain, I understand why this was done in the first instance, but surely if we speak about a dedicated schema, piezo rain should be fully supported in its own right?
I will be interested in our collective thoughts on this.
Thanks, I only use these entries in the weewx.conf [StdCalibrate] [[Corrections]] lightning_distance_save = lightning_dist if lightning_dist is not None else None lightning_distance = lightning_dist if lightning_strike_count > 0 else None lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None [Accumulator] [[lightning_distance]] extractor = last [[lightning_strike_count]] extractor = sum [[lightning_last_det_time]] extractor = last [[lightningcount]] extractor = last [[lightning_noise_count]] extractor = sum Ian Millard schrieb am Montag, 21. Juli 2025 um 20:01:38 UTC+2:
@Werner,
How do you generate the last non-zero strike distance and time? I have an X-Type to do that, but maybe you have another way. lightning_numis the number of lightning strikes on this daylightning_strike_countis the difference from the previous archive value.That's the only way I know it, and that's how it is now again.I use additionally[StdCalibrate] [[Corrections]] lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None[accumulator] [[lightning_noise_count]] extractor = sumThis allows me to display the last recorded number of lightning strikes per day without them disappearing after one day.michael.k...@ gmx.at schrieb am Mittwoch, 16. Juli 2025 um 22:29:28 UTC+2: I've updated ecowitt_http.py (warnings gone), set debug = rain, removed the corrections entry for p_rain and here is the log. No No more p_rain with the updated setting and the most recent version. (And yes, we had an considerable amount of rain here today, ~ 40mm so far and counting) By the way:
"lightning_num": "23",
"lightning_strike_count": "0",
Today 23 strikes were registered. What's the change here, the old driver set the lightning_strike_count.
Werner Krenn schrieb am Mittwoch, 16. Juli 2025 um 21:13:27 UTC+2:
Of course, it was meant to be debug at EcowittHttp:
[EcowittHttp]
debug = rain
With the current version, under
[[Corrections]]
p_rain = hail if hail is not None else None
is no longer necessary!
I've never heard of such an issue nor have I encountered one, but this one so far with the GW3000
I have mapped p_rain for piezo_rain with
[StdCalibrate]
[[Corrections]]
p_rain = hail if hail is not None else None
With debug = rain WeeWX didn't start, I've set logging to : debug = 3 [Logging]
version = 1
disable_existing_loggers = False
# Root logger
[[root]]
level = INFO
handlers = rotate, #console
# Additional loggers would go in the following section. This is useful for tailoring logging
# for individual modules.
[[loggers]]
[[[user.ecowitt_http]]]
level = DEBUG
# Definitions of possible logging destinations
[[handlers]]
# Log to a set of rotating files
[[[rotate]]]
level = INFO
formatter = verbose
class = logging.handlers.RotatingFileHandler
filename = /home/wusr/weewx-data/log/weewxd.log
maxBytes = 10000000
backupCount = 4
Werner Krenn schrieb am Mittwoch, 16. Juli 2025 um 18:50:04 UTC+2:
Please set
debug = rain
What is mapped for piezo_rain?
By the way, this behavior is why I changed the calculation of rain and piezo_rain.
Connection issues:
Have you read about the issue with GW3000 1.0.9 on GitHub?
After a failed connection to the GW300, this happened with the piezo rain data:Left: Old Ecowitt Gateway driver with GW2000, Right: ecowitt http driver with GW3000: From the log: 2025-07-16 13:28:17 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:16 CEST (1752665296)
2025-07-16 13:28:27 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:27 CEST (1752665307)
2025-07-16 13:28:37 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:37 CEST (1752665317)
2025-07-16 13:28:47 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:47 CEST (1752665327)
2025-07-16 13:29:07 weewxd[19407] ERROR user.ecowitt_http: URL - Failed to get device data on attempt 1 of 3
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: **** <urlopen error timed out>
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: Unable to obtain live sensor data
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Main loop exiting. Shutting engine down.
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Shutting down StdReport thread
2025-07-16 13:29:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector thread has been terminated
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: Caught WeeWxIOError:
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: **** Waiting 60.0 seconds then retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Loading station type EcowittHttp (user.ecowitt_http)
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpDriver: version is 0.1.0
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unit_system: 17
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device IP address is 10.0.1.84
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: poll interval is 10 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: rain debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wind debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: lightning debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: loop debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: sensors debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: parser debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: collector debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: archive debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_indoor: sensor ID decoding will use indoor 'WN32'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_outdoor: sensor ID decoding will use outdoor 'WN32P'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device firmware update checks will occur every 86400 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: available device firmware updates will be logged
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: battery state will not be reported for sensors with no signal data
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unknown fields will be ignored
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup source: device
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector startup
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: StdConvert target unit is 0x11
2025-07-16 13:30:09 weewxd[19407] INFO weewx.wxservices: StdWXCalculate will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Archive will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Record generation will be attempted in 'software'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using archive interval of 300 seconds (software record generation)
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: StationRegistry: Registration not requested.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: Wunderground: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: PWSweather: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: CWOP: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: WOW: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: AWEKAS: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: service version is 0.24
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: binding to loop
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data_binding is wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: topic is weather_test_ws90
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data will be uploaded to mqtt://10.0.1.90:1883/
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: 'pyephem' detected, extended almanac data is available
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: Starting up weewx version 5.1.0
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using binding 'wx_binding' to database 'weewx-ws90.sdb'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Starting backfill of daily summaries
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Daily summaries up to date
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'rain.0x13.val' for rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1.0: no last count
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to database 'weewx-ws90.sdb'
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to daily summary in 'weewx-ws90.sdb'
2025-07-16 13:30:13 weewxd[19407] INFO weewx.engine: Starting main packet loop.
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'rain.0x13.val' for rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping rain measurement of 600.4: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping piezo rain measurement of 691.3: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1: no last count
2025-07-16 13:30:13 weewxd[19407] INFO user.mqtt: client established for mqtt://10.0.1.90:1883/
2025-07-16 13:30:13 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:09 CEST (1752665409)
2025-07-16 13:30:19 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:19 CEST (1752665419)
2025-07-16 13:30:30 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:29 CEST (1752665429) The warnings shows up once, after the ecowitt_http.py was altered when a new pycache object is created, only showing up when starting weewxd manually. It is console output not being logged.
vince schrieb am Montag, 14. Juli 2025 um 20:03:48 UTC+2:
On Monday, July 14, 2025 at 9:29:24 AM UTC-7 steepleian wrote:
@Werner I find it very confusing that hail is used for p_rain. My database has columns for p_rain etc from mods I made for GW2000 driver.
Agree. I notice that weewx doesn't directly support multiple wind nor rain sensors, so folks with a combination if piezo and old-style spinning/tipping sensors have issues mapping database elements.
Rather than requiring modifying the as-delivered weewx schema, I'm wondering if an alternate approach might be to create an ecowitt-specific schema and a secondary db for whatever ecowitt supports. Granted, skins would need to explicitly reference the ecowitt db binding, but it would make the database mapping issue a non-issue.
FWIW - the purpleair extension I use as well as a couple other extensions create these alternate databases on first use, so it's not a big deal. You might consider taking the same approach for ecowitt which has a growing list of uniquenesses as they add more and more sensor types users can purchase.
That said, I do not know offhand if it is possible to have a driver's sensor_map use a secondary db rather than the default db. That might be helpful to be able to do, or even to map each sensor_map item to the chosen db+element to read from.
-- 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].
--
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].
--
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].
--
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].
--
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 visit https://groups.google.com/d/msgid/weewx-user/f629b1e2-242b-4c5c-9a7b-e6e219e99f8dn%40googlegroups.com.
--
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 visit https://groups.google.com/d/msgid/weewx-user/3FEDF487-05A4-49C5-A8F9-1E1C40D7B598%40btinternet.com.
|
