Gary - the daily table for windSpeed is called archive_day_wind not 

On Friday, 13 January 2017 15:52:55 UTC+2, gjr80 wrote:

> Andrew,
> The issue here is windSpeed and windGust being identical. 
> $day.windSpeed.max and $day.windGust.max come from archive_day_windSpeed 
> and archive_day_windGust respectively, archive_day_wind shoudl have nothing 
> to do with either. At a guess I would say that somehow windGust is 
> polluting archive_day_windSpeed. How that is happening is the question. The 
> handling of wind by weewx is complex. I have just spent the last hour 
> trying to get my head around it and I am still not there. Something I will 
> ask Tom about.
> Gary
> On Friday, 13 January 2017 23:38:12 UTC+10, Andrew Milner wrote:
>> Gary - as far as I can see from the results from the queries I asked for 
>> the issue seems to be resolving why day_archive_wind has the same value AND 
>> time as day_archive_windGust when in the archive the max for windSpeed and 
>> windGust are different values.
>> On Friday, 13 January 2017 15:30:36 UTC+2, gjr80 wrote:
>>> The SteelSeries Gauges template fields are correct (well the 10 min 
>>> average actually uses a 1 hour average but that is either here nor there). 
>>> The fact the maximum windSpeed recorded in the archive is lower than the 
>>> what you get with $day.windSpeed.max is not surprising. The windSpeed 
>>> values in your archive are the average of the loop windSpeed values seen 
>>> over that archive period. So if over the first 5 minute archive period of 
>>> the day your station saw (loop) windSpeed values of 6,8,8,10,12 the value 
>>> 8.8 (44/5) would be recorded in the archive as windSpeed for that archive 
>>> period. The daily summaries keep track of the Highs and Lows. So the 
>>> windSpeed daily summary would record 12 as the max. As subsequent archive 
>>> periods roll over and loop packets come in additional records are added to 
>>> the archive (ie windSpeed will contain the average of the loop windSpeed 
>>> values over the archive period) and the Highs and Lows in the daily 
>>> summaries will be updated *if a new* High or Low was seen during that 
>>> archive period. So it is quite possible that the maximum windSpeed value 
>>> seen in all of the day's archive records is lower than that returned by 
>>> $day.windSpeed.max ($day.windSpeed.max pulls the max windSpeed value from 
>>> the daily summaries). In fact for windSpeed i woudl almost guarantee that 
>>> the max value in the archive will be less than $day.windSpeed.max. The 
>>> exception is when the daily summaries are rebuilt all of the accumulated 
>>> detail of highs and lows and their times are lost (ie the detail of the 
>>> loop data is lost) and the daily summaries are rebuilt frome the (largely) 
>>> 'averaged' archive data.
>>> The real tell will be a query of both the windSpeed and windGust daily 
>>> summaries. If you do:
>>> SELECT * FROM archive_day_windSpeed ORDER BY dateTime DESC LIMIT 1;
>>> and then 
>>> SELECT * FROM archive_day_windGust ORDER BY dateTime DESC LIMIT 1;
>>> I'll bet the values in both of the max columns are the same (the 
>>> maxtimes will likely be different). That is not right and that is why 
>>> $day.windSpeed.max and $day.windGust.max are returning the same values. 
>>> (coincidentally, I get the exact same results on my system with a different 
>>> station so it is not an issue with the station). How weewx handles wind obs 
>>> is complex, and whilst the issue has been identified I think a bit more 
>>> analysis will be required to work any possible fix.
>>> 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 
For more options, visit

Reply via email to