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.pyover
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_sbut 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*-
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: -
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
[email protected].
To view this discussion
visithttps://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 [email protected].
To view this discussion
visithttps://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/d6d86d16-20e8-4bcb-b953-29769bcc98b3%40gmail.com.
