Matthew, Sorry forgot to answer your question on wx_ftp_upload and wx_cp_index. They are a couple of services I added in the early days of using weewx wx_ftp_load - to upload some camera images from my local directories. I could easily remove and put the images in the html path, but just haven't got around to it. wx_cp_index - I was using as a cheap copy of the index.html file to a network drive so I can have a monitoring system check to see if the weewx system has failed and perform some restart operations and send out some admin email messages. One of my remote sites uses a couple of cheap TEMPerHum sensors that I have had trouble with causing USB hangs on the RPi, so monitoring for a stale index file was the approach I took to detect this type of system failure. As you know USB hangs are problematic for Acurite stations as sometimes the Acurite stations stop talking completely when it happens. Only solution I have found that works consistently is to power down the weewx RPi and wait for 30mins for the Acurite to reset itself due to no USB traffic then reboot the RPi. So I set up a separate RPi as a system monitor and it handles all that via GPIO pins on the weewx RPi
As for stale data I have just started seeing that from both stations that past few weeks, generally not an issue. My thinking is that the batteries in the 5 in 1's are reaching the end of the life cycle and will need to be changed. Thanks, On Tuesday, February 5, 2019 at 9:22:37 AM UTC-5, mwall wrote: > > the OutOfSpan failure killed the report thread, and that brought down > weewx. imho this is a bug - weewx should continue to collect data, even if > the report thread cannot do its job. however, tom and gary know the > accumulator code better than i do, so they could say whether OutOfSpan > should be a fatal failure, versus a just "restart the report engine" > failure. but first we need to know the root cause of OutOfSpan. > > a few observations: > > - here is the analysis of report generation times from the syslog.2 file. > nothing unusual here. > > report cycle for record 2019-02-01 06:28:00 > StdReport - 14 files in 18.82s + 36 images in 18.89s > cmon - 1 file in 0.7s + 32 images in 82.48s > exfoliation - 9 files in 100.62s + 62 images in 38.07s > forecast - 12 files in 110.11s > ftp - 353 files in 110.13s > > report cycle for record 2019-02-01 03:35:00 > skipped because report generator still running previous record > > report cycle for record 2019-02-01 06:42:00 > StdReport - 14 files in 5.53s + 12 images in 3.07s > cmon - 1 file in 0.15s + 32 images in 81.32s > exfoliation - 8 files in 9.64s + 48 images in 27.97s > forecast - 12 files in 82.3s > ftp - 127 files in 35.62s > > report cycle for record 2019-02-01 06:49:00 > StdReport - 14 files in 2.89s + 12 images in 2.89s > cmon - 1 file in 0.15s + 32 images in 81.12s > exfoliation - 8 files in 9.63s + 28 images in 9.37s > forecast 12 files in 83.02s > ftp - 107 files in 33.38s > > so the first run is longer, as expected. you should see longer report > generation times whenever the monthly/yearly plots are updated as well. > > you could eliminate LOTS of overhead by removing the forecast skin. the > exfoliation skin has forecast reporting built in, so you don't need the > forecast skin too. the forecast skin is designed to illustrate how > forecasting works and to provide lots of examples of how to use it. you > probably don't want to run it in 'production'. > > - what are wx_ftp_upload and wx_cp_index? > > - you are getting stale data from the acurite sensor cluster (see circa > 07:13:47 in syslog.2). this is not unusual, but if it happens a lot then > you should look at way of making your connection stronger (eliminate > interference, re-orient the console, put console closer to sensors, dance > naked around a fire at the next full moon, etc). > > - you might want to plot the 'ignoring stale data' messages over time. > that is a good way to see if there is a pattern to the interference timing. > > - don't generate forecasts any more often than you must. once every 4 > hours is typically sufficient. i think exfoliation is set up to do this - > it only generates forecast.html every 4 hours. and the forecast download > services are set up to download the data based on when the sources update. > once again, get rid of forecast skin, because i think it regenerates every > report cycle, even though that frequency is pointless. > > - be sure that you have a sane max_age in the [Forecast] section in > weewx.conf. something like 604800 is reasonable. you should only use > max_age=none if you intend to retain forecasts indefinitely, e.g., for > doing forecast comparisons over extended periods. > > -- 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.
