On Wednesday, 31 May 2017 05:58:52 UTC+10, Tom Keffer wrote: > > As I started working on this patch I realized there's a problem with it: > if some rain happens to fall in the few seconds just after midnight, we > will lose its contribution to dayRain. This probably would not happen very > often, but for the days when it does, the sum of 'rain' for the day will > not be equal to the value of 'dayRain'. > > I wish the downloaded LOOP packets had timestamps... > > It seems to me that tinkering with dayRain is only addressing part (albeit the most noticeable part) of the problem. The real issue is that we have a 'record' from the previous day whose data is now considered part of today. I appreciate that rain will most likely show up an issue (since we have rain aggregates in the loop packet) but the issue has a similar (but likely far less noticeable) affect on all other obs in the 'record' - values from yesterday are being included in today's data.
If we are going to have the driver make a decision that a dayRain (and monthRain and yearRain and maybe dayET, monthET and yearET?) value is to be ignored (ie we are essentially making the decision that the packet was from the previous day) can we not just leave the packet data as is (we have no reason to doubt its accuracy) and just set the packet timestamp to 00:00? The loop data concerned would be accumulated in the old accumulator (since a new archive record is not written until archive_delay (default 15) seconds after the end of the archive period). I must confess this idea is based on a cursory review of the code rather than practical testing and I cannot vouch for it not causing other issues. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
