Thank you both of you for the replies, they helped me a lot! :) Also thank you very much for the great explanation and insight on the image generation, that will prevent bad surprises for sure!
As far as I can understand the python package 'python-pil' generates the plots, right? Again, thank you very much. Henry. On Friday, February 22, 2019 at 5:28:15 AM UTC+1, gjr80 wrote: > > Hi, > > Perhaps a small insight into the operation of the image generator might > help. Yes it is true that at the end of each archive period (during the > report generation cycle) the plots are copied to public_html (or wherever > you have set them to be copied). However, it is not quite as simple as > that, what is really going on is only those plots that have been generated > are copied. As you have found out the aggregate_interval has a role in > how often/when images are generated, in fact all other things being equal > plots are generated every aggregate_interval seconds. If no aggregate > interval is specified then they are generated every report cycle. > > So you might say well why not have a very small or zero aggregate interval > for each plot, you can certainly do that but there is a penalty to pay. > When WeeWX generates a plot it queries the archive and obtains all of the > data points for the observations required over the period of the plot. In > the case of a day plot the period covered is 27 hours so assuming a 5 > minute archive interval WeeWX would use 27x12=324 data points per > observation. These points are then plotted. For a week plot we now have > 7x24x12=2016 points, a month we have (approx) 31x24*12=8928 and for a year > we have 105120 data points. Now WeeWX will quite happily plot 324 data > points, as it will 2016 but when we get to 8928 and 105120 it takes WeeWX a > very long time to generate the plots (remember there are numerous plots > each with (usually) multiple obs each with 8928/105120 data points. So the > way WeeWX mitigates this load is to reduce the number of points being > plotted by using an aggregation, say the average over 1 hour (for month > plots) and over 1 day for year plots. This brings us down to around 744 > points for a month and 365 points for a year, much more manageable and > comparable to day and week plots. The load on the processor is further > reduced by only re-generating the plots after their aggregate_interval has > passed. > > So what, well as I said you can certainly reduce the aggregate interval to > 60 and all plots will then be generated every report cycle. But if you have > a look at your logs you will probably find the time taken to produce your > reports has increased significantly. This may or may not be a problem > depending on your archive interval and your processor. But if your reports > are taking close to your archive period to complete you may find your > system will become unstable or some report cycles may be skipped - quite > the contrary to what you are trying to achieve. Also remember that on a 1 > year plot with say 105120 points I don't think you will really be able to > see the difference 1 extra point makes so really you are gaining very > little by running a long period report every report cycle with a very small > or zero aggregate interval. > > I hope that helps explain what your are seeing, why you are seeing it and > the possible consequences of your changes. > > Gary > > On Friday, 22 February 2019 04:59:25 UTC+10, Henry Denston wrote: >> >> Ok, after hours of trial and error I guess the lable 'aggregate_interval' >> is responsible for my issue. >> I set it to 60 (so Images/Plots will get copied when older than a minute >> everytime a record runs). >> >
