Some semi-random (or sem-organised?) thoughts. *$alltime.wind.max or $alltime.windGust.max*. On a properly functioning/configured system with no data integrity issues then both will provide the same value. As Tom said the advantage of wind is that you can tie in the 2nd dimension, direction ie $alltime.wind.gustdir will give you the direction of the al time highest wind speed seen by your station. This is not possible from .windGust, .windGustDir, .windSpeed or .windDir; $alltime.windGustDir.max will just give you the 'largest' direction bearing ever seen, chances are it will be 359 or thereabouts (station dependent). So the upshot is if you just want the highest speed and don't care what direction it came from then just use $alltime.windGust.max, if you need to tie in the corresponding direction you need .wind.
*issue #339*. From my cursory glance I don't believe that fixing #339 will have any significant impact on the .wind issue. My best guess at the moment is that the length of time taken to complete the reports is pushing the report cycle out beyond the archive interval and by the time the report thread gets around to do an $alltime.wind another archive record has been saved and the timespan the still running report thread is using is no longer 1st to last archive record hence it defaults to the archive for the query and subsequently fails. So far I have not seen anyone who has been afflicted with this condition post a log extract that makes me think any different. Perhaps it would worthwhile establishing exactly what the failure mode/cause is; a simple debug=1 log extract over a few archive periods from someone who has the error will firm up whether my suspicion has foundation or not. A couple of well placed syslog.syslog calls in the $alltime SLE will confirm it. *Solutions*. For mine the long term solution is to reduce the execution time of the reports that are pushing out the report cycle execution time (assuming my suspicions are correct). This really comes down to me reworking the highchart json SLEs to be more efficient. I have a plan on how to do that but it will not be an overnight fix, more like a week or 2. A number of short term fixes come to mind; rationalising reports/SLEs across more than one skin, avoiding a 1 minute archive period and I am sure there will be a couple of others given some more thought. Gary On Monday, 3 September 2018 09:49:14 UTC+10, Pat wrote: > > David, Tom, Gary, > > I'm trying to follow the wind logic here, but perhaps I'm getting > confused. If switching $alltime.wind.max to $alltime.windGust.max fixes > the issue - should I just change it in the skin? Or would resolving #339 > <https://github.com/weewx/weewx/issues/339> fix the $alltime.wind.max > "problem"? > > I'm aware that no matter what I need to update the skin, but looking for > guidance on the "right way" on this one. Should I keep the current > $alltime.wind.max and update the SLE to use TimeBinder (with some > learning on how to resolve 339)? Or just change it to > $alltime.windGust.max? (or "yes" to both?) > -- 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]. For more options, visit https://groups.google.com/d/optout.
