I have two GW2000, a WN32, a WS90, a WS68, a WH40, a WH57 and all
this devices are feeding one WeeWX instance. Each GW2000 can only
handle either the WS68 or the WS90. See the excerpt of my
weewx.conf below. What my setup does is:
- mixing Wind speeds from both sources, assuming that the current
higher reading is the correct one (WS68 can freeze, WS68 shows
zero wind in very light conditions, hence the assumption)
- preferring the WS68 light sensor over the one from WS90
- adding the piezo rain sensor.
The GW2000 with the IP 10.0.1.85 is the one with the WS68, the
one with the WS90 is 10.0.1.86
The station is configured using the Ecowitt Gateway Driver as a
Driver for 10.0.1.85 and as a Service for 10.0.1.86
In the[GW1000Service] stanza there is a field map to map the
conflicting obs_types and piezo sensor values. This is also
leading to what you would call /"silencing specific sensors of
the array"/. For instance, I don't have a
"ws90_uvradiation"-column in my database, so the WS90 UV reading
is "silenced". In my database, I only added p_rain and p_rainRate.
In the [[Corrections]] stanza, the logic for using preferred wind
readings is defined.
You can view the result here:
https://kainzbauer.net/weather/Rif/en/index.html
Two other weewx instances run both GW2000 separately as a
service, without mixing values, compare the results:
https://kainzbauer.net/weather/Rif/gw2000/index.html (WS68) (no
piezo rain values)
https://kainzbauer.net/weather/Rif/dp2000/index.html (WS90)
[Station]
station_type = GW1000
[StdCalibrate]
[[Corrections]]
radiation = luminosity/126.7 if luminosity is not None
else None
lightning_distance = lightning_distance if
lightning_strike_count > 0 else None
windSpeed = ws90_windSpeed if 'windSpeed' not in locals()
else windSpeed if 'ws90_windSpeed' not in locals() else
ws90_windSpeed if ws90_windSpeed > windSpeed else windSpeed
windGust = ws90_windGust if 'windGust' not in locals()
else windGust if 'ws90_windGust' not in locals() else
ws90_windGust if ws90_windGust > windGust else windGust
windDir = ws90_windDir if 'ws90_windDir' in locals() and
ws90_windDir is not None else windDir
[GW1000]
# This section is for the Ecowitt Gateway driver.
# How often to poll the API, default is every 20 seconds:
poll_interval = 10
ip_address = 10.0.1.85
max_tries = 360
# The driver to use:
driver = user.gw1000
[GW1000Service]
#debug_loop = True
# This section is for the Ecowitt Gateway driver.
# How often to poll the API, default is every 20 seconds:
poll_interval = 10
ip_address = 10.0.1.86
max_tries = 360
# The driver to use:
driver = user.gw1000
[[field_map]]
ws90_windDir = winddir
ws90_windSpeed = windspeed
ws90_windGust = gustspeed
ws90_daymaxwind = daymaxwind
ws90_uvradiation = uv
ws90_UV = uvi
ws90_luminosity = light
p_rain = p_rain
p_stormRain = p_rainevent
p_rainRate = p_rainrate
p_dayRain = p_rainday
p_weekRain = p_rainweek
p_monthRain = p_rainmonth
p_yearRain = p_rainyear
vince schrieb am Montag, 7. Juli 2025 um 17:34:28 UTC+2:
If you don’t need backfill you can possiblt still use the
original driver.
Two issues. The first is whether your old gateway can read
data from a new model sensor. I had to upgrade from my old
gw1000 gateway to a gw1200 to be able to hear a newer ws85
sensor.
The second issue is how to merge multiple sensors into one
weewx database. Generally you just need a sensor-map to
select which wind or rain sensor to use. Worst case two
instances and MQTT should work.
FWIW my experience is that the ecowitt piezo rain sensors are
horrible. I found no way to calibrate my rain readings to be
able to believe them even with a calibrated cocorahs manual
gauge nearby. I gave up trying and took the ws85 down. I
never worked trying to see if its wind readings were good or not.
On Monday, July 7, 2025 at 4:48:05 AM UTC-7 Vetti52 wrote:
So, my first approach seems to be promising. Maybe, I
will at first, run the Wittboy in parallel, without
integration into Weewx and compare the data and
calibrate, when possible. At least I will have to omit
the wind data, because in the area there will be no
suitable place to measure the wind speed and orientation,
because at an elevation of 2m AGL there are too many
turbulences and will result in a data mess pretty sure.
As far, as I have read the documentation of GW1000 or
GW3000, there is no method to silence specific sensors of
the array. So I will have to find out, how to ignore wind
data in Weewx. Am I right?
Besides, since now, I never needed to backfill data from
Ecowitt or WU. So, I hope, this remains that way, and I
do not need the new backfill method. However, I am not
sure, if there are other advances, which will urge
Ecowitt users to switch to the http based driver, Gary
was working on. But, maybe, there is some progress on
this project from other specialists here in the forum,
that can enlighten me meanwhile.
Thanks so far
Peter
[email protected] schrieb am Freitag, 4. Juli 2025 um
19:31:42 UTC+2:
I use two GW2000 with one WeeWX instance, one with
the Ecowitt Gateway Driver as a Driver, the other
one with the Ecowitt Gateway Driver as a Service. I
am on 0.6.3, which isn't capable of backfilling data
from the gw3000s SD-storage in case your WeeWX wasn't
running for whatever reason.
Vetti52 schrieb am Freitag, 4. Juli 2025 um 18:46:51
UTC+2:
Since a couple of years I have an EFWS2900
working without any failure now. This is an
Ecowitt 2900 clone, positioned on a pole at 6m
above ground. It has a colored console, which is
just used for visual checks. I added a Froggit
DP1500, which is a clone of Ecowitt GW1000,
serving as source for weewx, using the GW1000
driver, version 0.6.3. This works perfectly.
However….
When there is only drizzling rain, the sensor
does not react. I therefore decided, to add
another rain sensor, which should be positioned
at 2m AGL.
My current approach is:
I have purchased an Ecowitt GW3001 (coming next
week), which consists of a Wittboy sensor set and
a GW3000. I plan to replace the WS2900 on the
pole with the Wittboy and place the WS2900 at a
position 2m AGL nearby. This should then be used
for additional rain measurement only.
The GW3000 should be connected per LAN, situated
directly at the router in the basement. The
temperature sensor is thus not relevant. The old
GW1000 remains in the living room for temperature
and, maybe, for pressure measurement.
So, I need a setup for collecting data from the
GW1000 and GW3000. My first approach was, to stay
with the current setup using the GW1000 driver,
and ad the GW3000 with a second GW1000 driver,
but running as a service.Is this possible? And,
if yes, how should I configure weewx to „merge“
the data into an arrangement, which provides a
„smooth“ transition?
I have seen the thread started from gjr,
concerning a separate GW3000 driver, which
indicates, that there are improvements coming,
concerning Ecowitt drivers at all. But the actual
situation of gjr being „offline“, touches me
considerably.
So, I am hesitating to follow my approach. Or
should I, instead, replace the complete GW1000
driver based data collection setup by something,
which is more „up to date“, and which needs,
however, still to be developed?
--
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/08a6ad8a-1b41-40e7-8e36-1f21d75af376n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/08a6ad8a-1b41-40e7-8e36-1f21d75af376n%40googlegroups.com?utm_medium=email&utm_source=footer>.
