minmax and maxmin with span killing page?

[mrzimgjugl asdf]

I have added minmax and maxmin to the SmartPhone temp.html.tmpl. I use the weekly outside temeprature for examples. The standard but useless (becuase it does not relate to the above graph) form works perfectly fine:

maxmin2: $week.outTemp.minmax at $week.outTemp.minmaxtime<br/>
minmax2: $week.outTemp.maxmin at $week.outTemp.maxmintime<br/>

But, when I try my span delta modified version, not only they do not display, temp.html stops being generated at all until I remove these lines completely! I added two lines in front of the regular max and min:

minmax: $span(day_delta=7).outTemp.minmax<br/>
maxmin: $span(day_delta=7).outTemp.maxmin<br/>

[Andrew Milner]

what error does the log give when the html fails to generate??

the log usually contains the key to all weewx failures, and should always be the first place to look.  In the event of a suspected weewx failure or problem the log should also be attached to the post describing the issue so taht others may get to see the log clues.

[Pila]

Sorry, I was making notes on everything I wanted to ask, and in all that logging, I forgot a log I should include :)

wee_reports[14046]: cheetahgenerator: Generate failed with exception '<class 'weewx.ViolatedPrecondition'>'
wee_reports[14046]: cheetahgenerator: **** Ignoring template /home/weewx/skins/Smartphone/temp.html.tmpl
wee_reports[14046]: cheetahgenerator: **** Reason: Invalid aggregation type 'minmax'
wee_reports[14046]: ****  Traceback (most recent call last):
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/cheetahgenerator.py", line 332, in generate
wee_reports[14046]: ****      fd.write(str(compiled_template))
wee_reports[14046]: ****    File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1045, in __str__
wee_reports[14046]: ****      rc = getattr(self, mainMethName)()
wee_reports[14046]: ****    File "_home_weewx_skins_Smartphone_temp_html_tmpl.py", line 151, in respond
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/tags.py", line 329, in __getattr__
wee_reports[14046]: ****      return self._do_query(aggregate_type)
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/tags.py", line 343, in _do_query
wee_reports[14046]: ****      val=val, **self.option_dict)
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/wxmanager.py", line 60, in getAggregate
wee_reports[14046]: ****      return weewx.manager.DaySummaryManager.getAggregate(self, timespan, obs_type, aggregateType, **option_dict)
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/manager.py", line 1268, in getAggregate
wee_reports[14046]: ****      **option_dict)
wee_reports[14046]: ****    File "/home/weewx/bin/weewx/manager.py", line 450, in getAggregate
wee_reports[14046]: ****      raise weewx.ViolatedPrecondition("Invalid aggregation type '%s'" % aggregate_type)
wee_reports[14046]: ****  ViolatedPrecondition: Invalid aggregation type 'minmax'

[Andrew Milner]

there is no aggregate minmax or maxmin - just saying min will give the lowest value over the span and just saying max will give the highest value over the period

so

minmax: $span(day_delta=7).outTemp.minmax<br/>
maxmin: $span(day_delta=7).outTemp.maxmin<br/>

should be

minmax: $span(day_delta=7).outTemp.min<br/>
maxmin: $span(day_delta=7).outTemp.max<br/>

[Pila]

They are not nearly the same thing. In the summer, we do not care about the coldest night. Warmest nights are the problem. Warmest nights are of interest. In the winter lowest daily maximum becomes crucial.

Pity. This is very unfortunate missing crucial feature. These two really should exist in any good meteo program.

Then again, why they exist in standard form which is useless to describe graphs?

[vince]

On Monday, October 7, 2019 at 11:11:32 AM UTC-7, Pila wrote:

Pity. This is very unfortunate missing crucial feature. These two really should exist in any good meteo program.

Then again, why they exist in standard form which is useless to describe graphs?

[...rant on...]

FWIW, your constant negativity and criticism is getting extremely tiring and is likely stopping people from spending their minimal time and energy to try to give you (free) support out of the goodness of your hearts.

I'd invite you to please write your own weather app that does what you want it to do.  Then you can criticize the author by looking in the mirror.

Thank you.

[...rant off...]

[Thomas Keffer]

There is indeed a "minmax" aggregate, but it comes with limitations. The start and end of the aggregation interval must be at midnight. I suspect the problem is that you are attempting to do it from a random time of the day. In that case, minmax (and maxmin) would then be not well-defined mathematically.

-tk

--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/26FB5345-2EA6-41AB-A6A7-09CD1FECBCA3%40gmail.com.

[Pila]

OK. This is perfectly logical and acceptable limitation. It makes sense for both weekly and monthly or longer period where it will be used.

I am off investigating how to set such defined spans.

Thanks for the insight.

[Pila]

Yes, using span delta means I am using now as the starting point. That was I wanted to acheve.

minmax: $span(day_delta=7).outTemp.minmax
maxmin: $span(day_delta=7).outTemp.maxmin

I tried running a report with a midnight time, and it creates desired minmax spans, as you correctly stated. Any other time, it skips generating the page with no interactive display of the fault, only in the log.

But now, my problem is how to create minmax lines on the midnight and reuse them entire day? report_timing option in weewx.conf is for enitre reports. That does not fit the bill.

I need a weekly and monthtly minmax / maxmin lines under the week and month OutTemp graphs. Closest to the usable idea I have:

1) in skin.conf, create two templates (for the two maxmin+minmax lines, one for week one for month)

2) include them to temp.html.tmpl

But, I am unable to find a solution to create these two files at midnight only and reuse them the rest of the day? Can I, in a skin.conf, do somethng like:

[ $(date +"%H:%M") == "00:00" ] && create_templates || skip

I could try initially generating them manually at midnight, and then use stale_age in skin.conf to keep them for 24 hours. Not elegant and touchy, but it may work. I am open to any better suggestions.

[Andrew Milner]

I think you can run wee_reports manually or via cron with a different .conf (and therefore different skin(s)) specified.  this would permit just doing the report(s) you wanted, at time you desire.

[Pila]

>I think you can run wee_reports manually or via cron with a different
>.conf
>(and therefore different skin(s)) specified. this would permit just
>doing
>the report(s) you wanted, at time you desire.
>

I did not think of that! Far from elegant, but it should work. Hopefully I will be able to create a corresponding report! It actually does not even need to be run at midnight. It can be run at any time with midnight as argument.

I would prefer if program itself adjusted values for this problem too midnight, but I think this may be useful workaround.

Thanks for a great idea!

[Pila]

Yup. An extremely ugly fix to a problem for which I claim should not have existed. Works. I just hope it is not doing to a database something.

[Thomas Keffer]

On Thu, Oct 10, 2019 at 3:23 PM Pila <mrzim...@gmail.com> wrote:

Yup. An extremely ugly fix to a problem for which I claim should not have existed. Works. I just hope it is not doing to a database something.

You are misunderstanding how open-source software works. It is a collaborative effort. A lot of people have put a lot of time into this software that you are now using. 

You don't get to whine unless you contribute. So, how about a Pull Request to fix this supposed problem?

[gjr80]

Whilst it is true that the report_timing option only works down to the report level (ie it cannot discriminate between templates) this is easily overcome with a little lateral thinking. Duplicate the skin (with a unique name of course) containing the template concerned and then disable/remove all other reports from the duplicated skin. Add a new entry under [StdReport] in weewx.conf for the duplicate skin with the desired report_timing option.

Gary

On Friday, 11 October 2019 08:23:43 UTC+10, Pila wrote:

Yup. An extremely ugly fix to a problem for which I claim should not have existed. Works. I just hope it is not doing to a database something.

[Pila]

I did similarly. This add on report is being run by my script 3 minutes after midnight generating a report for midnight. It is on a 4 RPI Zero, better to not run out too at midnight. Clumsy but it works.

Now I have a very good numerical description of minimums and maximums in last 7 and last 30 days graphs in the Smartphone skin.

As I am using Weewx only briefly, I am mostly unfamiliar with it. I am not certain what can I safely remove from this add on report config files. So, slowly... The first thing is to understand it and test if it can do what I need it to do.

Of course, the proper solution for me would be to fix it in a source code to achieve seamless consistent use of maxmin and minmax. Should I continue using it, that will have to wait until I learn Phyton. For now, I am unable to reduce graph margins.

[vince]

On Friday, October 11, 2019 at 2:14:36 AM UTC-7, Pila wrote:

Of course, the proper solution for me would be to fix it in a source code to achieve seamless consistent use of maxmin and minmax. Should I continue using it, that will have to wait until I learn Phyton. For now, I am unable to reduce graph margins.

I would suggest you consider just using what you have, as-is, and possibly take your energy to learn how the software actually works, and what it can and cannot currently do, rather than constantly complaining.  Get familiar.  Then you'll understand whether you are running into a bug, a limitation, or a feature you don't yet understand.