The three pictures look nice, as well those form Michael. I would mainly be interested, how the daily summary will be calculated. In this example, you have aboout 1.5mm at afternoon from WH40 vs. 0.6mm from WS90, right? OTOH I see two low measurements before and after this rain event, which are only measured at WS90. My simple approach would be, to count data from WS90, when no data are available from WH40, else count those from WH40. So I would not simply summarize both rain amounts, which would otherwise double some of the rain. I want, first, upload the rain data to windy, which will only be one value, preferably the calculated sum. And, second, I would like to see the this sum in the allTime table (https://github.com/glennmckechnie/alltimeSeasons), I have integrated into my Season skin. As far as I can look into it, this is a small version of the fuzzy-archer skin, Michael has used, right?
Concerning the room temperature, I was up to now not bothering about two gateways in one weewx instance and one database, as Michael described above. What would be the disadvantage? On the long run, I will, depending on the WAF here, expand the network in the living room and put the GW3000 there. Then I do not need an extra purchase (I was born near Augsburg, in a region, which is known to be very thrifty), as long as I have currently a functioning sensor working. Rainer Lang schrieb am Mittwoch, 9. Juli 2025 um 08:21:35 UTC+2: > > On 07.07.2025 22:30, Vetti52 wrote: > > Thank to all of you for your most valuable input. The only thing, that > makes me sad, is, that Vince describes the piezo rain sensor as „horrible“. > That is, because I bought this sensor array to improve the rain data, > especially, when rain is drizzling. > Michael‘s approach of one Weewx instance, one database and two gateways is > promising to me. I would, instead of two GW2000, implement one GW1000 clone > and one GW3000. *As far as I can understand, I could collect all data in > the GW3000 already. But, as I want to continue measuring the living room > temperature and humidity, which are actually provided by the GW1000, I > prefer to use both gateways. I would then read the data from WH65 clone > through GW1000, as is, and in addition the data from WS90 through the new > GW3000.* > > if the only purpose of this additional GW1000 is to get indoor temperature > readings, why not use another WH31 sensor (extra T/RH) instead and connect > it to your GW3000 ? > The GW3000 can manage up to 8 extra T/RH. You would not need the (maybe > interesting) pain of organising two weewx instances and do everything with > one instance. > > Then the task of Weewx is, to merge the data into one database and present > them, a little more sophisticated as I have it now in a regular seasons > skin. > My aim is, to merge the rain data in a similar way, as Michael did it with > the wind data in his example. *So, when there is no rain from WH65 but > from WS90, the piezo rain data should be used instead, otherwise the data > from WH65. Don‘t know, if this would work not only for wind, but also for > rain data?* > > And why not have both in parallel ? you can show them in your skin by > adding a new picture or creating a combined WH65/WS90 chart. > > I have done this myself. I have a separate picture for each rain sensor > and a combined summary picture ... > > As of temperature, I would collect both sensor data, as is could be > interesting to see differences at 6m od 2m AGL. Humidity I would ignore > from 6m AGL data. I have an extra temperature/humidity sensor in a shack > near by, which is currently collected from GW1000. *Should I move this to > the new GW3000, just in case, I want to save the data on a SD card lateron?* > > > There's not should. That's your choice. But, yes you could register it to > your GW3000. > > [email protected] schrieb am Montag, 7. Juli 2025 um 20:46:35 UTC+2: > >> 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/68d36fb8-d461-4e22-951d-8d94ad0e0b85n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/68d36fb8-d461-4e22-951d-8d94ad0e0b85n%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/d83ad090-0bca-475c-8dc1-9e825f212c68n%40googlegroups.com.
