weewx.4.6.0 : since.py : KeyError: 'trend'

[Glenn McKechnie]

Just a heads up to anyone out there that uses since.py (used to shift
the rain window)
and has upgraded to weewx.4.6.0

I went through the process (I needed the new lang option) and for the
life of me couldn't work out why it kept falling over when generating
various skins.

Switching to a plain skin and adding my cruft back in and lo and
behold it falls over when since.py is slotted back into skin.conf

skin.conf
[CheetahGenerator]
search_list_extensions = user.since.Since

What then happens is that whenever the trend option is called - such
as in Seasons/current.inc : $trend.barometer.formatted - it raises a
KeyError pointing at 'trend' as the culprit.

Attached is the script since.py and a file with the errors generated
by cheetahgenerator, as found in syslog.

It's way beyond my abilities to work out why it happens, but I'd be
curious to know if it's fixable. :-)

I also hope finding it prevents anyone elses hair loss. :-)

--

Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

[Tom Keffer]

The problem here is a little technical, so bear with me.

The way things work normally is that the default configuration for the Cheetah generator includes a TimeBinder in the search list. Because a TimeBinder includes an attribute 'trend', the tag $trend works.

The problem is that the extension since.py also includes a TimeBinder, but one that has not been properly initialized. It needs a keyword argument "trend".

Why did it work before, but not now? Because the order of evaluation of the search list changed. Before, it searched built-in objects first, then user extensions. V4.6 does it the other way around: it searches user extensions first, then the built-ins. This is to allow overriding the behavior of the built-in search list, which the since.py extension inadvertently did. So, when evaluating the tag $trend, the custom, not properly initialized, version of TimeBinder is hit first, and the built-in version is never seen. This re-ordering should have been mentioned in the Upgrade Guide.

There are two ways to fix:

1. Properly initialize the instance of TimeBinder in since.py.

2. Change the logic of since.py. Frankly, I don't know why it returns a TimeBinder at all. It's way more complicated than it needs to be, and has the side effect that it's basically overriding all of the tags, including such mundane tags as $day, $week, etc. It gets away with this because its semantics are identical for these other tags.

If you want a quick fix, do option #1. Here's the delta

--- since.py 2022-02-06 04:59:19.000000000 -0800
***************
*** 160,169 ****
                                                   formatter=self.formatter,
                                                   converter=self.converter)
 
          tspan_binder = NewBinder(db_lookup,
!                                 timespan.stop,
!                                 self.generator.formatter,
!                                 self.generator.converter)
 
          t2 = time.time()
          logdbg2("Since SLE executed in %0.3f seconds" % (t2-t1))
--- 160,176 ----
                                                   formatter=self.formatter,
                                                   converter=self.converter)
 
+         try:
+             trend_dict = self.generator.skin_dict['Units']['Trend']
+         except KeyError:
+             trend_dict = {'time_delta': 10800,
+                           'time_grace': 300}
+
          tspan_binder = NewBinder(db_lookup,
!                                  timespan.stop,
!                                  self.generator.formatter,
!                                  self.generator.converter,
!                                  trend=trend_dict)
 
          t2 = time.time()
          logdbg2("Since SLE executed in %0.3f seconds" % (t2-t1))

But, really, since.py should be fixed so that it doesn't override default behavior.

-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/CAAraAzgTEeXkgVGFpcpnKdkcrnVwMtvyn5kJTGBe_Qin8WTnxA%40mail.gmail.com.

[Glenn McKechnie]

Thanks Tom, for the explanation and the quick fix. It's applied and working.

I'll mull over your explanation, bits of it make sense - I'll need
more time for the rest ;-)

Thanks again.

> https://groups.google.com/d/msgid/weewx-user/CAPq0zEBWJcuAftEafqxYNrEJ0AfFprc-EhfL0oP883GR%2BFxqiA%40mail.gmail.com.

[Greg from Oz]

Hi,

Is there a copy of the since.py that works with the later versions of weewx?

I cannot find a working copy of it anywhere.

I tried adding the bits that Tom suggested but obviously I didn't do it correctly and it didn't work.

Thanks

[Glenn McKechnie]

Looks like I'm still using this once - with WeeWX 4.6.0
See attached

> https://groups.google.com/d/msgid/weewx-user/4845d22e-6e79-4f00-bae2-6c205ac29a98n%40googlegroups.com.

[Greg from Oz]

Thanks Glenn your copy of since.py works with version 4.8.0.

https://weather.ubeaut.work/

[Derek Harding]

I can't find a copy of since.py anywhere on my installations (I have two weather stations in different locations). Both of them only have inigo-since.py.

I'm running raspberry pi's with version 4.7.0 and 4.9.1

Can someone suggest into which directory I should place Glen's version of since.py?

[Glenn McKechnie]

It is a non-standard file . It doesn't come with weewx.

And, it belongs in the Weewx user directory - /usr/share/weewx/user

There are installation notes in the files header - although
abbreviated there as weewx/user/.

> https://groups.google.com/d/msgid/weewx-user/a5143ded-64b4-405a-a7d3-717103e678cbn%40googlegroups.com.

[John Smith]

Thanks for the reminder, I updated the inigo extension to fix it's copy of since.py

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a5143ded-64b4-405a-a7d3-717103e678cbn%40googlegroups.com.

[Greg from Oz]

Since upgrading to weewx 4.10.1 the since time since last rain is showing epoch time.

I tried adding the long_form but that didn't work like I had to do for the uptime etc.

It used to look like this on the we page https://weather.ubeaut.work/

Last rain was:
15/02/23 00:05:00
6 days, 18 hours, 15 minutes ago

But now it looks like this:

Last rain was:
09/02/23 14:55:00
1053000 seconds ago

This is what I have in the index.html.tmpl

                    <td>Last rain was:</td>
                        <td>$time_at('rain>0')<br/>$time_since('rain>0') ago</td>
                      </tr>
                      <tr>

Any ideas how to fix the formatting?

I am not a python programmer so I need help.

Thanks

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

Check https://weewx.com/docs/upgrading.htm#Breaking_changes_for_skins_that_use_delta_times

You need to (untested):

<td>$time_at('rain>0')<br/>$time_since('rain>0').long_form ago</td>

[Greg from Oz]

Thanks. I tried the long_form before but it gives me this:

Last rain was:
09/02/23 14:55:00
30 minutes, 0 seconds ago

It's close but not correct.

Without the long_form:

Last rain was:
09/02/23 14:55:00
1099800 seconds ago

Which should be about 12 days ago and not 30 minutes ago.

[Tom Keffer]

Make sure you are using the latest version of time_since. The current version changes the time context to "month".

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0af65136-6991-4d12-bf99-6b7118d5f98an%40googlegroups.com.

[Greg from Oz]

Thanks Tom. That was the bit I was missing. I installed the latest time_since.py and now it is showing the correct data.

Much appreciated.