Very simply, when your driver is emitting loop packets your time resolution is the time between loop packet timestamps, once your driver is emitting archive records your time resolution decreases and is the time between archive record timestamps. Similar but slightly different with actual values, loop packets give you the finest granularity of the observation values, once you move to archive records you get the average of the loop values (well actually you get whatever function is used to obtain an archive record value from a group of loop packet values, this is usually the average but it could be the sum or the last or the first value, it depends).
Gary On Tuesday, 9 February 2021 at 22:42:18 UTC+10 gjr80 wrote: > OK, let's work through it. The hardware stored data at one minute > intervals, so between 11:05:00am to 11:10:00am the hardware will have five > stored records, the driver then creates a single archive record covering > 11:05:00am to 11:10:00am, the observation that has the max value at > 11:07:00am will appear as the average of the five values stored between > 11:05:00am and 11:10:00am (so chances are that will not be the same as the > value (the maximum) seen at 11:07:00am) and that is what will be stored as > the new daily max in the daily summary (if in fact it is a new maximum). > The timestamp of this backfilled record will be 11:10:00am and that is what > will be recorded as the max timestamp in the daily summary. So in this case > not only will you likely miss the maximum value that occurred at 11:07:00am > but you will miss the actual timestamp of the maximum value as well, it > will be moved to an archive interval boundary. > > Gary > > On Tuesday, 9 February 2021 at 22:28:52 UTC+10 michael.k...@gmx.at wrote: > >> For the loop packets this is what I already thought to know. >> >> What I wanted to know if my weew archive interval is 5 mins, and the >> hardware stored at 1min: >> Lets assume the archive_interval 11:05:00am to 11:10:00am is to be >> backfilled. The driver gets the stored archive values from the hardware, >> where the maxvalue was at 11:07:00am. >> Is the maxvalue in the archive_day_xxx table for that day timestamped >> with 11:07:00am or with 11:10:00am? >> >> gjr80 schrieb am Dienstag, 9. Februar 2021 um 13:11:41 UTC+1: >> >>> If your one loop packet was the only loop packet received by WeeWX in >>> that archive interval then the archive record that WeeWX would synthesise >>> from that solitary loop packet would be the same as that loop packet. If as >>> you said that loop packet was stored by hardware and if the driver's >>> genArchiveRecord() method obtains that same data when it generates an >>> archive record, then yes they will be the same. Highs and lows in the daily >>> summaries would be the same but it would not surprise me if some timestamps >>> were different. Loop packets are generally timestamped when the data is >>> read, whereas archive records are typically timestamped at the end of the >>> period they cover. So for an archive interval that covers say 11:05:00am to >>> 11:06:00am, the loop packet may have been created at 11:05:25am and >>> timestamped accordingly. If WeeWX is set to obtain highs and lows from loop >>> packets (ie loop_hilo <http://weewx.com/docs/usersguide.htm#StdArchive> >>> is True) then if a new max/min is found in that loop packet the relevant >>> timestamp recorded in the daily summary will be the loop packet timestamp. >>> If you now consider the archive record that is read during a backfill, it >>> will be timestamped 11:06:00am, again any new highs or lows will be >>> recorded (so the actual aggregate value will be the same) but in this case >>> the timestamp recorded for the high or low will be the archive record >>> timestamp 11:06:00am. If you happen to have more than one loop packet in >>> the archive period then you may loose some fidelity of the actual >>> observation high/low value as well. >>> >>> This is the same effect you see if you rebuild your daily summaries with >>> wee_database >>> --rebuild-daily, if you have loop_hilo = True then your daily summary >>> tables will likely have loop packet timestamps for many highs and lows but >>> after you rebuild the daily summaries you loose that fine detail and your >>> high/low timestamps will align with archive record timestamps. If you have >>> multiple loop packets in an archive interval then your high/low values may >>> be one of the values in those loop packets, after rebuilding though you end >>> up with archive values being used to generate the highs and lows which are >>> typically averages of loop values. For example, if you have four loop >>> packets in an archive interval and each has an outTemp value of 8.0, >>> 9.0, 12.0 and 7.0 degrees C your daily summary may record 12.0 as the max. >>> The corresponding archive record outTemp value would >>> (8.0+9.0+12.0+7.0)/4=9.0 so your max might be 9.0. >>> >>> Gary >>> >>> On Tuesday, 9 February 2021 at 21:03:10 UTC+10 michael.k...@gmx.at >>> wrote: >>> >>>> > If you mean does WeeWX determine if any incoming archive record has >>>> (for example) a new daily max for some field and then save that data, then >>>> yes that is what StdArchive does. >>>> >>>> So if a hardware sends a loop packet with all the readings in a >>>> one-minute-interval, and stores these exact values in its own storage in a >>>> separate entry, one entry per minute, the weewx database values are >>>> exactly >>>> the same, regardless if they were received as loop data as if they were >>>> backfilled? Including timestamps and Values for min/max in >>>> archive_day_xxxx, which may differ from the min/max value found in all >>>> weewx archive records of that particular day, with timestamps between >>>> possible timestamps of archve values? >>>> >>>> -- 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/3f2ab90e-fd41-443f-83f2-7e3faa3056a5n%40googlegroups.com.
