OK, so we know the cause. I don't see this as an issue with the driver/station per se (there is no rule specifying the need for equal hardware archive periods), rather an issue between Belchertown and drivers/stations that don't emit archive records with exactly the same length. Maybe the Bechertown gapsize setting can be changed, I have no experience with Belchertown, that is one for Pat.
There is no particular disadvantage to using software record generation, WeeWX takes all of the loop data seen in each archive period and synthesises and archive record using an appropriate aggregate on each observation. Some stations emit additional data/info in hardware archive records and that may be of value to the user and justification to use hardware record generation. Some (many ?) stations/drivers do not support hardware record generation. It really comes down to your needs and the capabilities of your station and the driver. Gary On Sunday, 5 January 2020 21:42:39 UTC+10, István Hegedűs wrote: > > Ok, so I changed to record_generation = software and now I have nice > archive record timestamps: > > Jan 5 11:45:24 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 11:45:00 CET (1578221100) to daily summary in 'weewx.sdb' > Jan 5 11:50:18 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 11:50:00 CET (1578221400) to database 'weewx.sdb' > Jan 5 11:50:18 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 11:50:00 CET (1578221400) to daily summary in 'weewx.sdb' > Jan 5 11:55:21 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 11:55:00 CET (1578221700) to database 'weewx.sdb' > Jan 5 11:55:22 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 11:55:00 CET (1578221700) to daily summary in 'weewx.sdb' > Jan 5 12:00:20 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:00:00 CET (1578222000) to database 'weewx.sdb' > Jan 5 12:00:20 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:00:00 CET (1578222000) to daily summary in 'weewx.sdb' > Jan 5 12:05:15 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:05:00 CET (1578222300) to database 'weewx.sdb' > Jan 5 12:05:15 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:05:00 CET (1578222300) to daily summary in 'weewx.sdb' > Jan 5 12:10:26 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:10:00 CET (1578222600) to database 'weewx.sdb' > Jan 5 12:10:26 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:10:00 CET (1578222600) to daily summary in 'weewx.sdb' > Jan 5 12:15:17 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:15:00 CET (1578222900) to database 'weewx.sdb' > Jan 5 12:15:17 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:15:00 CET (1578222900) to daily summary in 'weewx.sdb' > Jan 5 12:20:23 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:20:00 CET (1578223200) to database 'weewx.sdb' > Jan 5 12:20:23 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:20:00 CET (1578223200) to daily summary in 'weewx.sdb' > Jan 5 12:25:22 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:25:00 CET (1578223500) to database 'weewx.sdb' > Jan 5 12:25:22 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:25:00 CET (1578223500) to daily summary in 'weewx.sdb' > Jan 5 12:30:17 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:30:00 CET (1578223800) to database 'weewx.sdb' > Jan 5 12:30:17 raspberrypi weewx[16347]: manager: Added record 2020-01-05 > 12:30:00 CET (1578223800) to daily summary in 'weewx.sdb' > > This fixed my graphs so maybe the driver or just the cheap weather station > is the problem. > > [image: Screen Shot 2020-01-05 at 12.41.05.png] > > > Are there any disadvantages of software record generation? > > 2020. január 5., vasárnap 0:19:05 UTC+1 időpontban gjr80 a következőt írta: >> >> The issue of archive record timestamps is somewhat complex, what results >> are seen (and how that result was derived) vary depending on a couple of >> factors. First up the type of archive record generation. If the install is >> using software record generation then WeeWX is controlling the archive >> record timestamps and you will see nice archive records sitting on top of >> the minute boundaries eg, 00:05, 00:10 not 00:05:23, 00:10:21. If you are >> using hardware record generation then you are at the mercy of the station >> and driver, so the answer here is it depends. If the station/driver is >> capable of emitting hardware generated archive records then the timestamp >> you see if what the driver/station emitted. If the driver/station does not >> support emitting hardware based archive records then WeeWX falls back to >> software record generation with 'nice' archive record timestamps. OK, maybe >> not so complex but not so simple either. >> >> I note from the wee_debug output that the OPs install is using hardware >> record generation (WeeWX default to hardware record generation if nothing >> is specified for the record_generation setting in [StdArchive]). it >> might be an interesting test to change that to software record generation >> (ie set record_generation = software and restart WeeWX) and see what the >> results are. That should give you 'nice' top of the minute archive record >> timestamps and it might be interesting to see if that helps with the gap >> issue. I am not sure how the Belchertown plots are generated, it might take >> some time before a 'new' history is built up under software record >> generation. Note that I am not suggesting the change to software record >> generation is a fix for the gap problem, rather I see it as a simple way to >> see if the irregular archive record timestamps are the source of the issue >> and if so that may narrow down the solution in terms of tweaking of the >> Belchertown settings/operation. >> >> Gary >> >> On Sunday, 5 January 2020 07:54:26 UTC+10, István Hegedűs wrote: >>> >>> Maybe is it a bug in WS23xx driver? >>> >>> 2020. január 4., szombat 5:26:31 UTC+1 időpontban vince a következőt >>> írta: >>>> >>>> On Friday, January 3, 2020 at 2:41:53 PM UTC-8, gjr80 wrote: >>>>> >>>>> I really don't think this has anything to do with when the records may >>>>> or may not be saved to archive, rather it has to do with the timestamps >>>>> of >>>>> the records (there is a difference). A system under load may save records >>>>> at (slightly) different times but the system should still timestamp >>>>> archive >>>>> records in a consistent manner. >>>>> >>>>>> >>>>>>> >>>> ok, my very wimpy system is 'very' regular in timestamps it archives, >>>> always ending in :00 seconds of the minute. >>>> >>>> Jan 3 18:05:19 debian weewx[13833] INFO weewx.manager: Added record >>>> 2020-01-03 18:05:00 PST (1578103500) to database 'weewx.sdb' >>>> Jan 3 18:10:19 debian weewx[13833] INFO weewx.manager: Added record >>>> 2020-01-03 18:10:00 PST (1578103800) to database 'weewx.sdb' >>>> Jan 3 18:15:19 debian weewx[13833] INFO weewx.manager: Added record >>>> 2020-01-03 18:15:00 PST (1578104100) to database 'weewx.sdb' >>>> Jan 3 18:20:16 debian weewx[13833] INFO weewx.manager: Added record >>>> 2020-01-03 18:20:00 PST (1578104400) to database 'weewx.sdb' >>>> >>>> >>>> Syslog reports this happens usually about 19 seconds after the minute, >>>> but periodically a few seconds quicker than that as indicated in the >>>> snippet above. >>>> >>>> Just in case it matters.... >>>> >>>> >>>> -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/dae43654-b273-4b9b-97c2-d58fe5055cbb%40googlegroups.com.
