I suggest the wee_import approach earlier in the thread
of course weewx won't do this by itself, the import needs to be triggered
for such tasks you can create a CRON job - in Linux (derivate)
installations usually the cronjob config file is /etc/crontab
if you want to update weewx every five minutes, you have to initiate the
download and import every five minutes
for the import there should be an example file in the weewx file system
for the wee_import itself see
version 4
https://weewx.com/docs/4.10/utilities.htm#wee_import_utility
version 5
https://weewx.com/docs/5.1/utilities/weectl-import-about/
example for an import.conf file attached
to avoid conflicts mentioned in the utilities guide, you better run your
cronjob in the middle of your archiving interval e.g. not at the full
five minutes (if that's your interval) but two or three minutes later to
avoid conflicting access to the database - the same applies to the
wee_database/weectl_database tool (|wee_database --rebuild daily /
weectl database rebuild-daily) |you may want to run after each import to
update your summary tables
On 23.03.2025 08:10, 'Tomasz Lewicki' via weewx-user wrote:
I don't know if this makes sense or not, I simply described my
attempts. tcpdump is unlikely to lie. But fine. Let's assume I don't
have the ability (or skill) to use the interceptor driver. Are there
other options for getting data from the station?
It seems to me that I have two ways - direct and indirect.
1. Direct
I found information about the weewx-sdr controller. From the
description it seems to me that it can help me in my situation. It
works well, because I have an SDR dongle that I use to receive ADS-B
signals.
2 Indirect
Downloading the data sent by the station to the WU and uploading it to
Weewx. I repeat the question from the previous message - does Weewx
allow import on the fly from WU, or only from manually fed files?
niedziela, 23 marca 2025 o 02:35:36 UTC+1 vince napisał(a):
Not sure your description makes much sense. There has to be some
traffic from the station to an ip off network. I’d expect ntp and
dns traffic as well.
On Saturday, March 22, 2025 at 12:48:59 PM UTC-7 Tomasz Lewicki wrote:
Today I had the opportunity to face the Garni 1025 station.
Unfortunately, the issue is much more complex than it might
seem at first. The universal driver “interceptor” is powerless
in this case. The station communicates with the environment in
a strange way. It turns out that the panel with the display
does not connect directly to the local network as a device
with an IP address in the range given by the DHCP server of
the home router, but probably forms a kind of bridge between
itself and the router.
The way I came to this was that after connecting the Raspberry
Pi with Weewx installed, I scanned the local network with my
smartphone and found no device in it that could be a Garni
panel. From the instructions, I learned that to configure the
panel, you need to press the appropriate button on the case
and enter AP mode. Then you can enter the default address
192.168.1.1 with a browser and there enter the SSID of your
home network and the password for it. I managed to connect the
laptop to the network created by the Garni panel and started
sniffing on the network traffic. Unfortunately, tcpdump didn't
show anything that would give any meaningful clues. The only
packets were sent by the Garni panel to my laptop. I couldn't
see any packets that Garni was routing to the router, yet it
must be transmitting something if data is being sent to the
WU, right?
Do you see any way that I could still try?
PS. Does Weewx allow you to import data from WU in "quasi real
time"? What I mean is, can I download data from WU, for
example, every 5-10 minutes and feed it to Weewx so that it
creates charts locally.
niedziela, 16 marca 2025 o 10:02:32 UTC+1 Tomasz Lewicki
napisał(a):
Thank you all for the helpful replies.
As I said, the station is out of my reach so I hoped to
prepare "dry run" and set up Weewx in my home environment
and then just connect in in target network, changing only
necassary things (WiFi network and so on). If it is not
possible, I have to use tcpdump "in situ", where Garni
works. But - replying to Reiner Lang's suggestion - Garni
sends the data to WU instantly; you can check it here ->
https://www.wunderground.com/dashboard/pws/IKOWAL30
In the meantime I got a photo of manual page from the
owner of the station (Garni doesn't share the manuals on
its website - it's strange) and then I was almost sure
that Garni uses Weathercloud protocol because setup allows
setting my own server (if someone is curious, here is a
photo -> http://stalker.udl.pl/temp/garni1025.jpeg). So I
looked into Weathercloud website and can confirm that
Garni 1025 uses Weathercloud protocol ->
https://weathercloud.net/en/compatible-devices List
contains plenty of manufacturers which I know. Rainer Lang
hinted that manufacturer is CCL (shame to say it but I did
not know this company). I found quite old "wcloud" driver
from Matthew Wall
(https://github.com/matthewwall/weewx-wcloud) but if I
understand it good, it allows only for uploading the data
from Weewx to Weathercloud server, not downloading it from
weather station.
So maybe the clones which Weewx supports are using some
"standard" protocol (whatever means "standard" when
talking about PWS) and I can use some known driver here...?
niedziela, 16 marca 2025 o 02:55:59 UTC+1 vince napisał(a):
Can you perhaps just listen for all tcp traffic and
not specify the src address and see what is on your
network ?
I’d think you might try to listen for tcp src
192.168.0.0/24 <http://192.168.0.0/24> dst not
192.168.0.0/24 <http://192.168.0.0/24> and not specify
any port.
Or listen for all tcp traffic for at least 10 minutes
and capture to a file, then transfer the pcap file
back to your computer to analyze in the
wireshark/ethereal gui later. If you could post a pcap
file somewhere I’m sure folks will see if they can
help determine the correct settings.
On Saturday, March 15, 2025 at 6:15:42 PM UTC-7
matthew wall wrote:
tomasz,
you are correct to first use tcpdump. once you see
data using tcpdump, then you can experiment with
interceptor to get the data into weewx. if the
station can successfully post to wunderground,
then the interceptor *should* be able to capture
the data. but you should first use tcpdump to
figure out the settings necessary to capture data.
is it possible to adjust the destination in the
weather station? if so, you could tell the
station to send to the computer running weewx,
instead of wunderground. but still use the
wunderground protocol.
can you control the dns entries on the network?
if so, make weatherstation.wunderground.com
<http://weatherstation.wunderground.com> resolve
to the computer running weewx, then run
interceptor in listen mode. if you already run a
web server on port 80 then you would have to make
interceptor listen on a port other than 80, then
adjust the web server configuration to send
traffic for
/weatherstation/updateweatherstation.php to that
port. or do it with firewall rules.
does your network switch support port mirroring?
if so, mirror the port that the weather station
uses and make interceptor listen on the mirrored port.
or if the station is wifi, make interceptor listen
on an interface that can see the wifi traffic.
but first use tcpdump in one of these
configurations to ensure that you can see the data
from the station.
m
--
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/b9622ebb-15d9-43c8-96e5-083fce340079n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/b9622ebb-15d9-43c8-96e5-083fce340079n%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/dc1ebb9c-3495-4267-9980-faa02d5715ac%40gmail.com.
# EXAMPLE CONFIGURATION FILE FOR IMPORTING FROM THE WEATHER UNDERGROUND
#
# Copyright (c) 2009-2019 Tom Keffer <[email protected]> and Gary Roderick.
# See the file LICENSE.txt for your rights.
##############################################################################
# Specify our source. Available options are:
# CSV - import obs from a single CSV format file
# WU - import obs from a Weather Underground PWS history
# Cumulus - import obs from a one or more Cumulus monthly log files
# WD - import obs from a one or more WD monthly log files
# Format is:
# source = (CSV | WU | Cumulus)
source = WU
##############################################################################
[WU]
# Parameters used when importing from a WU PWS
# WU PWS Station ID to be used for import.
station_id = XXXXXXXX123
# WU API key to be used for import.
api_key = XXXXXXXXXXXXXXXXXXXXXX1234567890
#
# When importing WU data the following WeeWX database fields will be
# populated directly by the imported data (provided the corresponding data
# exists on WU):
# barometer
# dateTime
# dewpoint
# heatindex
# outHumidity
# outTemp
# radiation
# rain
# rainRate
# windchill
# windDir
# windGust
# windSpeed
# UV
#
# The following WeeWX database fields will be populated from other
# settings/config files:
# interval
# usUnits
#
# The following WeeWX database fields will be populated with values derived
# from the imported data provided the --calc-missing command line option is
# used during import:
# altimeter
# ET
# pressure
#
# The following WeeWX fields will be populated with derived values from the
# imported data provided the --calc-missing command line option is used
# during import. These fields will only be saved to the WeeWX database if
# the WeeWX schema has been modified to accept them. Note that the pyephem
# module is required in order to calculate maxSolarRad - refer WeeWX Users
# Guide.
# appTemp
# cloudbase
# humidex
# maxSolarRad
# windrun
# How will the interval field be determined for the imported records.
# Available options are:
# derive - Derive the interval field from the timestamp of successive
# records. This setting is best used when there are no missing
# records from period being imported. Missing records will
# cause the interval field to be incorrectly calculated for some
# records.
# conf - Use the interval setting from weewx.conf. This setting is
# best used if the records to be imported have been produced by
# WeeWX or some other means with the same archive interval as
# set in weewx.conf on this machine.
# x - Use a fixed interval of 'x' minutes for every record where 'x'
# is a number. This setting is best used if the records to be
# imported are equally spaced in time but there are some missing
# records.
# Due to WU frequently missing uploaded records, use of 'derive' may give
# incorrect or inconsistent interval values. Better results may be
# achieved by using the 'conf' setting (if WeeWX has been doing the WU
# uploading and the WeeWX archive_interval matches the WU observation
# spacing in time) or setting the interval to a fixed value (eg 5). The
# most appropriate setting will depend on the completeness and (time)
# accuracy of the WU data being imported.
# Format is:
# interval = (derive | conf | x)
interval = x
# Should the [StdQC] max/min limits in weewx.conf be applied to the
# imported data. This may be useful if the source has extreme values that
# are clearly incorrect for some observations. This is particulalrly useful
# for WU imports where WU often records clearly erroneous values against
# obs that are not reported. Available options are:
# True - weewx.conf [StdQC] max/min limits are applied.
# False - weewx.conf [StdQC] max/min limits are not applied.
# Format is:
# qc = (True | False)
qc = True
# Should any missing derived observations be calculated from the imported
# data if possible. Available options are:
# True - Any missing derived observations are calculated.
# False - Any missing derived observations are not calculated.
# Format is:
# calc_missing = (True | False)
calc_missing = True
# Specify how imported data fields that contain invalid data (eg a numeric
# field containing non-numeric data) are handled. Available options are:
# True - The invalid data is ignored, the WeeWX target field is set to
# None and the import continues.
# False - The import is halted.
# Format is:
# ignore_invalid_data = (True | False)
# Default is True.
ignore_invalid_data = True
# Imported records are written to archive in transactions of tranche
# records at a time. Increase for faster throughput, decrease to reduce
# memory requirements. Format is:
# tranche = x
# where x is an integer
tranche = 250
# Lower and upper bounds for imported wind direction. It is possible,
# particularly for a calculated direction, to have a value (eg -45) outside
# of the WeeWX limits (0 to 360 inclusive). Format is:
#
# wind_direction = lower,upper
#
# where :
# lower is the lower limit of acceptable wind direction in degrees
# (may be negative)
# upper is the upper limit of acceptable wind direction in degrees
#
# WU has at times been known to store large values (eg -9999) for wind
# direction, often no wind direction was uploaded to WU. The wind_direction
# parameter sets a lower and upper bound for valid wind direction values.
# Values inside these bounds are normalised to the range 0 to 360. Values
# outside of the bounds will be stored as None. Default is 0,360
wind_direction = 0,360
