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.
