Tom, OK, so sort of the right answer but for the wrong reason!
I don't know why it took so long for me to tweak but I now know why the
following TypeError was occurring:
Apr 5 13:00:19 raspberrypi weewx[604] ERROR weewx.cheetahgenerator: ****
TypeError: '>' not supported between instances of 'NoneType' and 'int'
It's the change in the use of None in comparisons under python3 (Phil is
running under python 3). Unless you are in the hour from 11pm to midnight
iterating over the hours of the day will always return as least one hour
where $hour.rain.sum.raw is None and the comparison below will return a
TypeError under python3 if there is a None involved in the comparison.
Nothing to do with missing rain data for the day. The fix is a change to
the if statement as I posted earlier. Will submit that change and the
rainrate/rainRate change as PRs to the SteelSeries Weather Gauges repo.
Gary
#set $hourlyrainTH = 0
#set $ThourlyrainTH = ''
#for $hour in $day.hours
#if $hour.rain.sum.raw > $hourlyrainTH
#set $hourlyrainTH = $hour.rain.sum.raw
#set $ThourlyrainTH = $hour.dateTime.format("%H:%M")
#end if
#end for
On Tuesday, 7 April 2020 21:39:50 UTC+10, Thomas Keffer wrote:
>
> Gary,
>
> Makes sense.
>
> To gather data for a plot, version 3.9 called Manager.getSqlVectors(),
> which hit the database. Only types that appear in the database schema can
> be plotted. Because many databases are case-insensitive, rainRate and
> rainrate are treated the same, so it works.
>
> By contrast, version 4.0 calls weewx.xtypes.get_series(). This function
> allows new types to be introduced, which are not necessarily in the
> database. If no extension has been registered that knows how to deal with a
> type, then xtypes consults the schema. If the type is not in there, an
> exception weewx.UnknownType is raised. The schema consultation is done in
> Python in a case-sensitive manner, so rainrate and rainRate are different.
>
> This explains the difference in behavior.
>
> -tk
>
>
>
> On Mon, Apr 6, 2020 at 6:27 PM gjr80 <[email protected] <javascript:>>
> wrote:
>
>> Well looking into the rainrate/rainRate issue has been most interesting.
>> First up rainrate has been used in skin.conf for the rain rate plot as
>> follows since the SteelSeries Weather Gauges first directly supported WeeWX:
>>
>> [[images]]
>> x_label_format = %H:%M
>> show_daynight = true
>> [[[daybarometer]]]
>> [[[[barometer]]]]
>> [[[dayrain]]]
>> yscale = None, None, 0.02
>> plot_type = bar
>> [[[[rain]]]]
>> aggregate_type = sum
>> aggregate_interval = 3600
>> label = Rain (hourly total)
>> [[[dayrainrate]]]
>> [[[[rainrate]]]]
>>
>> But why has this never caused a problem or been noticed before? I think
>> the way in which plot data is obtained and the introduction of xtypes holds
>> the answer. Before WeeWX v4 plot data was obtained via a call to
>> manager.getSqlVectors() which itself is encapsulated in a try...finally
>> statement. The result being that any error (for example a non-existant obs
>> type) was effectively swallowed and no data returned by
>> manager.getSqlVectors(). The image generator would then plot this
>> non-data which resulted in a plot devoid of data. Given that rain rate
>> plots are seldom looked at, quite often show no data, and also as this plot
>> was only used as a mouseover on the SteelSeries rain rate gauge, it is not
>> surprising it's lack of data was never noticed. Now consider the new xtypes
>> regime, plot data now comes from xtypes and if my xtypes understanding is
>> correct, the xtypes are searched until one is found that can return the
>> required data. In this case no xtype can return data for field rainrate
>> which results in a weewx.UnknownType error which is highlighted in the
>> log and painfully obvious to the user.
>>
>> Of course the fix is simple, replace rainrate with the correct field
>> rainRate. This then got me wondering about the $hour.rain.sum.raw issue.
>> I am still convinced this is tied to an underlying lack of rain data for at
>> least one full hour in the day. My testing yesterday showed the
>> gauge-data.txt template would handle such a lack of rain data without
>> problem, which is counter to Phil's experience. But I was running under
>> WeeWX 3.9.2 which does not use xtypes, I am now thinking there is a subtle
>> difference in the data returned by xtypes in some corner cases. So far my
>> understanding of xtypes has been fairly limited to just what I have needed
>> to bget by in working on WeeWX 4.0 (which has not been much). Clearly I
>> have a bit more reading to do (@tkeffer - warning there will be some xtypes
>> questions inbound) and I will spend some time today seeing if I can
>> replicate the issue.
>>
>> Gary
>>
>> --
>> 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] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/cf119004-27b4-4415-9c93-cc823bee6c75%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/weewx-user/cf119004-27b4-4415-9c93-cc823bee6c75%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 on the web visit
https://groups.google.com/d/msgid/weewx-user/f105913e-003d-45a6-b57a-b34f89fb6819%40googlegroups.com.
