What I am describing is one WeeWX instance and one database, but two GW2000 devices, that WeeWX is reading data from using the Ecowitt Gateway driver. The one GW2000 with the driver as a driver, the other with the driver as a service, using only particular obs_types from the unit as a service.
I further describe two other WeeWX instances, connecting to a single GW2000 (either one of the two) as a driver. So, all in all three WeeWX instances, three databases, two GW2000. Rainer Lang schrieb am Montag, 7. Juli 2025 um 19:53:15 UTC+2: > correct, > the WS85 restriction applies to the GW1000 and WH2650/2680 only - all > other consoles (e.g. GW> 1100) with local API can also receive and process > a WS85. > On 07.07.2025 19:49, vince wrote: > > Minor correction. You ‘can’ use Gary’s original ecowitt driver with a > WS85 if you have a console/gateway newer than a gw1000. Mine works fine > with a gw1200 and also with a ws3800 console/gateway using Gary’s driver > as well. > > My recollection is the ws85 should also work with the gw1100 also > according to info from last year, but I did not test that. I simply bought > a gw1200 to the latest model of that kind of gateway. > > I worked with Gary last June to add ws85 support in his driver, FWIW. > > On Monday, July 7, 2025 at 10:11:11 AM UTC-7 Rainer Lang wrote: > >> 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/885ae40a-0d25-484f-8fa6-75a0d0db8451n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/885ae40a-0d25-484f-8fa6-75a0d0db8451n%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/5446fc0f-fc4b-4d6d-bb77-2208b52262a7n%40googlegroups.com.
