Gary - the daily table for windSpeed is called archive_day_wind not archive_day_windSpeed
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 to weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
