Gary - the point I was really trying to make was that - especially where an RPi is involved - it is likely that one cannot necessarily do all that one wishes - but compromising does not necessarily mean a significant loss of information. What people often forget is that midnight in particular results in more load for reports as the yearly plots and pages are regenerated together with the monthly, weekly, current etc also and this can result in more issues when small archive intervals are being used.
I think we are really on the same page Gary, even if I may appear a luddite and a pedant at times. Andrew On Tuesday, 5 February 2019 07:49:34 UTC+2, gjr80 wrote: > > I beg to disagree. I learnt a long time ago to not impose my views on a > user's requirements; maybe the user needs to generate a report every > minute, maybe they need to record the number of widgets every minute, maybe > they just like lots of dots in their plots. At the end of the day it does > not matter, WeeWX supports a 1 minute archive interval. Now if a user > chooses to use a 1 minute archive interval that may impose some limits on > the user, but that is a different matter. I know the old chestnut about > wind speeds and directions gets dragged out every now and then. I think we > need to keep in mind that the period over which an observation is made does > not necessarily bear any relationship to how often you may wish to record > the value. > > Gary > > On Tuesday, 5 February 2019 14:22:12 UTC+10, Andrew Milner wrote: >> >> I continue to find it almost impossible to conceive a situation where an >> archive interval of under 5 minutes serves any useful purpose. As long as >> a gust value is recorded for the 5 minute period the average speed >> value/direction over the period is more than sufficient - even for an >> airfield - and the other readings are unlikely to alter over 5 minutes >> anyway. So with a Pi a 5 minute interval is more than sufficient. >> >> I found the following whilst googling wind gust which I thought useful >> since the implication is that wind measurements over short periods of time >> (if the rest of the world is right) are error prone anyway: >> >> "Wind gusts (which last only a few seconds) make it hard to determine the >> overall wind speed of storms whose winds don't always blow at constant >> speeds. This is especially the case for tropical cyclones and hurricanes. >> To estimate the overall wind speed, the wind and wind gusts are measured >> over some period of time (typically 1 minute) and are then averaged >> together. The result is the highest average wind observed within the >> weather event, also called the *maximum sustained wind speed*. >> >> Here in the U.S., maximum sustained winds are always measured by >> anemometers at a standard height of 33 feet (10 m) above ground for a >> duration of 1 minute. The rest of the world averages their winds over a >> period of 10 minutes. This difference is significant because measurements >> averaged over just one minute are about 14% higher than those averaged over >> the course of ten minutes." >> >> >> On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote: >>> >>> Yes the NoneType error is certainly due to the realtime clientraw >>> extension not handling a None value correctly, by the looks of it a wind >>> related field so quite possibly brought on by your battery/connectivity >>> issue. That extension was written over 2 years ago and never formally >>> released (and judging by the lack of user questions I assume not used by >>> too many). So that means it is probably not too robust. It maybe easiest to >>> just disable it until I can get to have a look at it in the next 2-3 weeks >>> (as per other thread). >>> >>> Some good advice above about getting a machine to work reliably, the >>> only thing I would add is chose your archive interval carefully as that >>> also has an impact on stability when you start to add in a number of >>> extensions. A 5 minute archive period means there is 5 minutes between >>> report cycles so arguably WeeWX has around 5 minutes to get all of its >>> report processing completed, cut that down to 1 minute and WeeWX now only >>> has 1/5 the time. You don't want your reports taking longer to run than >>> your archive interval, that would be bad on many fronts. Some folks think >>> that having the shortest possible archive interval is essential, that may >>> be the case in some circumstances but there are other secondary effects >>> that need to be kept in mind. Basically, to run a 1 minute archive WeeWX >>> needs to be fairly lean extension wise. >>> >>> Gary >>> >>> On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote: >>>> >>>> On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith >>>> wrote: >>>>> >>>>> Noted the use of skins and mqtt on a pi, i kind of assumed it was up >>>>> to the job, i do like the weewx system so may well move up to a more >>>>> useful >>>>> machine - coming from Windows into this world means i know little beyond >>>>> Dells and Win 10 which is what i have been trying to avoid due to >>>>> frequent >>>>> updates and crashes of other systems. >>>>> >>>>> Any advice on what sort of system weewx needs to run would be good >>>>> (again i should Google this first!). >>>>> >>>> >>>> here are some suggestions: >>>> >>>> https://github.com/weewx/weewx/wiki/hardware >>>> >>>> data collection is almost never a problem. uploading data is not cpu, >>>> i/o, or network intensive. most reports will run just fine on a pi or >>>> other low-power machine - you should have no problems with 1 or 2 reports. >>>> >>>> however, you might have issues if you try to run 3 or 4 query-intensive >>>> reports with a short archive interval. >>>> >>>> in some configurations, the crt (cumulus realtime) and wdcr (clientraw) >>>> extensions can be problematic on low-end hardware, since they query the >>>> database each report cycle (archive interval) to get the data they need. >>>> if you run them on archive intervals you should be ok, but if you run them >>>> on loop packets you can easily run into the 'database locked' problems. >>>> >>>> the NoneType error is almost certainly due to a bug in rtcr.py - it is >>>> getting a value of None but does not handle it properly. >>>> >>>> m >>>> >>> -- 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.
