That would give you (in most cases) the same result. The issue is that 'weewxDailyHigh' does not reset until weeWX saves the 00:00 archive record to database which (by default) occurs at 00:00:15. After that 15 second period everything is as it should be. The issue can certainly be fixed but for a small issue that presents itself for 15 seconds at midnight I am loathed to spend more time altering an already complex system of loop stats. The new approach I am working on should do away with the (continuous) reliance on the the weeWX daily summaries and I will wait until I have that nailed down before dealing with this issue.
Gary On Friday, 10 March 2017 15:55:52 UTC+10, tempus wrote: > > It seems that merely setting "wgustTM" in 'gauge-data.txt' to the highest > of the daily-high-gust-value from weewx and the current rtgd "wgust" value > would be an easy fix. I am not fluent in Python, so this may not be > technically correct, but in principle like this: > > IndicatedDailyHigh = max(weewxDailyHigh, rtgdTenMinuteHigh) > > -Bob > > On Thursday, March 9, 2017 at 2:49:06 AM UTC-8, gjr80 wrote: >> >> I observed again at midnight just gone, yes the daily high gust pointer >> does take a number of seconds before resetting, this is due to the >> (default) 15 second delay weeWX has from an archive record being generated >> until the data is saved to archive and the daily summaries updated (rtgd >> uses a combination of the daily summaries and the loop data since the last >> archive record to determine daily highs). I am working on a better method >> of keeping various stats (highs/lows/avg etc) in a loop environment for a >> separate project, when I get that working I may roll the new approach into >> rtgd which may improve this. In the meantime the delay can be lessened by >> reducing the archive delay using the archive_delay option in [StdArchive] >> in weewx.conf. Whilst the option can be safely reduced from 15 how far >> it can be safely reduced will, I expect, be station and system dependent. >> >> Gary >> >> On Thursday, 9 March 2017 17:19:06 UTC+10, tempus wrote: >>> >>> Each time the wind reaches a higher value than previously reached since >>> midnight, both the gauge-hand and the 10-minute-gust-indicator move >>> simultaneously to the new high, but the daily-high-wind-gust-pointer does >>> not. It remains at the previous daily-high until expiration of the current >>> weewx 300-second archive interval when it then also moves to the new high. >>> >>> I will be traveling the next 24-hours and not able to respond quickly. >>> >>> -Bob >>> >>> On Tuesday, March 7, 2017 at 4:04:37 PM UTC-8, gjr80 wrote: >>>> >>>> I would say that this will quite often be the case. >>>> >>>> The daily high wind gust pointer should always indicate the highest >>>> wind speed seen after midnight at the start of the day and up to and >>>> including midnight at the end of the day. In other words it will reflect >>>> the highest wind speed indicated by the gauge hand throughout the day. At >>>> midnight the daily high wind gust pointer is reset to 0 and it will again >>>> start tracking the highest wind speed seen throughout the new day. On the >>>> other hand, the 10 minute gust value is the highest wind speed seen over >>>> the last 10 minutes, it is not constrained by day boundaries. So consider >>>> the first packet that arrives after midnight, say at 2 seconds after >>>> midnight. Assuming its windSpeed value is >0, the daily high wind gust >>>> pointer will move the this new value. Now if the 10 minute wind gust value >>>> is currently higher than this latest windSpeed (in other words the 10 >>>> minute wind gust occurred some time in the last 10 minutes of the previous >>>> day), the daily high wind gust pointer will not be affected by the 10 >>>> minute wind gust and nor should it (because it occurred yesterday). If the >>>> 2 seconds after midnight windSpeed value is higher than the 10 minute wind >>>> gust value, then the 10 minute wind gust value will be updated to this new >>>> windSpeed value and the daily high wind gust pointer will indicate the >>>> same >>>> value (as will the wind speed gauge hand). >>>> >>>> The real check for correct operation of the daily high wind gust >>>> pointer just after midnight is to verify that it tracks the highest speed >>>> indicated by the gauge hand after midnight. If the gauge hand indicates >>>> say >>>> 5mph and the daily high wind gust pointer indicates 4 mph then we have a >>>> problem. >>>> >>>> Gary >>>> >>>> On Wednesday, 8 March 2017 02:40:39 UTC+10, tempus wrote: >>>>> >>>>> The only issue I have noticed since upgrading to v0.2.9 is that for a >>>>> short time period following midnight the daily high wind gust pointer was >>>>> below the 10-minute high gust indication. However, I went to bed after >>>>> that and haven't watched since. Based on that single observation it >>>>> appears that periodic daily high wind speed values from the weather >>>>> station >>>>> aren't being updated to include latest wind speeds. >>>>> >>>>> -Bob >>>>> >>>>> On Tuesday, March 7, 2017 at 4:20:34 AM UTC-8, gjr80 wrote: >>>>>> >>>>>> Well I observed your wind speed gauge over a couple of continuous 10+ >>>>>> minute periods this afternoon, there were 5 occasions where the gauge >>>>>> indicated a speed higher than the present 10 minute gust and in each >>>>>> case >>>>>> the 10 minute gust immediately jumped up to the indicated speed. I guess >>>>>> this supports your observations under v0.2.9. I noticed a number of >>>>>> changes >>>>>> (daily max, gauges rescaling, windrun going to 0) at 6PM my time and >>>>>> thought what? Then I realised it was midnight and change of day (I am >>>>>> +10 >>>>>> UTC). So the chnage of day appears to works fine. >>>>>> >>>>>> Periods of lower wind speeds are more likely to include some 0 wind >>>>>> speed packets than periods of higher wind speed. It's possible the old >>>>>> method of calculating the 10 minute gust could have been upset by 0, I >>>>>> don't believe that was the case but who knows. >>>>>> >>>>>> Staring at a gauge for 10+ minutes is incredibly boring so I will >>>>>> leave that for now, let me know if you notice anything else that does >>>>>> not >>>>>> appear right. >>>>>> >>>>>> Gary >>>>>> >>>>>> On Tuesday, 7 March 2017 17:24:58 UTC+10, tempus wrote: >>>>>>> >>>>>>> Sorry about the 403 Forbidden error. That is a test domain and >>>>>>> public access is often blocked. I opened access a few hours ago when I >>>>>>> saw >>>>>>> your message, but didn't have time right then to post a response or >>>>>>> upgrade. I have since upgraded to v0.2.9. You should now be able to see >>>>>>> it >>>>>>> working here: >>>>>>> >>>>>>> http://www.lablibrary.com/ss/newport.php >>>>>>> >>>>>>> This area recently had a several-day period of unusually light >>>>>>> winds. The 'wgust" value anomalies occurred at those unusually low wind >>>>>>> speeds. I don't know why functionality would be different at different >>>>>>> speeds, but whatever the reason, v0.2.8 'wgust' anomalies occurred far >>>>>>> less >>>>>>> frequently today at higher speeds and I haven't seen them at all since >>>>>>> upgrading to v0.2.9. >>>>>>> >>>>>>> Weather forecasts are not very reliable in this area, but there may >>>>>>> be an opportunity to check higher-speed functionality tomorrow, because >>>>>>> the >>>>>>> National Weather Service has issued this High Wind Watch: >>>>>>> >>>>>>> "*South wind 30-40 mph with gusts to 65 mph, strongest near beaches >>>>>>> and headlands but also possibly affecting coastal communities. Winds >>>>>>> spreading northward late Tuesday morning, with peak winds from about >>>>>>> noon >>>>>>> to 4:00pm or 5:00pm. These winds could cause tree damage that could >>>>>>> lead to >>>>>>> power outages, and will cause hazardous driving conditions.*" >>>>>>> >>>>>>> My anemometer is 33-feet (*10 meters*) above ground, 204 feet (*62 >>>>>>> meters*) above mean-sea-level, and line-of-sight to the sea, so it >>>>>>> should be spinning rather quickly if the forecast is correct. The time >>>>>>> here >>>>>>> is 8 hours behind UTC. >>>>>>> >>>>>>> -Bob >>>>>>> >>>>>>> On Monday, March 6, 2017 at 2:26:22 PM UTC-8, gjr80 wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, 5 March 2017 06:11:53 UTC+10, tempus wrote: >>>>>>>>> >>>>>>>>> I have been traveling for a few days with only a SmartPhone to >>>>>>>>> watch data. However, based merely on wind-speed-gauge indications >>>>>>>>> there >>>>>>>>> seem to be "wgust" value anomalies. The pink gust-area sometimes >>>>>>>>> disappears >>>>>>>>> even though there have been recent gusts into that speed-range. >>>>>>>>> Furthermore, gusts above the indicated upper-gust-limit often do not >>>>>>>>> cause >>>>>>>>> the indicated gust-range to expand. >>>>>>>>> >>>>>>>> >>>>>>>> I have been closely observing my wind speed gauge over the last few >>>>>>>> days during various windy periods. I did notice periods where the red >>>>>>>> gust >>>>>>>> 'wedge' would disappear for a short period. I observed several >>>>>>>> occasions >>>>>>>> where the indicated wind speed went higher than the existing 10 minute >>>>>>>> gust >>>>>>>> value, on all occasions the ten minute gust value was immediately >>>>>>>> increased >>>>>>>> and the red gust wedge similarly increased in size immediately to >>>>>>>> match the >>>>>>>> indicated wind speed. >>>>>>>> >>>>>>>> >>>>>>>>> It is my understanding that the value of "wgust" is supposed to be >>>>>>>>> the speed of the highest gust over the last ten-minutes. If so, the >>>>>>>>> ten-minute time-window should include recent "wlatest" values. >>>>>>>>> >>>>>>>> >>>>>>>> That is my understanding as well and that is exactly what rtgd >>>>>>>> does. The issue in this case was the method in which the ten minute >>>>>>>> wind >>>>>>>> gust value was derived from the ten minute wind speed list. This has >>>>>>>> been >>>>>>>> fixed in v0.2.9. >>>>>>>> >>>>>>>> I have no solution for the gusts you observed that did not update >>>>>>>> the ten minute gust value. I have not been able to replicate this >>>>>>>> issue and >>>>>>>> I have reviewed the code and am confident it is correctly capturing >>>>>>>> windSpeed data and calculating 10 minute gust values. I suggest you >>>>>>>> upgrade >>>>>>>> to v0.2.9 and see if the issue remains, if so we need to determine the >>>>>>>> conditions under which the issue occurs. If this is not possible >>>>>>>> visually >>>>>>>> then I have some wind speed debug code that will dump the windSpeed >>>>>>>> history >>>>>>>> list and other key values to log and we will need to wade through the >>>>>>>> figures to determine the issue. >>>>>>>> >>>>>>>> I did go to your previously posted link to try to observe the >>>>>>>> issues you describe myself but the link now gives me a 403 Forbidden >>>>>>>> error. >>>>>>>> >>>>>>>> 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]. For more options, visit https://groups.google.com/d/optout.
