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.
[email protected] schrieb am Samstag, 19. Juli 2025 um 21:34:08 UTC+2:
> 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.
>
> [email protected] schrieb am Samstag, 19. Juli 2025 um 21:28:25 UTC+2:
>
>> That again sounds like the plot_groups is the problem,.
>>
>> Vetti52 schrieb am Samstag, 19. Juli 2025 um 21:10:15 UTC+2:
>>
>>> 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.
>>> [email protected] schrieb am Samstag, 19. Juli 2025 um 19:33:50 UTC+2:
>>>
>>>> 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 schrieb am Samstag, 19. Juli 2025 um 15:44:06 UTC+2:
>>>>
>>>>> 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:
>>>>> [image: IMG_0782.png]
>>>>> 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.
>>>>>
>>>>> [email protected] schrieb am Samstag, 19. Juli 2025 um 12:28:36
>>>>> UTC+2:
>>>>>
>>>>>> 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:
>>>>>> [image: one_images.png]
>>>>>> 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:
>>>>>>
>>>>>> [image: two_images.png]
>>>>>>
>>>>>> Do alike for week, month, year and don't forget the translations ;)
>>>>>> Vetti52 schrieb am Samstag, 19. Juli 2025 um 10:17:05 UTC+2:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> DrVet52 schrieb am Samstag, 12. Juli 2025 um 21:14:11 UTC+2:
>>>>>>>
>>>>>>>> Glenn McKechnie <[email protected]> schrieb am Sa., 12. Juli
>>>>>>>> 2025, 05:07:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, 12 Jul 2025 at 01:48, DrVet52 <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> Glenn McKechnie <[email protected]> schrieb am Fr., 11. Juli
>>>>>>>>>> 2025, 01:42:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 10 Jul 2025 at 23:03, Vetti52 <[email protected]> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>> https://groups.google.com/d/msgid/weewx-user/CAAraAzgLusKPepML6VWPiu1O2a5FPm5X-AsbPA7jALevp0V87A%40mail.gmail.com
>>>>>>>>>>>
>>>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/CAAraAzgLusKPepML6VWPiu1O2a5FPm5X-AsbPA7jALevp0V87A%40mail.gmail.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/CAO%3D2E3ktpNVSTM0Ee9uXxF7Ygysc%3DBBWbYPJO3fe8hp9J635OQ%40mail.gmail.com
>>>>>>>>>>
>>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/CAO%3D2E3ktpNVSTM0Ee9uXxF7Ygysc%3DBBWbYPJO3fe8hp9J635OQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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 [email protected].
>>>>>>>>>
>>>>>>>> To view this discussion visit
>>>>>>>>> https://groups.google.com/d/msgid/weewx-user/CAAraAzgE%3DuhAZ-iS%3D4TswJcMwefCHqkBSfQ%3D1%3D%3DuoVR1VxF6fA%40mail.gmail.com
>>>>>>>>>
>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/CAAraAzgE%3DuhAZ-iS%3D4TswJcMwefCHqkBSfQ%3D1%3D%3DuoVR1VxF6fA%40mail.gmail.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/ad930073-3f20-430f-a76e-f60dd4635a87n%40googlegroups.com.
