To clarify, the archive interval coming from the driver or weewx.conf is quite acceptable.
If a driver has the ability to emit archive records then it MAY also control the archive period (by the same token it may not). Consequently, if you are using driver emitted archive records (ie hardware record generation) WeeWX will look to the driver for the archive interval during startup. If the driver provides the archive interval then WeeWX will use that instead of the weewx.conf archive_interval setting. If the driver does not provide the archive interval WeeWX will fallback to the weewx.conf value. Irrespective of the archive interval, what happens at the end of an archive interval depends on whether hardware or software record generation is being used. If hardware record generation is being used then WeeWX will ask the driver for for all archive records since the last. If one or more archive records are provided WeeWX accepts and uses them, if the driver cannot provide archive records (for example it has no genArchiveRecords() method) then WeeWX falls back to software record generation. If software record generation is selected then at the end of the archive interval WeeWX (not the driver) generates an archive records based on accumulated loop data seen by WeeWX over the archive interval. After this processing by WeeWX for both hardware and software record generation is essentially the same. One other point. I notice some mention of the daily summaries (archive_day_xxxxxx). I would be very careful dealing with the daily summaries. I am not sure a driver should be delving into the daily summaries. The driver should really have no need to read the daily summaries and it certainly should not be writing to them. The driver should just emit archive records (be it current or historical) and loop packets and let the rest of the WeeWX machinery take care of dealing with (day based) aggregates in the daily summaries. Gary On Tuesday, 9 February 2021 at 16:29:55 UTC+10 michael.k...@gmx.at wrote: > Hi Jan-Jaap. > > In brief my observations with your driver: > > - udp-packets are being picked up (and published with mqtt in my case, > because I've installed the extension) > - missing database values are NOT being backfilled > - current archive records from loop data are NOT being generated > > For the archive interval: > > I don't know exactly how this all works, hopefully the "staff" here can > clarify, but: there must be either something wrong with setting the archive > interval in your driver or how this value is being used. Leaving the hard > coded 60 seconds in your code this leads weewx to generate reports every 60 > seconds, which, as far as I understand how things are intended to work, > overrides the archive_interval in weewx.conf, which I do not consider as > desired behavior. The sentence in the documentation also starts with an > "if", so maybe this is only necessary under certain circumstances. > > For backfilling missing data would use an approach like: If there is data > available in weatherflow REST service, an if it is available on a time base > which is more frequent than archive_interval, I would try to backfill like > this: for every top of an weewx archive_interval that is missing, I'd get > all data available for this interval, calculate averages (take care with > vector data windSpeed/windDir!), check if minimum/maximum values of each > REST entry, if it is lower/higher than the min/max value in > archive_day_[archiveColumn], handle it. > > Jan-Jaap van der Geer schrieb am Montag, 8. Februar 2021 um 23:21:28 UTC+1: > >> On Sunday, February 7, 2021 at 12:31:33 AM UTC+1 michael.k...@gmx.at >> wrote: >> >>> I've just installed your driver. Whats the status now? Right now it >>> neither seems to backfill data nor store current data from UDP into the >>> database. >>> >> >> Yes, I've recently noticed that UDP data is not getting filled into the >> database. I'm not sure why, as it's virtually using the same methods as the >> backfill (which BTW is working fine here). It took some time before I >> noticed the UDP not working as the REST data fills it up anyway. But I'm >> not sure why it's not working. I've been looking at it today, but it seems >> that somehow the fact that I have the genArchiveRecords() method causes the >> UDP/LOOP packages to be ignored by weewx. As far as I can see I'm still >> returning them to weewx and they seem fine to me, but it seems weewx is >> ignoring them. >> >> >>> Other Question: >>> @property >>> def archive_interval(self): >>> return 60 >>> What purpose does this have and why is it hardcoded to 60? Shouldn't it >>> read and return >>> [StdArchive] >>> >>> # If the station hardware supports data logging then the archive >>> interval >>> # will be downloaded from the station. Otherwise, specify it (in >>> seconds). >>> archive_interval = 300 >>> >> >> >>> from weewx.conf? >>> >> >> In the documentation at >> http://weewx.com/docs/customizing.htm#genArchiveRecords() it says: >> >> archive_interval >> >> If you implement function genArchiveRecords(), then you should also >> implement archive_interval as either an attribute, or as a property >> function <https://docs.python.org/3/library/functions.html#property>. It >> should return the archive interval in seconds. >> >> This too me means that as the WeatherFlow REST service has a record for >> every minute, the archive_interval should be set to 60 seconds. >> >> Cheers, >> Jan-Jaap >> > -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/792bb9c3-9852-4aaf-92ed-159671671e8dn%40googlegroups.com.
