Seeking for advice for integration of GW3001

[Vetti52]

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?

[michael.k...@gmx.at]

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]

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

[vince]

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.

[michael.k...@gmx.at]

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

[Rainer Lang]

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.

--
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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/08a6ad8a-1b41-40e7-8e36-1f21d75af376n%40googlegroups.com.

[vince]

 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.  

[Rainer Lang]

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.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/885ae40a-0d25-484f-8fa6-75a0d0db8451n%40googlegroups.com.

[michael.k...@gmx.at]

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.

[Vetti52]

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.

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?

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?

[vince]

The downside of the ecowitt piezo rain sensor is that the ‘user’ has to figure out how to tune its settings, it does not read correctly as delivered out of the box. The instructions are in minimal badly translated english as well which doesn’t help. I gave up after a few attempts at finding tunings that were accurate.,

Their manual even says to buy their standalone gauge…see section 9 of the WS90 manual. https://oss.ecowitt.net/uploads/20250314/WS90-0314.pdf#page20

Their specs say rain is +/- 20% accuracy. Wow.  Their standalone WH40H colllector claims 10%.but at least it is more inexpensive.

Just as a point of reference, the Davis VP2 claims 3% accuracy which is true based on the light rain we get here near Seattle during the wet season. I compare mine frequently with a calibrated CoCoRAHS manual gauge.

[michael.k...@gmx.at]

To compare: https://kainzbauer.net/weather/Rif/en/stats.html
The linked page lists rain and piezo rain per day/month/year

My WS90 is vanilla, I did not tune any settings. While a bucket is agnostic to the type of rain, the piezo sensor isn't. Large drops vs. mist make a difference. After a longer period of time the sums of the different sensors aren't that much away from each other. I don't give much about the sum the piezo sensor is reporting, but it delivers information when there is only a little rain or very light rain, which sometimes the bucket doesn't recognize at all. 

[Rainer Lang]

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.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/68d36fb8-d461-4e22-951d-8d94ad0e0b85n%40googlegroups.com.

[Ian Millard]

@michael

Those are exactly my findings. I also have a piezo rain sensor and tipping rain sensor with the funnel upgrade and I feel they complement each other perfectly. Yes they work out much the same in the end but the piezo is much better at sensing the very fine rain which frequently occurs in this part of the world which the tipping sensor never registers. 

--
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 weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/507402e1-6c70-498d-9fef-aad3644d1f47n%40googlegroups.com.

[DrVet52]

So, I need a sophisticated solution to combine both data into one report for my upload to windy and for a proper report in my allTime Seasons skin, which is a simpler derivate from the Fuzzy-Archer skin.

I hope, this post will be published, as currently all my posts are blocked in this forum. So, if this post will partly double up, sorry.

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/rwdy_SwGW8o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/3FCDEAAF-47A7-426D-89D7-75967F1C0F6C%40btinternet.com.

[Vetti52]

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.

[Glenn McKechnie]

On Thu, 10 Jul 2025 at 23:03, Vetti52 <drv...@gmail.com> wrote:

[...]

 

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

It's a fork of gedgers repo

https://github.com/gedger/alltimeSeasons/

which (in its first release in 2020) attributes

https://github.com/brewster76/fuzzy-archer

Yes, It's a simpler version and because of that origin timing it won't have any of the extras that the latest version of fuzzy-archer may have / has added.

I added an extra totals column, changed some colors, then packaged it as an installable skin (per weewx style), and that's about it. 

Anything else would need to be adapted from the current fuzzy-archer and incorporated into it, or a new fork.

Cheers

 Glenn

Various WeeWx addons at
https://github.com/glennmckechnie

 

[DrVet52]

Thanks, Glenn! I am glad with AlltimeSeasons, as is now. Nicht to see, that is now installable, and does not need to be installed manually. Although, when manually installed, it was necessary to have a look into the diff files, which gateway e good feeling, what was changed compared to standard Seasons skin.

So, I think, that you know about the mechanisms of summarizing rain data. I think, it is a better approach to do this calculations in weewx, and not in alltimeSeasons. Because, it would be important, not to sum up the same rain from different sensors, but either chose one ( preferably the "better" sensor ), or, if ther is no bias, calculate sort of statistical mean value of the sensor data. In case of piezo vs tipping sensor, I tend to a biased version: when tipping gives no data, take that of Piezo, otherwise that of the tipping bucket.

What is your opinion?

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/rwdy_SwGW8o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAAraAzgLusKPepML6VWPiu1O2a5FPm5X-AsbPA7jALevp0V87A%40mail.gmail.com.

[Glenn McKechnie]

Weewx does all the calculations, AlltimeSeasons takes them from the NOAA tables.

If there is an entry in the files in the NOAA directory (for a 2nd rain gauge there won't be), those daily summaries are correctly generated (no extreme errors in data) then half the work is done. Editing the NOAA templates is interesting, but quite do-able.

It then relies on the alltimes skin.conf and the historygenerator.inc page having a definition for those daily summaries. With that done, they can be displayed.

That is all reasonably straightforward. YMMV.

You're talking serious magic to select the "better" sensor and display it accordingly. Ditto with the mean. It could be done, but you're on your own there.

Far easier to include both rain gauge types in the displayed data. IMHO that is more informative too as you'll see the differences as they happen, know which one has gone offline or started pulling its stats from mercury.

I have 2 rain gauges. My allTimeSeason stats page displays them both.

I do have an unreleased, tweaked version which installs as a separate skin, but is ultimately incorporated into the Seasons skin via the index.html page.

It's in an unfinished state, and you would need to parse what I've done and troubleshoot as you go. I'll obviously help but you'll need to do some hard yards too.

Contact me off-list and I'll send it, as time becomes available (mainly me) we should be able to get it working for a 2nd rain gauge.

My email address is in the install.py file.

Cheers

 Glenn

Various WeeWx addons at
https://github.com/glennmckechnie

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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAO%3D2E3ktpNVSTM0Ee9uXxF7Ygysc%3DBBWbYPJO3fe8hp9J635OQ%40mail.gmail.com.

[DrVet52]

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAAraAzgE%3DuhAZ-iS%3D4TswJcMwefCHqkBSfQ%3D1%3D%3DuoVR1VxF6fA%40mail.gmail.com.

[Vetti52]

Well, finally, it works - mostly.

After I got the GW3001 I managed to get it into producing data. Interestingly it did connect to my Froggit DP1500 as well. I then did dactivate all unused sensors there. So, I think, that  could use this GW1000 clone for both arrays.

Then I introduced the GW3000 into weewx as a service - and did not see any data. I then changed both drivers, with GW1000 as service -  with all data from GW3000 but none from GW1000. I switched back and replaced the GW3000 service by @Ian ecowitt-http driver. The log showed the activation, I could even see catchup, but no data. Long story short result: I always missed to establish a field map for the service stanzas. Silly me! I should have known that in case of running as a service, a field map is mandatory, because this was one of my strategies for „silencing“ certain fields, such as the indoor temperature and wind of GW3000. Both are not representative.

So I finally went back to the most conservative setup and user GW1000 as GW1000driver and GW3000 as GW1000Service. I maybe will replace GW3000service by Ecowitt-httpService, as I know, that it will work. But, currently, the only advantage would be the use of catchup.

So, I ended up with weewx using data of both sources. I additionally found a lot of help using the examples in @Werner github driver and comparison of his custom driver and the new http driver. 

What still is open to be solved: 

I use alltimeSeansos skin, which is a clone of the most recent Seasons skin. I tried to add the new piezo rain plots, besides that of tipping sensor rain, which was „build in“. I did non succeed. I had a look into the www/html/weewx directory and found, that the png files were there. But they did not show in the web site. My quick and dirty solution was to rename the stanza contining both sensors in the skin.config into that, which is shown on the web page. Now, I see both rain results as adjacent columns. Fine.

But, why does Seasons not show the other plots? I had a look into the „logic“ of index.html.tmpl, where there is a group, containing „rain“,  that should be displayed for day, week, month, year, if present, so far I can understand. But although there are files like dayrain.png and dayrain_t.png and dayrain_p.png, only dayrain.png is imported into index.html. For now, my quick and dirty solution satisfies my interest. But maybe someone can enlighten me, how to deal with this structure.

Thanks

Peter

[michael.k...@gmx.at]

If I understand the seasons skin correctly, and alltimeSeason is a clone, you need to add a configuration, as there is only dayrain, monthrain, etc. built in.

So let's assume your tipping sensor is rain and you piezo sensor is p_rain, the data of the tipping sensor should be there, out-of-the-box. 

First option: If you want to add the p_rain to the same image as rain, it should be enough if you put in your weewx.conf (don't modify skin.conf!), below the alltimeSeasons config in [StdReport]:

[StdReport]

    [[alltimeSeasonsReport]]

        [[[ImageGenerator]]]
            [[[[day_images]]]]
                [[[[[dayrain]]]]]
                    [[[[[[p_rain]]]]]]
                        aggregate_type = sum
                        aggregate_interval = 1h
                        label = Piezo Rain (hourly total)
                        color = <optional, default red doesn't seem right for rain... your choice, but it obviously should be different from the color for rain>

Looks like this:

Second option: If you want to add an image for p_rain apart from rain, add p_rain to the options and configure the image:

[StdReport]
    [[alltimeSeasonsReport]]          
        [[[DisplayOptions]]]
        plot_groups = barometer, tempdew, tempfeel, hum, wind, winddir, windvec, rain, p_rain, ET, UV, radiation, lightning, tempin, humin, tempext, humext, tempext2, humext2, templeaf, wetleaf, tempsoil, moistsoil, pm
           
            [[[ImageGenerator]]]
                [[[[day_images]]]]
                    [[[[[dayp_rain]]]]]
                        [[[[[[p_rain]]]]]]
                            aggregate_type = sum
                            aggregate_interval = 1h
                            label = Piezo Rain (hourly total)

Looks like this:

Do alike for week, month, year and don't forget the translations ;)

[Vetti52]

The problem is not missing plots. They are pretty well generated, e.g. dayrain.png, dayrain_p.png, and dayrain_t.png. The problem is the presentation in index.html, where only dayrain.png is present:

I do not understand, how to see all three plots, as Index.html.tmpl chooses the plots like:

#set $periods = $to_list($DisplayOptions.get('periods', ['day', 'week', 'month', 'year']))

#set $plot_groups = $to_list($DisplayOptions.get('plot_groups', ['tempdew', 'wind',  'rain']))

…

#for period in $periods

          <div id="history_${period}" class="plot_container" style="display:none">
  #for plot_group in $plot_groups
    #set $show_plot = 0
    #*
      The plot name is just the concatenation of the period and the plot group.
      For example, 'year' + 'tempdew' yields 'yeartempdew'.
    *#
    #set $plot_name = $period + $plot_group
    #for obs in $getobs($plot_name)
      #if $recent.check_for_data($obs)
        #set $show_plot = 1
      #end if
    #end for
    #if $show_plot
            <img src="${plot_name}.png" alt="${plot_name}"/>
    #end if
  #end for
          </div>
#end for

I tried to add rain_t and rain_p in $plot_groups, but no success.

[michael.k...@gmx.at]

What do the logs say? If the generated picture is not referenced by the index.html, then you have something messed up with the plot groups. Maybe the bracket [] count is wrong, or you are not configuring the report you think you are configuring. The code I posted above was tested with Seasons and the "second option" example altered the index.html rendering the p_rain plot in place. Remember: I only ever changed weewx.conf, never touched skin.conf

[Vetti52]

As I do not have increased the debug level, the logs look as everyday. 

I prefer to configure the skins in the respective skin.conf, as it more conveniant to adopt skins there. I at least do not have to edit weewx.conf, and thus do not need to restart weewx.

The corresponding stanza in skin.conf:

        [[[dayrain_t]]]
            # Make sure the y-axis increment is at least 0.02 for the rain plot
            yscale = None, None, 0.02
            #plot_type = bar
            [[[[rain]]]]

                aggregate_type = sum
                aggregate_interval = 1h

                label = Rain (hourly total)
                
                
        [[[dayrain_p]]]
            # Make sure the y-axis increment is at least 0.02 for the rain plot
            yscale = None, None, 0.02
            y_label = "mm"
            #plot_type = bar
            color = "#b44242"
            [[[[hail]]]]
                data_type = hail * 25.4
                aggregate_type = sum
                #aggregate_type = cumulative
                aggregate_interval = 300        #3600
                label = Rain Piezo #(hourly total)

        [[[dayrain]]]
            # Make sure the y-axis increment is at least 0.02 for the rain plot:
            yscale = None, None, 0.02
            plot_type = bar
            y_label = "mm"
            [[[[rain]]]]
                aggregate_type = sum
                aggregate_interval = 600
                label = Regen Classic (10min)
            [[[[hail]]]]
                data_type = hail * 25.4
                aggregate_type = sum
                aggregate_interval = 600
                label = Regen Piezo (10min)

I just renamed the first stanza from dayrain to dayrain_p and the third to dayrain. And, as expected, the data from the third stanza were displayed in index.html instead of that from the first stanza. So, I am pretty sure, that the syntax is ok.

I did not change anything in index.html.tmpl. It looks pretty like @Tom Keffer has designed it. It is somewhat tricky, as compared to earlier versions. Maybe I should try another skin or an earlier version of Seasons skin, if there is no further explanation of, how it works properly. I have aa backup of the previous version, which does this job like this:

       <div id="history_day" class="plot_container">
       <img src="daybarometer.png" alt="$obs.label.barometer"/>
            <img src="daytempdew.png"   alt="$obs.label.outTemp" />
            <img src="daytempfeel.png"  alt="$obs.label.feel" />
            <img src="dayhum.png"       alt="$obs.label.outHumidity" />
            <img src="daywind.png"      alt="$obs.label.windSpeed" />
            <img src="daywinddir.png"   alt="$obs.label.windDir" />
            <img src="daywindvec.png"   alt="$obs.label.windvec" />
            <img src="dayrain.png"      alt="$obs.label.rain" />
            #if $day.UV.has_data
            <img src="dayuv.png"        alt="$obs.label.UV" />
            #end if
            #if $day.radiation.has_data
            <img src="dayradiation.png" alt="$obs.label.radiation" />
            #end if
            #if $day.inTemp.has_data
            <img src="daytempin.png"    alt="$obs.label.inTemp" />
            #end if
            #if $day.inHumidity.has_data
            <img src="dayhumin.png"    alt="$obs.label.inHumidity" />
            #end if
            #if $day.extraTemp1.has_data or $day.extraTemp2.has_data or $day.extraTemp3.has_data
            <img src="daytemp.png"      alt="$obs.label.extraTemp1" />
            #end if
            #if $day.rxCheckPercent.has_data
            <img src="dayrx.png"        alt="$obs.label.rxCheckPercent"/>
            #end if
          </div>
 

This is a version, I can understand the way, it works and could adopt it easily.

[michael.k...@gmx.at]

That again sounds like the plot_groups is the problem,.

[michael.k...@gmx.at]

While it may be right that fiddling around with skin.conf might be more handy because you don't have to restart weewx, the skin.conf get overwritten with every update of the skin. Merging your customization tends to be hard and you have multiple files to keep track of. Not to mention you can override any skin.conf value in weewx.conf, which might be your exact issue here.

[Vetti52]

You are right. Yes, it might become a challenge. But I tend to keep weewx.conf clear from skins configuration. The only entries, I have there so far, are for activating the skins true or false. Everything else is at the skins.conf. Well, when updates change files, it is a good moment, to monitor the changes. Usually, then there are two files, the original naming and those ending with dpkg-dist. It was always valuable to see the differences there and decide, what was acceptable. This way, I could have decided to stay with the older version of index.html.tmpl, as cited above. I did not, because to me, the newer way of selecting, which plots should be displayed, looked more sophisticated, although I did not expect the difficulties, I am facing now.

Meanwhile, I have seen, that @Werner Krenn has published a SeasonsEcowitt skin at Github. Maybe, I will give it a try. At least it looks less obscure to me than the actual Seasons skin Version 5.1.0. It is closely related to the previous Seasons skin, but expands rain with hail, so to see piezo data also: 

          <div id="history_day" class="plot_container">
            <img src="daybarometer.png" alt="$obs.label.barometer"/>
            <img src="daytempdew.png"   alt="$obs.label.outTemp" />
            <img src="daytempfeel.png"  alt="$obs.label.feel" />
            <img src="dayhum.png"       alt="$obs.label.outHumidity" />
            <img src="daywind.png"      alt="$obs.label.windSpeed" />
            <img src="daywinddir.png"   alt="$obs.label.windDir" />
            <img src="daywindvec.png"   alt="$obs.label.windvec" />
            <img src="dayrain.png"      alt="$obs.label.rain" />

            #if $day.hail.has_data
            <img src="dayrain1.png"        alt="$obs.label.rain" />
            #end if
            <img src="dayrainbar.png"      alt="$obs.label.rain" />
            <img src="dayrain2.png"      alt="$obs.label.rainRate" />

            #if $day.UV.has_data
            <img src="dayuv.png"        alt="$obs.label.UV" />
            #end if
            #if $day.radiation.has_data
            <img src="dayradiation.png" alt="$obs.label.radiation" />
            #end if

            #if $day.sunshine_hours.has_data
            <img src="daysunshine.png"        alt="$obs.label.sunshine_hours"/>
            #end if
However, I have to follow his skin definitions, which needs to be checked before.

[Vetti52]

Finally, there was a solution, mentioned here by Tom Keffer elsewere in this group in 2022 already.

I have to add the topics also into skin.conf like

[DisplayOptions]

plot_groups = rain, hail, rainhail,

Now, I have designed the three plots as dayrain, dayhail, dayrainhail. And, here we go, all are shown.

[michael.k...@gmx.at]

Just as mentioned by me, just a few posts above.

[Vetti52]

Yes, you mentioned it above. But there are two entries for plot_groups. 
Thw one, I had described and tried to expand at first, is that in index.html.tmpl. That did not succeed. But Tom Keffer pointed me to the other one, which is in skin.conf. It is a bit complicated, but after I changed both entries, it works now.

Due to the struggle with rain data, I forgot to introduce the Wittboy temperature sensor. So, again, I will have to edit weewx.conf, change the field map in the W1000Service stanza and restart. Sigh. Usually my weewx runs for several hundred days. 

[michael.k...@gmx.at]

As already written: you don't habe to modify any template, and you are probably better of doing your customization in weewx.conf, not skin.conf. It will save you a lot of time when updating next time.

[Vetti52]

Maybe, you are right. Currently I would expect, just to add into the GW1000Service stanza

[[field_map_extensions]]

extraTemp2 = outTemp

And it should display outTemp from the GW3000 next to the temperature obtained from my extra sensor (which is extraTemp1)  without any additional fiddling in the skin, right?

I will test, when I‘ll be back home tonight.

[Vetti52]

Well, just to be precise, the field map extension should say

extraTemp2 = outtemp

No capital T on the right side. To be careful with typos, is essential, I see.

Now:

Today was the first day, since I have both sensors in function with weewx. And, it was a perfect day to show, what I wanted to have a look at:

Tonight there was a heavy thunderstorm, yielding 7.8mm rain, surprisingly on BOTH sensors equally!!! During the day there several drizzle periods, where the Piezo sensor yielded 10.4mm in sum per day, and the tipping sensor 8.3mm. So, fortunately, because of the thunderstorm, it approves to be a day with rain. Would that thunderstorm, however,  have been before midnight, the drizzle would have gained 0.5mm for today from the tipping sensor and 2.6mm from the piezo sensor. So, only the piezo sensor data would have counted as a day with rain. I am still asking, how to handle it.

[michael.k...@gmx.at]

Use the tipping sensor for statistics like these. On the very low intensity side of rain events, the piezo sensor is not precise, showing much more rain, than there really is. But it shows at least something, when the tipping sensor couldn't collect enough to tip over. It's a resolution thing on both sensors and for the WS90 I think that it only has a resolution of 0,1mm is part of this behavior. But there are many discussions about that and how to deal with it in other forums.

And for your statistics, that's how I handle it: I count days with rain > 1mm and I don't call them "days with rain" but "days with rain > 1mm". There are many days without any rain where the tipping sensor collects enough water from dew that it tips over once or twice. 

[Vetti52]

I have not gone into detail with the sensivitiy discussion of the different rain sensors yet. 

My starting point is the alltimeSeasons skin, where the last table says „Days with Rain“. I did not try to find out, how @Glenn did the calculation, and how to define it. But, as he wrote above, he takes the rain data from the NOAA tables. My observation is, that the threshhold is 1mm per day. 

In my example, it was a perfect day to be defined as day with rain, even without considering the thunderstorm in the early morning hours. This would only be represented using the data from the piezo sensor. However, the NOAA tables are filled with ‚rain‘ data, which come from the tipping sensor only. So, at the current situation, staying with the tipping sensor‘s data for ‚rain‘ only, reamins suboptimal for me.

[Glenn McKechnie]

On Tue, 22 Jul 2025 at 20:20, Vetti52 <drv...@gmail.com> wrote:

I have not gone into detail with the sensivitiy discussion of the different rain sensors yet. 

Now that you have the values for your rain_piezo instrument generating graphs, it should be relatively straightforward to get the AlltimeSeasons section working.

 

My starting point is the alltimeSeasons skin, where the last table says „Days with Rain“. I did not try to find out, how @Glenn did the calculation, and how to define it. But, as he wrote above, he takes the rain data from the NOAA tables. My observation is, that the threshhold is 1mm per day. 

There is no threshold for the raw rainfall data, rain, hail,  whatever...

There is a 1mm (configurable) threshold for the rain_days, hail_days, whatever_days.

The NOAA tables are currently configured to display rain only. You need to modify the NOAA-%Y.txt.tmpl master template (after making a backup)  to include the data for your rain_piezo field (I use hail, as previously mentioned, because it's already part of the group_rain). In my previous post I gave an example / overview where I used hail and snow as the other "rain" gauge field names.

When that is done, deleting the NOAA-2025.txt file and allowing weewx to regenerate it on the next report cycle, should show a fresh file with the new "rain" (database hail) columns within it.

You seem to be okay when editing the weewx configs and templates directly so It should be doable, more so once you get a sense of the language used.

Once you have that file being generated with the correct fields then configure the [HistoryReport] section in skin.conf to show those new fields, as outlined previously..

 

In my example, it was a perfect day to be defined as day with rain, even without considering the thunderstorm in the early morning hours. This would only be represented using the data from the piezo sensor. However, the NOAA tables are filled with ‚rain‘ data, which come from the tipping sensor only. So, at the current situation, staying with the tipping sensor‘s data for ‚rain‘ only, reamins suboptimal for me.

If you have more questions, then contact me off-list. I'll answer when I can.

If you're having trouble editing your files, then send those (YourSeasons/skin.conf that contains [HistoryReport], NOAA-%Y.txt.tmpl ) to me so that I can see directly (rather than infer) where the issue might be.

[Auchtermuchty Weather]

I have the original driver working just fine with a new gateway, with the SD card. It has it's own IP address (set in a DHCP server on my home network) and I also have an older gateway working alongside it, the DHCP gives that a different IPA.

[Vetti52]

well, to suppose, what the „original“ driver might be, I have my own story:

There is the „original“ 0.6.3 GW1000 driver, plus the 0.1.0a28 Ecowitt_http driver at Ian‘s repository, plus the actual 0.1.6 Ecowitt_http driver at Werners branch.

I was interested to insert „is_raining“ in my alltimeSeasons skin. Crazy?  Currently I use the GW1000 driver and GW1000Service to collect the data from my GW1000 and GW3000. There is no „is_raining“. So, I decided, to replace the GW1000Service by Ecowitt_httpService. Nice idea, but the field_map_extension copied from GW1000Service does not match. Unfortunately, I mapped piezoRain.0x0D.val to hail. That resulted in rain_event running into rain data for a while. Suddenly my rain rate rised to several thousand mm/h. Ugly. So, I had to stop weewx, edit the database to zero all hail data for this afternoon (this was easy because of no rain) rebuild the today summaries and start weewx in the previous configuration in a hurry: Because then it started to rain (and it still rains)….

I will wait, until the two versions of ecowitt_http drivers grow together, hoping, not to mix up the field maps again, and stay with the „original“ GW1000 driver. And no „is_rain“ for now.

Besides I could edit the NOAA file properly. First, I forgot to „paint“ the heading lines in the table, but now it looks perfect. The HistoryReport needs to be done yet. Thanks, @Glenn!

[Vetti52]

Oh well, I‘ve got the logic now. To see the data from the [HistoryReport]  stanza [[hail]] in the html table, I had to add the table into histgenerator.inc:

           <h3>Regenfall Piezo (mm)</h3>
          $hail_table

Now, I see the Piezo data! Great!! Although easy, it was a hard way for me to proceed. Thanks to all of you!

Peter

[michael.k...@gmx.at]

@Glenn the historygenerator alltimeseasons integrated from fuzzy-archer has been undergoing massive changes to the better, also adding features like alltime min/max/avg and so on. You might want to take a look. Also, nor more template adaptions necessary, like vetti52 mentioned above.

see: https://github.com/brewster76/fuzzy-archer

[Glenn McKechnie]

Thanks Michael,

Indeed. I've had my eye on the skin for a while and I did a test install of version 4,3 back at the start of Jan 2025. (It must have been my NewYears resolution!)

It's still there at http://cgm.id.au/weewx/Bootstrap/

I like it. It renders well, especially using the phone;  that alone is a huge plus. 

I've always liked the dynamic graphs (which is why I spent the time updating the original mesowx skin - https://github.com/glennmckechnie/weewx-mesowx that I run internally)

The trouble is, I just haven't had the time to migrate my existing install over to it. I used up my coding allotment on another project and my ToDo list got way out of sync. If the (promised - cough) rain comes later this week, I may just be able to sit down, guilt free, and make a decent start on it... but who knows ?

Cheers

 Glenn

Various WeeWx addons at
https://github.com/glennmckechnie

--

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 weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b2a48bbe-ea83-455b-a606-841f6e6bbe0cn%40googlegroups.com.

[Vetti52]

My favorite was alttimeSeasons, because there are no speedometer like gimmicks. Just tables and graphs. The only „round“ design, I would accept, was a compass rose, preferably in a marine design. If one could kick off all of them, besides of the winddir display in the bootstrap skin, it could be of interest for me, So far I am happy with alltimeSeasons.

[michael.k...@gmx.at]

You can "kick" any gauge you want. You simply configure the live_gauge_items to be the empty string and they are gone. Although I have to admit this wasn't a considered use case so far and there currently is an ugly space in the layout. which will be fixed in the next version (it is already fixed in the current master)

[Vetti52]

That is in deed an interesting option, thanks!

As far as I understand, this skin runs aside of the Seasons skin, so I could give it a try without breaking my current alltimeSeason skin. Currently, I am very happy with the additional support, @Glenn offered. I have days with rain and days with Piezo-rain simultaneously. Now I will observe, how the data look like for some months. Eventually I will, after another try to use ecowitt_http service driver, have a look at ecowitt-Seasons skin, @Werner has developped. For now, I will start observing the weather…

[michael.k...@gmx.at]

You can run multiple reports with individual skins, in theory as many, as your machine is able to generate between archive intervals. As long as you don't configure them using the very same HTML_ROOT, they won't interfere.