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.
