OK, that helps paint the picture. If I understand correctly your concern is the timestamp of these records:
Apr 1 12:11:25 maginos weewx[4560]: manager: Added record 2020-04-01 12:05: 10 CEST (1585735510) to database 'weewx.sdb' Apr 1 12:11:25 maginos weewx[4560]: manager: Added record 2020-04-01 12:05: 10 CEST (1585735510) to daily summary in 'weewx.sdb' You expect the timestamps should be xx:00:00 (or xx:30:00) but not xx:05:10. In your case WeeWX is configured to synthesise archive records every 30 minutes from the loop data received during that 30 minute archive interval. This will result in archive records on xx:00:00 and xx:30:00 boundaries and once your station has been running for a while this is what will occur. What you are seeing is a hardware catchup. When WeeWX starts up it asks the driver if your station has any stored archive records that are newer than the last record in the WeeWX archive. This is WeeWX catching up if WeeWX has been disconnected from the station for some time. During a hardware catchup WeeWX does not synthesise the archive records, rather WeeWX takes the archive records (and their timestamps) from the driver/station as is and saves them to archive. In your case the driver is obtaining an archive record from the station that has an unusual timestamp and WeeWX is accepting that record and saving it to archive as is. I am no fine offset expert but I know the fine offset driver ignores the station clock. I suspect the station timestamps the archive records that it stores in memory but these timestamps are in no way synchronised with the WeeWX clock, hence you see records that are stored in the station memory being retrieved with unusual timestamps. It may be the station is saving a record in memory every 30 minutes, just not on the hour and half hour as WeeWX does. Since restful services such as WOW, CWOP etc are largely archive record based these services are passed the record with the odd timestamp and that is why these servies are using the odd timestamp. So what can you do. There are a couple of things that spring to mind that might mitigate the situation. Firstly, you could verify that your station hardware is using the same archive interval that you have WeeWX set to use (30 minutes). You can use the wee_device utilitily <http://weewx.com/docs/hardware.htm#fousb_notes> using with the --info and --set-interval actions to check and set the interval respectively. I suspect that even if the WeeWX and station hardware intervals are the same there will still be odd timestamped records during hardware catchup. You could drop the archive interval used by WeeWX and the station hardware to something like five minutes. Again this will not eliminate the problem but it may make it less noticeable. Finally, you could use the undocumented no_catchup config option in weewx.conf to prevent WeeWX doing a hardware catchup on startup: [StdArchive] .... no_catchup = True .... This will eliminate the odd timestamped records you are seeing but it will also prevent WeeWX from automaticlly catching up if it is disconnected from your station for a period of time. Or finally you could leave it as is, the odd timestamped records will not trouble WeeWX. I am not so certain about the external services your are uploading to, some have requirements of uploaders bnu these are usually in regards to frequency of uploads so they may not be a problem. Then again an experienced fine offset user may come along too... Gary On Wednesday, 1 April 2020 20:57:20 UTC+10, Maginos wrote: > > So here's the log. > > Before 12 o'clock I stopped weewx, started it, until it has finished and > stopped again. At 12:09, I started it again. > I hope this is helpful. > > > > Am Mittwoch, 1. April 2020 10:46:35 UTC+2 schrieb gjr80: >> >> Didn’t expect any errors in the log, the log unambiguously records the >> timestamp of all records saved to archive. If you have timestamps appearing >> in the database that should not be there then the log is the first place to >> check. The startup portion of the log shows key config info for your setup. >> Helps add to the picture and help us avoid wasting our time asking 20 >> questions. Sometimes it’s not about errors, it’s about getting a clear >> picture. >> >> 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 weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/fe905bbc-5445-4545-90d2-46d235300fc5%40googlegroups.com.