> another question: what do you mean by " top of the interval" ? In my understanding the top of the interval is the end.
I didn't address this behavior as an issue, I just asked (myself) the question, if this behavior is desired and how does this behavior fit into WeeWX? You're right that a 5-min average with an the interval of 07:22 to 07:27, imported for the WeeWX interval from 07:25 to 07:30 wouldn't be correct, but if your hardware only ever sent data in a 5-minute-interval, WeeWX would have stamped the same data from 07:27 with 07:30 when actively running and receiving these values as a loop package (setting any highs/lows to 07:27), but when incoming from backfill, an archive entry stamped with 07:27 is created. I consider this inconsistent behavior, without proposing either way "correct" or not. > For me there is no desired behaviour here - what was archived is stored. Accumulation only where accumulation is possible. Im a bit confused: you state "there is no desired behavior" and in the same line you describe it: "what was archived is stored. Accumulation only where accumulation is possible." Accumulation would be possible, if there is more than one value in the device storage for an WeeWX archive_interval. I've set the GW3000's interval to 1 min, to see what will happen: when backfilling, WeeWX now produces an archive entry every minute, that's in my understanding in contradiction to accumulate, when possible. Anyway, I'm with you that this not a real issue and I also don't care if the backfilled data is aligned to the usual interval, but from a technical point of view worth discussing about. Rainer Lang schrieb am Sonntag, 13. Juli 2025 um 11:34:03 UTC+2: > > I don't think that this "deviated" timestamp is a real issue. > > Assuming your weewx srchiving interval is 5 minutes (300 seconds) and also > assuming the GW3000 archive interval is also 5 minutes, its archiving time > stamp will be whenever it starts archiving - any time between minute 00 and > minute 05 and multiples to fill the hour. If the timestamp is not 00, 05, > 15, ...,55, what is weewx supposed to do ? If the timestamp is 03 instead > of 05, there is nothing to fill the loop with. So it will store with > whatever the GW3000 timestamp was. > > And where is the problem ? For the backfill period you will get the data > that was stored in the GW3000 and then weewx will continue with 00, 05, 10 > etc. whatever is the time once the backfill is completed. > For this situation to be aligned and corrected with a full 5 minute > archiving at the weewx end, you would have to recreate the timestamp - and > create wrong data by the way as they didn't occur at that new "aligned" > time. > For me there is no desired behaviour here - what was archived is stored. > Accumulation only where accumulation is possible. > In my situation the GW3000 interval is two minutes, the weewx interval > too. I don't care if the timestamp for the backfill period is 1, 3, 5, 7, 9 > or 0, 2, 4, 6, 8. > I don't think that making weewx "correct" or better say "align" the > timestamp (because this alignment will provide an incorrect time) is worth > the effort. > > Either, leave it as it is, or make sure your GW3000 archive at a full 5 > minute interval timestamp or whatever is your weewx interval. > Anyhow, I don't see any issue with some records having a timestamp not > matching the start minute of the weewx archiving during normal operation. > > It may be different if e.g. the GW3000 interval is smaller/shorter than 5 > minutes, at least so short, that more than one record will fit into the gap > (assuming the weewx interval is still 5 minutes) - then the loop could be > used for accumulation, but I don't say it needs to be done that way. > > It had such a situation before where my weewx instance crashed over a > weekend and 72 hours of data were missing. But I had the data archived in > my Meteobridge in a one minute interval and had one minute interval > exports. Before editing the export file by removing 4 records for every > five minutes, I simply imported them all. Less work, no harm done. > > another question: what do you mean by " top of the interval" ? The > beginning or the end ? Weewx uses the timestamp of the end of loop > interval. Only this makes sense for a correct accumulation. > The data from the GW3000 are the data at the time of the GW3000 archiving > - no accumulation there. > On 13.07.2025 10:32, '[email protected]' via weewx-user wrote: > > I've played around a little bit with the installation of your fork and > Werners ecowitt_http.py and got many things working. > > Calculation radiation from luminosity isn't required anymore, since the > device is calculation it and it is mapped, but luminosity now has to be > calculated :) > When backfilling data, the timestamp of the record of the device seems to > be used, so with the default archive interval, when backfilling, you get > values for 07:27(or whatever it would be in the particular case) instead of > 07:30. Since WeeWX is accumulating values in an interval and storing these > accumulations with the timestamp from the top of the interval, I don't > think this is the desired behavior. > > So, for now, I consider the following as relevant settings in my > weewx.conf: > > [Station] > # Set to type of station hardware. There must be a corresponding > stanza > # in this file, which includes a value for the 'driver' option. > station_type = EcowittHttp > > ############################################################################## > [StdCalibrate] > > [[Corrections]] > # For each type, an arbitrary calibration expression can be given. > # It should be in the units defined in the StdConvert section. > # Example: > #foo = foo + 0.2 > luminosity = radiation*126.7 if radiation is not None else None > lightning_distance = lightning_distance if lightning_strike_count > > 0 else None > > ############################################################################## > # This section is for quality control checks. If units are not specified, > # values must be in the units defined in the StdConvert section. > [StdQC] > > [[MinMax]] > co2 = 0, 65534, ppm # max value is one below the theoretical max, > because sometimes after a battery change the sensor delivers the max value. > pm1_0 = 0, 6553, microgram_per_meter_cubed > pm2_5 = 0, 6553, microgram_per_meter_cubed > pm4_0 = 0, 6553, microgram_per_meter_cubed > pm10_0 = 0, 6553, microgram_per_meter_cubed > > ############################################################################## > [EcowittHttp] > # This section is for the Ecowitt Local HTTP API driver. > > # The device IP address: > ip_address = 10.0.1.84 > > # How often to poll the API, default is every 20 seconds: > poll_interval = 10 > > # The driver to use: > driver = user.ecowitt_http > > # Is a WN32P used for indoor temperature, humidity and pressure > wn32_indoor = True > > # Is a WN32 used for outdoor temperature and humidity > wn32_outdoor = True > # how many attempts to contact the device before giving up > max_tries = 3 > # wait time in seconds between retries to contact the device > retry_wait = 5 > # max wait for device to respond to a HTTP request > url_timeout = 10 > [[catchup]] > source = device # source = either, both, net, device ## not set > = None, default is then either or both > > > Ian Millard schrieb am Samstag, 12. Juli 2025 um 22:53:50 UTC+2: > >> @Michael, >> >> I am doing exactly the same thing. Can we share the pertinent parts of >> weewx.conf please? Obviously excluding sensitive information. If we can >> align our thoughts on this, I will update the repro to reflect. You can >> email me directly [email protected] >> >> Thanks, >> Ian >> >> On 12 Jul 2025, at 19:05, '[email protected]' via weewx-user < >> [email protected]> wrote: >> >> @Ian see: https://kainzbauer.net/weather/Test/Rif/ws68/index.html this >> is running the ecowitt http driver from your repo with the ecowitt_http.py >> from Werners repo. >> >> Ian Millard schrieb am Samstag, 12. Juli 2025 um 13:26:59 UTC+2: >> >>> @Michael, >>> >>> I cannot test air quality data as I do have a device. However I am able >>> to calculate: - >>> >>> [StdCalibrate] >>> >>> [[Corrections]] >>> radiation = luminosity/126.7 if luminosity is not None else None >>> luminosity = 0 if luminosity == None else luminosity >>> >>> On 12 Jul 2025, at 10:25, '[email protected]' via weewx-user < >>> [email protected]> wrote: >>> >>> Ian's fork doesn't support luminosity/radiation and pm/co2 values, >>> probably other things. I've copied the contents of Werners version of >>> https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/blob/main/ecowitt_http/ecowitt_http.py >>> over the one I've installed from Ian's fork, getting >>> luminosity/radiation and pm/co2 working. Werner has posted about his work >>> here: https://groups.google.com/g/weewx-user/c/-rbfcQsNo_s but I'm not >>> sure how this really fits into Gary's work and their forks. >>> >>> Auchtermuchty Weather schrieb am Freitag, 4. Juli 2025 um 17:45:37 UTC+2: >>> >>>> Thanks for this Ian. When I have some spare time I will give it a >>>> whirl. >>>> >>>> I have found the following in this thread: >>>> https://github.com/hoetzgit/weewx-gw1000 >>>> *https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development >>>> <https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development> >>>> *- >>>> this is Ian's fork with working catch-up >>>> >>>> https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/tree/main/ecowitt_http >>>> >>>> If I search github for weewx-ecowitt there are more but sorted by >>>> recently updated >>>> >>>> https://github.com/bidord/weewx-gw1000 >>>> >>>> However, as above, I will try Ian's out. My last contact with Gary was >>>> on the 23rd April. :( >>>> >>>> On Thursday, 3 July 2025 at 12:20:39 UTC+1 steepleian wrote: >>>> >>>>> Yes it is very worrying. >>>>> >>>>> This is the link to my fork: - >>>>> >>>>> [image: weewx-ecowitt_local_http.png] >>>>> >>>>> Millardiang/weewx-ecowitt_local_http at development >>>>> <https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development> >>>>> github.com >>>>> <https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development> >>>>> >>>>> <https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development> >>>>> >>>>> https://claydonsweather.org.uk >>>>> >>>>> On 3 Jul 2025, at 10:48, Auchtermuchty Weather <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sunday, 29 June 2025 at 11:44:21 UTC+1 Tom -KQ5S wrote: >>>>> >>>>> This is interesting. >>>>> >>>>> <sip> >>>>> >>>>> I call it deeply worrying. I was in touch with him around Easter when >>>>> he said he was on the verge of having the catch-up ready for me to test. >>>>> Then I was busy in various ways and his repository had vanished when I >>>>> came >>>>> back to looking for it. I have done some searching (probably not very >>>>> effectively) and can't find a trace of him. >>>>> >>>>> Should point out it wasn't the only useful utility he had there - >>>>> there was PolarWindPlot, and I think a couple more. >>>>> >>>>> Worrying about Gary aside, where is the best place to download a copy >>>>> of the driver with backfil? >>>>> >>>>> >>>>> -- >>>>> 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]. >>>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/weewx-user/332e8804-ad61-41c5-8dd4-3d5bbb3dbd3cn%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/weewx-user/332e8804-ad61-41c5-8dd4-3d5bbb3dbd3cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>> -- >>> 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]. >>> >>> To view this discussion visit >>> https://groups.google.com/d/msgid/weewx-user/fa1c26a8-b1cd-4244-b500-5f3e3356da22n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/fa1c26a8-b1cd-4244-b500-5f3e3356da22n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >> -- >> 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]. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/weewx-user/7e5b4660-87db-439e-9f49-f5b95043d881n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/7e5b4660-87db-439e-9f49-f5b95043d881n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- > 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]. > > To view this discussion visit > https://groups.google.com/d/msgid/weewx-user/1c3e9553-2b30-450a-8bfa-b949c90a58ecn%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/1c3e9553-2b30-450a-8bfa-b949c90a58ecn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/cc618911-07a0-4380-b6f9-1e8c0e66ab81n%40googlegroups.com.
