https://github.com/gjr80/weewx-gw1000/wiki has disappeared from GitHub
Rainer Lang
@Gary or others knowledgeable regarding the
topic ...
Is there a special reason why this link doesn't work anymore ?
Or is this only a temporary thing ?
A search on GitHub with the "GW1000" keyword doesn't give any results ...
best regards
Rainer
Chuck Rhode
"'Rainer Lang' via weewx-user" <weewx...@googlegroups.com> wrote:
> Is there a special reason why this link doesn't work anymore ?
the day I reached for the WeeWX driver. Arghhh!
--
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx
.. 65° — Wind SE at 10 mph. Sky clear.
John Kline
List of broken links and other issues:
https://github.com/gjr80
Line: 1062
Code: 404 Not Found
Not only have all of Gary’s repositories disappeared, Gary (gjr80) has also disappeared from github. Hopefully, this wasn’t intentional and Gary’s work will appear again soon.
> On Jun 1, 2025, at 12:47 PM, Chuck Rhode <charlescu...@gmail.com> wrote:
>
> On Sun, 1 Jun 2025 21:14:19 +0200
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/weewx-user/20250601144726.3a231199%40BigTimber.LacusVeris.com.
BarCar
Auchtermuchty Weather
Auchtermuchty Weather
Tom -KQ5S
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/d44f4a36-281a-4b8a-9190-732e29e43e99n%40googlegroups.com.
Tom Keffer
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/d44f4a36-281a-4b8a-9190-732e29e43e99n%40googlegroups.com.
Tom -KQ5S
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEBCC_FgqmT8xFfCz%3DHOtUnrcH8WyMsGSZZN1tXB6iVpdw%40mail.gmail.com.
steepleian
On 29 Jun 2025, at 12:54, Tom -KQ5S <kq5...@gmail.com> wrote:
I had a link to weewx on his home server. It no longer works but if I go to the root of the server I get the Welcome to nginx screen so his server is still active which is reassuring.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/3817CC21-3FE0-4042-AD52-D007FD44FFB5%40gmail.com.
michael.k...@gmx.at
steepleian
On 29 Jun 2025, at 13:42, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
I think it is less about being willing doing it, but being able doing it in way that is creating the best value for everyone. I'd be willing, but I don't have the resources to push myself on a python level, that would be sufficient to achieve this, apart from barely finding time for the Bootstrap skin. Rainer probably is probably more than enough challenged with his FOSHKplugin. But he and "Gyvate" have excellent connections to the manufacturer, who has proved several times that they are willing to communicate and support the community with information and fixes needed to provide solutions like a driver for a software like WeeWX. Maybe we find a way to bundle our individual strengths and develop the driver to the next level?
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/824748cd-7f85-4828-a354-18ba3226ae2bn%40googlegroups.com.
michael.k...@gmx.at
Ian Millard
 | |
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/ed9d2be7-68e1-4b03-bfa3-bd265c359727n%40googlegroups.com.
Ian Millard
On 29 Jun 2025, at 15:20, 'Ian Millard' via weewx-user <weewx...@googlegroups.com> wrote:
Hi Michael,Here it is, this is the development branch, the main branch is not yet fully populated: -
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/00F94C7F-4878-4137-B7C7-649CD98EB762%40btinternet.com.
Rainer Lang
regarding the backfilling between application restarts
the GW3000 (and WS6210) SD card csv file
structure is completely documented in my FO/EW WiKi - as is the
http API and the custom server structure
SD card:
http://192.168.1.111/dokuwiki/doku.php?id=start#gw3000-csv
for the http API which is definitely much
easier to handle than the earlier binary API:
http://192.168.1.111/dokuwiki/doku.php?id=start#c_retrieval_of_sensor_data_from_the_local_network_via_http_call_local_http_api
and
http://192.168.1.111/dokuwiki/doku.php?id=start#b_retrieval_of_live_data_from_the_local_network_via_http_call_local_http_api
I can assist in answering questions and clarifying to my skill
and capacity - and can also do driver testing
I've been doing this with the developers of two other rather
well know datalogger software (CumulsuMX, Meteobridge) and I
have at least one item
of each existing sensor
the existing driver for the binary API
can/must still be used with some meanwhile legacy gateway models
like the GW1000 and WH2650
so we will have two drivers - call them GW1000 (binary) and
GW3000 (http)
and, by the way, FOSHKplugin is Oliver 😉 - these laurels I don't deserve
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/ed9d2be7-68e1-4b03-bfa3-bd265c359727n%40googlegroups.com.
Rainer Lang
@Ian
I had a brief rather superficial run through the Python code -
looks like both backfilling options are implemented (ecowitt.net
and SD card)
and the coding looks pretty complete
Now
how and where do you set the option(s)
- if backfilling is used or not
- if backfilling is via ecowitt.net
- if backfilling is via SD card
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/D2F9CBE9-202B-412F-B53C-CD46DDFA7906%40btinternet.com.
Ian Millard
(weewx-venv) dvm@dvm:~$ sudo journalctl -u weewx -f
Jul 01 15:09:41 dvm python3[3781035]: for rec in self.gen_ecowitt_archive_records(since_ts=lastgood_ts):
Jul 01 15:09:41 dvm python3[3781035]: File "/home/dvm/weewx-data/bin/user/ecowitt_http.py", line 4876, in gen_ecowitt_archive_records
Jul 01 15:09:41 dvm python3[3781035]: catchup_obj = self.catchup_factory()
Jul 01 15:09:41 dvm python3[3781035]: ^^^^^^^^^^^^^^^^^^^^^^
Jul 01 15:09:41 dvm python3[3781035]: File "/home/dvm/weewx-data/bin/user/ecowitt_http.py", line 4924, in catchup_factory
Jul 01 15:09:41 dvm python3[3781035]: return EcowittNetCatchup(api_key=self.api_key,
Jul 01 15:09:41 dvm python3[3781035]: ^^^^^^^^^^^^
Jul 01 15:09:41 dvm python3[3781035]: AttributeError: 'EcowittHttpDriver' object has no attribute 'api_key'
Jul 01 15:09:42 dvm systemd[1]: weewx.service: Main process exited, code=exited, status=1/FAILURE
Jul 01 15:09:42 dvm systemd[1]: weewx.service: Failed with result 'exit-code’.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/cacb603d-08f0-4694-9bd1-3adf7f5b641e%40gmail.com.
vince
Rainer Lang
the ecowitt.net backfill and the SD card backfill are mutually exclusive/excluding each other
in addition, the MAC address of the console
in question is needed - also for the SD card download the MAC
address is needed
=> a nested setup (as e.g. done in CumulusMX) will make sense
1. activate ecowitt.net by providing MAC,
APP and API keys
2. if 1. is activated AND SD card is activated (MAC info
available), then SD card backfill takes priority
=> something like a SD card backfill switch needs to be
considered - more code inspection needed
3. SD card backfill should be possible without providing an
APP/API key
also to consider (unless already done --> code inspection):
the ecowitt.net lowest data resolution is 5
minutes, the SD card resolution (if so chosen) goes down to one
minute
=> if you have a 300 second/5 minute archiving interval, the
SD card data might have to run through the loop and accumulation
process
for all records whereas from ecowitt.net there is a 1:1 filling
of the loop and archive table ("dictionary").
result: four more switches/options/parameters needed
1. app_key = key
2. api_kep = key
3. mac_address = MAC
4. SD_card = yes/no
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/89f016c5-2b15-4f8c-9724-8b580e2d6163n%40googlegroups.com.
Rainer Lang
after some code inspection (and my
understanding of Python) it appears (see catchup_factory(self)
line 4897)
that at weewx startup, if a device with SD card is available
under the IP address from weewx.conf, the EcowittDeviceCatchup
class is executed.
If not, provided the API/APP key and MAC address info is
available, the backfill ("catchup") via ecowitt.net is
initiated.
So far there is no weewx.conf option available to keep the SD
card backfilling/catchup from being executed.
SD card backfill takes precedence over ecowitt.net backfill.
The ecowitt.net backfill/catchup can be avoided by not providing
the needed info (APP/API keys/MAC).
Tom Keffer
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/79156d5c-99f1-48fc-96ca-156579ea3c99%40gmail.com.
Rainer Lang
@Tom
thanks - that's very helpful information
taking this piece of information into account I think that all
options needed are covered
Tom Keffer
Steeple Ian
vince
Auchtermuchty Weather
This is interesting.
steepleian
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/332e8804-ad61-41c5-8dd4-3d5bbb3dbd3cn%40googlegroups.com.
Werner Krenn
You can find the adapted driver and some information about it:
https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/blob/main/ecowitt_http
What doesn't work:
- the service function doesn't work
- loop packets aren't used (but they are picked up!).
Ian Millard
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/8a5eda02-d12f-4433-9455-e7812f6f4ba7n%40googlegroups.com.
michael.k...@gmx.at
Auchtermuchty Weather
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
michael.k...@gmx.at
Ian Millard
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/fa1c26a8-b1cd-4244-b500-5f3e3356da22n%40googlegroups.com.
michael.k...@gmx.at
Ian Millard
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/7e5b4660-87db-439e-9f49-f5b95043d881n%40googlegroups.com.
michael.k...@gmx.at
Rainer Lang
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.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/1c3e9553-2b30-450a-8bfa-b949c90a58ecn%40googlegroups.com.
michael.k...@gmx.at
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.