Reading the thread I think there is some potential confusion ...
Hence the whole story in short below:
1. the GW1000, GW1100, GW1200, GW2000, GW3000 - all Ecowitt consoles
with the local Ecowitt API, the binary local API for which the weewx
local API driver is there, can handle all existing Ecowitt sensors with
the exception of a WS85, a WH46 and a WH54 (LDS01) sensor.
2. If you also want to include the WS85, WH46 and LDS01 sensor, you need
to use the local http API for which an experimental weewx version exists
(EcowittHttp driver) or an extended Interceptor driver.
3. You can connect to a console all available sensors and sensor arrays
in type and number following the compatibility matrix:
https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#b_console_-_sensor_-_maximum_number_and_display_tables
4. if you have multiple sensors for the same observation (rain, wind,
outdoor temperature and solar) connected, the console applies a priority
scheme called sensor hierarchy
https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#sensor_hierarchy
that means you don't need special observation assignment via
StdCalibrate or a Field Map extension - the console has already
preselected - the other multiple occurrences are discarded by the
console. You cannot have the wind data from WS68 and WS90 (or WS69 or
WS85 or WS80) at the same time with one and the same console. If you
want this, you need a second weewx instance fed by a console which is
connected to the respective arrays and excludes the not wanted data
(disable sensor in the console configuration)
What @Michael is describing are two weewx instances, only not two weewx
databases - an interesting approach which obviously works.
5. You can have traditional a rain (a WS69/WH65 outdoor array or a WH40
or a WN20) in parallel with a haptic (piezo) rain sensor (WS85, WS90).
If you want to store both in the weewx database, you have to either
create a new database column in the wview_extended database schema or
repurpose an existing field (e.g. hail and hailRate); then you have to
assign the p_rain and p_rainRate to the hail and hail_rate database
fields either via StdCalibrate or a Field Map extension.
6. As long as no WH46, WS85 or LDS01 is used, the binary local Ecowitt
API driver 0.6.x is good enough
7. if you want SD card or Ecowitt Cloud backfilling at startup, the new
(still experimental but 99% working) Ecowitt_http driver will be needed.
Long story short:
the OP (@Vetti52) can use the "old" (binary) local Ecowitt API driver
for his purpose as no backfill is needed, and if he also wants to see
the rain history data from his WH65 outdoor array (from the WH2910
clone), in his report (skin) and not only as current data, he will have
to archive the p_rain and p_rainRate data separately from the t_rain and
t_rainRate data.
On 07.07.2025 17:41, '[email protected]' via weewx-user wrote:
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>.
--
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/db14a347-3b98-4ac5-91ff-cd3c71049446%40gmail.com.
