Gary, many thanks for the detailed explanation. This helped me to track the issue and resolve it immediately. My answer is delayed because I was waiting for the first rain event. I confirm the rain is logged correctly and polling/archive interval is perfectly on time.
There were three issues with my setup/configuration: * external script was running every 1 minute with 10 second fixed delay (cronjob) --> too rare; I've increased this to every 30 seconds * the polling interval in weewx.conf was set to 60 seconds --> not good as it could still get old data. I set the polling to 8 seconds or so * I did log the "dateTime" value from Ecowitt cloud and made it available to weewx through fileparser --> not good. As soon as I removed it, the weewx's started archiving data constantly every 1 minute with no gap Overall, I'm very happy with how the weewx works and all support you provide. petek, 18. april 2025 ob 11:53:35 UTC+2 je oseba gjr80 napisala: > Some comments below. > > Gary > > On Wednesday, 16 April 2025 at 18:13:29 UTC+10 mihec wrote: > > Gary, > I have edited the weewx.conf with proposed configuration. I am still not > getting the values correct. I do have: rainDay, rainWeek, rainMonth and > rainYear values in the weewx's database. > > > Just one point of clarification. The cumulative field used in a [[Delta]] > stanza need only appear in loop packets/archive records, there is no need > for it to be saved to the WeeWX database. It won't hurt if it is, but there > is no requirement. > > Maybe I don't understand the logic behind the [[Delta]]. > > I have few questions: > 1. Does the logging interval matter? I am polling the data every minute > and store it to the fileparser's compatible format. However, looking at the > log file, I see that the records in the weewx.sdb do not update every > minute. There are occasions where a minute is skipped (say 1 time per 10 > minutes). I don't know the reason. > > > Not sure what you mean by 'the logging interval'. When using the fileparse > driver there are a few intervals/periods of interest. First you have the > interval at which the fileparse source data file is updated. This is > typically completely external to WeeWX. Then you have the fileparse driver > polling interval, this is the interval used by the fileparse driver to read > the source data file and generate a loop packet. In effect the fileparse > driver will emit a loop packet every polling_interval seconds). Ideally > the driver polling interval is shorter than the source data file update > interval. How much shorter is somewhat subjective, if it was me I would > have my polling interval 1/3 (or less) of the source data file update > interval. If your source data file update interval and polling interval are > the same you risk missing data (ie the source data file is updated twice > before fileparse polls it). The final interval of concern in the WeeWX > archive interval, this is the interval at which (in the case of the > fileparse driver) WeeWX generates an archive record and saves the record to > database. The WeeWX archive interval should be greater than the driver > polling interval, if they are the same or the archive interval is less than > the polling interval you will have archive periods where WeeWX does not > receive any loop packets from the driver and consequently no archive record > is generated and no archive record would be saved to database. > > As an example, if you were updating your source data file every minute you > might set the fileparse driver polling interval to 10 seconds and the WeeWX > archive interval to five minutes. > > > 2. To avoid midnight time discrepancies, I am using the dateTime value > provided by the data source (Ecowitt cloud) and provide the "dateTime=<>" > string to the fileparser. Is this valid to do? I have also tried without > this. Explanation: when polling for the data few seconds over 00:00, I get > data from 23:59. If I let weewx use the actual OS time, the "rainDay" would > be wrongly logged to the next day. > > > I am not sure exactly what you mean. Are you obtaining data from > Ecowitt.net to produce your source data file? If so you need to be very > careful of latency. For example, when your station posts data to > Ecowitt.net there is a delay while the data is processed by Ecowitt.net and > then made available via the Ecowitt.net API. There will then likely be a > delay until you poll the Ecowitt.net API, obtain the data and generate the > source data file. You then may have a delay before the fileparse driver > polls the source data file and generates a loop packet. The fileparse > driver timestamps each loop packet with the time the loop packet is > generated, not the time the original data was uploaded to Ecowitt.net, so > there could well be cases where a loop packet may contain data from a > previous loop period rather than the current loop period. This could cause > discrepancies between data on Ecowitt.net and WeeWX. This would especially > be the case for obs such as rain. > > > > Why is using e.g. rainMonth or rainYear better than rainDay? > > > The per-period or 'delta' values are obtained by taking the difference > between a current cumulative value and the last cumulative value. > Cumulative fields such as rain usually reset to zero after some time (eg > each hour, day, week, month, year) or when the counter rolls overs (perhaps > for an all-time or total rain value). When the cumulative value jumps to > zero the delta value for that period cannot be determined, so if any rain > fell in that period it would be lost. When using a hour based cumulative > value that reset to zero happens once per hour or 24 time per day, whereas > for a year based cumulative value the reset to zero happens once per year > and there is much less chance of any rainfall occurring in a reset period. > If no rain ever falls in the reset period there will be no > problem/discrepancy, but eventually it will. Best to minimise the risk by > maximising the reset period of the cumulative value used. Hence the > preference for year rain over day rain or hour rain. > > > > Thank you. > > > nedelja, 6. april 2025 ob 13:53:47 UTC+2 je oseba gjr80 napisala: > > Provided you are running WeeWX v4.2.0 or later you need to make the > following changes to the [StdWXCalculate] stanza in weewx.conf: > > > 1. under [[Calculations]] add an entry as follows: > rain = prefer_hardware > 2. add a new stanza [[Delta]] after the [StdWXCalculate] [[Calculations]] > stanza: > [[Delta]] > [[[rain]]] > input = dailyRain > > where dailyRain is the name of your cumulative rain field to be used to > calculate WeeWX field rain. If you have more than one cumulative rain > field use the one that resets least frequently, eg use day rain in > preference to hour rain, year rain in preference to month rain etc. > > your [StdWXCalculate] stanza should look something like: > > [StdWXCalculate] > [[Calculations]] > .... > rain = prefer_hardware > [[Delta]] > [[[rain]]] > input = dailyRain > > After making the changes save weewx.conf and restart WeeWX. WeeWX should > now correctly populate the WeeWX field rain. > > Gary > On Sunday, 6 April 2025 at 00:07:45 UTC+10 mihec wrote: > > While looking for solution to my issue, I came around this post. > I am using fileparser to log data from my remote weather station (Ecowitt) > and everything works fine except the rain. I have implemented my own > pre-processing where I log the delta-rain but that doesn't work for some > reason (might my timing issue in the scripts). I am logging the dailyRain > and other values, too. Just in case. I don't know how to e.g. use the > dailyRain in the NOAA report. > > As I read this: https://github.com/weewx/weewx/issues/491 > I assume this could resolve it. Are there any more details on the use? > > > -- 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 visit https://groups.google.com/d/msgid/weewx-user/74b0c242-262a-4013-8122-c71326939943n%40googlegroups.com.
