For what it’s worth, rainRate has been a problem as I have it fixed in my copy 
of gauges.  I don’t know when I changed it as it is in my initial check in 
(Jan. 6) of my private (and modified) github copy.  In particular, I don’t know 
if I needed to change it for WeeWX 4.

> On Apr 6, 2020, at 6:27 PM, gjr80 <[email protected]> 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].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/cf119004-27b4-4415-9c93-cc823bee6c75%40googlegroups.com.

-- 
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/58F37365-CB35-4A39-9BF9-2BCDEE516B0B%40johnkline.com.

Reply via email to