Garni 1025 (unknown protocol) and interceptor driver

[Tomasz Lewicki]

I started new thread but referring to this one: https://groups.google.com/g/weewx-user/c/AMecZZXf_BM

I have to configure quite exotic weather station - Garni 1025 from Czech Republic (https://www.garnitechnology.com/garni-1025-arcus/). It would be much simpler when knowing its communication protocol but I don't know it. But I know it supports Weather Underground and Weathercloud services. It doesn't have USB connection so WS6in1 driver can't be used in this case. Moreover, I do not have physical access to this station - hardware is is not mine; I have to configure Raspberry Pi and just connect it in the target location.

But I have my own PWS - quite old Ambient Weather WS-1002. I use it with Raspberry Pi via interceptor driver in "observer" mode. As I said earlier, I don't know what protocol Garni uses so it will be much safer if I use interceptor driver in "sniff" mode. To keep the whole story to a minimum:

1. I got working Weewx 5.1.0 on "target" RPi (target = RPi for Garni, not for my home station)
2. I installed interceptor driver and it works, no errors in Weewx log

I thought I would test the target RPi by running Weewx in sniff mode and listening for packets from my home station. But I get no packets from my station, as log says:

weewxd[738]: DEBUG user.interceptor: empty queue
(and repeating)

I'm not sure if I use proper configuration so here it goes:

1. target RPi has 2 network interfaces:
   * built-in wlan0 with IP address 192.168.0.143
   * USB wlan1 with IP address 192.168.0.120

2. my home station's display panel has IP address 192.168.0.113 and it sends the data to rtupdate.wunderground.com (probably standard port 80)

3. the relevant section of weewx.conf looks like this:

[Interceptor]
    driver = user.interceptor
    device_type = wu-client
    mode = sniff
    iface = wlan1
    pcap_filter = src 192.168.0.113 and dst port 80
   
I tried listening for packets from 192.168.0.113 using tcpdump with this command running on target RPi:

tcpdump -i wlan1 "src 192.168.0.113 and dst port 80"

but without effect - no packets are coming.

I also changed iface = wlan1 to iface = wlan0 but no change - still empty queue.

I'm stuck so I would appreciate if someone experienced will go through it and tell me if everything is OK, and if not, what I should change and check.

[Rainer Lang]

One thing I can tell that the Garni 1025 is not a Fine Offset clone 
model like your Ambient ObserverIP WS-1002 - therefore the settings for 
your WS-1002 cannot be taken. It's a different manufacturer for the 
Garni 1025, CCL. When your Garni 1025 posts to WU, it probably posts 
only every 5 minutes, so it might not be astonishing that you don't 
receive anything with tcpdump, even if the settings look sensible. There 
is another option you may want to test which could give you the same 
results: your can download data from WU and import them into weewx using 
wee_import check the weewx documentation - weewx utilities guide

On Sat, Mar 15, 2025 at 11:47 PM Rainer Lang <lang....@gmail.com> wrote:

One thing I can tell that the Garni 1025 is not a Fine Offset clone 
model like your Ambient ObserverIP WS-1002 - therefore the settings for 
your WS-1002 cannot be taken. It's a different manufacturer for the 
Garni 1025, CCL. When your Garni 1025 posts to WU, it probably posts 
only every 5 minutes, so it might not be astonishing that you don't 
receive anything with tcpdump, even if the settings look sensible. There 
is another option you may want to test which could give you the same 
results: your can download data from WU and import them into weewx using 
wee_import check the weewx documentation - weewx utilities guide

--
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/f12b2e63-ce9a-4522-b34a-70e8191d7594n%40googlegroups.com.

[matthew wall]

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 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

[vince]

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 dst not 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.

[Tomasz Lewicki]

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...?

[Tomasz Lewicki]

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.

[vince]

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.

[Tomasz Lewicki]

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?

[Rainer Lang]

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

--
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/b9622ebb-15d9-43c8-96e5-083fce340079n%40googlegroups.com.

[Tomasz Lewicki]

Thank you for the hint about importing from WU.

In the meantime, I managed to get the SDR dongle to download data from my home station - a clone of Ambient Weather WS-1002. The tests went well, the dongle captures packets, I mapped the sensors and compared the readings from the interceptor controller and directly from the display. Unfortunately, like many before me, I am having trouble determining the insolation in W/m2.

When reading from rtl_433, I get this result (JSON format):

{ “time” : “2025-03-23 10:56:53”, “model” : “Fineoffset-WH24”, “id” : 100, “battery_ok”. : 1, “temperature_C” : 8.500, “humidity” : 69, “wind_dir_deg” : 100, “wind_avg_m_s” : 1.680, “wind_max_m_s” : 2.240, “rain_mm” : 792.300, “uv” : 527, “uvi” : 1, “light_lux” : 16065.800, “mic” : “CRC”}

How to convert light_lux to W/m2 for this station?

EDIT: I have already concluded that you need to divide the value in lux by 126.7 to get the value in W/m2. I made the changes in the [StdCalibrate] section:

[StdCalibrate].
   
    [[Corrections]]
        radiation = radiation / 126.7
       
How do I get Weewx to respect this correction?

I hope that if I was able to “get along” with my station using SDR, I will repeat this success with Garni 1025.

[vince]

One thing I’ve found is that some devices only query dns and especially ntp when they power up, so it is easy to miss those if you run tcpdump after the console is already running.  You might have more luck if you start tcpdump then power the console down/up.

SDR should likely see something if you can figure out the frequency settings, but decoding it might be difficult initially. If it is similar to other stations already known by weewx-sdr then extending that driver by adding a new definition is pretty straightforward.

SDR will not have any data from sensors in the console itself (typically pressure and inside temperature)

I do not recall anything that imports realtime from WU. Interceptor intercepts traffic ‘to’ WU. WU does not send data anywhere.

[Tomasz Lewicki]

OK, I got it. 

Dividing did not work, but multiplying did. Instead of:

radiation = radiation / 126.7

I used the formula:

radiation = radiation * 0.007893

and calculations look reasonable.

[gjr80]

Tomasz,

Can you please elaborate? If there is a bug here we would like to fix it. What did you see to make you say it did not work, did you see an error in the log (in which case can you post it) or was the result unexpected (in which case can we see the uncorrected and corrected values)? Either of those StdCalibrate corrections should work and give the same result.

Gary

[Cameron D]

I don't understand why the Garni would need to be set up as you describe - its specification is only 2.4GHz for Wifi, so its value as a real AP would be minimal. It does not seem to need to use wifi for connecting to anything else (that uses 868MHz).

You wrote that "I managed to connect the laptop to the network created by the Garni panel..." but that does not fit - an AP does not create a new wifi network, it only extends the existing one created by the router.

Most likely the router recognises that the upload traffic from the panel is not local and does not show it to the laptop/pi, since it would require retransmitting.  A domestic router is unlikely to offer traffic mirroring/monitoring.

If all that is correct then I think your options are:

1. investigate the option where it says "access data on user's own server"

2. set up the Pi as another wifi router and pass the traffic through it - then use ethernet to the external router

[Tomasz Lewicki]

Sorry for delay in answering. Dividing didn't work but multiplying did:

radiation = radiation * 0.007893

I don't know why but it works now and displays correct value.

[Tomasz Lewicki]

I don't know how or why it works that way. Unfortunately, as I wrote earlier, the station does not belong to me and I have no physical access to it. When I entered AP mode (that's exactly what the manual calls it), a new one called PWS-nnnnnn (nnnnnn are the last six digits of the MAC address) appeared in the list of wireless networks. I would then connect - without a password - to that AP. But when the Garni is in AP mode, it does not transmit data to the Internet, i.e. to the home router - I see it because WU isn't refreshed. I have to leave AP mode for it to start sending data again. But at the same time, when leaving AP mode, my laptop stops receiving packets from Garni's panel.

In my opinion, this is an unnecessary complication, but since I can't do anything about it, I'm looking for other solutions. Since I was able to use the SDR dongle in my home setup, it will almost certainly work with Garni. The problem is determining the transmit frequency. I suppose it's 868 MHz, since this is equipment for the European market.

Unfortunately, the second option suggested by Cameron D (“set up the Pi as another wifi router and pass the traffic through it - then use ethernet to the external router”) is not feasible - I'm using a Raspberry Pi Zero, which doesn't have an Ethernet connector.

[vince]

The setup procedure you mention is exactly like an ecowitt gateway’s. You put an ecowitt gateway/console into a setup mode and you can connect to it from any wifi device to do the setup steps. So that is why it works that way.  It permits setting it up from a laptop or other wifi device wirelessly without requiring bluetooth (which a weatherflow hub requires, for example).

Using a pi zero certainly makes your diagnostics more difficult,  I still recommend starting tcpdump and capturing to a file, power cycling the garni, and seeing if you can capture its communication. It almost certainly does a ntp lookup and probably dns queries as well. You might set the garni dns to 8.8.8.8 and 8.8.4.4 to use google dns (if I recall their addresses correctly) but that might be on the advanced tab in your setup gui. I didn’t notice it on the jpeg you linked to.

[Tomasz Lewicki]

OK, so I will try this approach - connecting to Garni's own network, power off and on and tcpdump'ing. I will then give a feedback here. Maybe it will help someone in the future. But I can make such an attempt at next weekend.

[Rainer Lang]

@Cameron D.
I think you are mistaken here regarding the console WLAN - even if that Garni piece is manufactured by CCL, what they do is a commonly used process.
E.g. factually all FineOffset (clone) consoles can create their own WLAN and a WLAN enabled device (PC, Smartphone etc.) can connect to it via the SSID the console sends. So that console also becomes an access point for its own WLAN. It has not yet anything to do with the local WLAN.
The local WLAN is then selected through the console and the user can connect to it via the local SSID and the router password. Now, that console has two interfaces - through its own WLAN and through the local WLAN.
Usually the console WLAN is switched off once the connection to the local WLAN is established.
This process sometimes called "WiFi provisioning" or "pairing" is quite common.

The 2.4 GHz come into play as the console is usually only 2.4 GHz enabled.
Considering this having a minimal value is immaterial - the value consists of being able to connect the console to the local WLAN - this type of setup is quite common and usually works well - provided the user takes a few precautions like e.g. switching off the mobile data network during the "pairing" process and avoiding also having a 5 GHz WLAN with the same SSID active during the pairing.

--
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/805d8c77-046b-4f35-9d0b-ed090a1536b1n%40googlegroups.com.

[Cameron D]

yes, I realised my mistake once Vince mentioned the EcoWitt setup.

It is an unfortunate ambiguity of "Access Point" terminology, which I have only seen used to describe the process I was referring to - bridging two network segments.

From the  description Tomasz gave it seems the panel has a single wifi interface that either sets up an isolated private wlan, or acts as a wifi client.

[Tomasz Lewicki]

Today I had the opportunity to test Garni again and... I am even more confused.

After switching to AP mode, I entered an additional user server in the configuration (manual page with screenshot: http://stalker.udl.pl/temp/garni1025.jpeg):

URL: 192.168.1.153 (RaspberryPi IP with Weewx installed)
Station ID: ABC
Station key: abc

Then I ran tcpdump on the RPi. It recorded several packets to port 80 coming from Garni (192.168.1.100). I saved them in a .pcap file, unfortunately they don't tell me anything meaningful. I'm sharing two files, maybe someone can find something in them?

http://stalker.udl.pl/temp/weewx1.pcap
http://stalker.udl.pl/temp/weewx2.pcap

The weewx.conf fragment for the interceptor driver looks like this in my case:

[Interceptor]
    driver = user.interceptor
    device_type = wu-client
    mode = sniff

    iface = wlan0
    pcap_filter = src 192.168.1.110 and dst port 80

Unfortunately, with these settings I still see an empty queue.

So I set about listening in using the SDR dongle. The rtl_433 found several devices in the area transmitting at 868 MHz, including Garni:

2025-03-30T17:42:08.703037+02:00 raspberrypi weewxd[475]: INFO user.sdr: unmapped: {'dateTime': 1743349325, 'usUnits': 17, 'temperature.43967.Bresser7in1Packet': 8.6, 'humidity.43967.Bresser7in1Packet': 51.0, 'wind_gust.43967.Bresser7in1Packet': 1.1, 'wind_speed.43967.Bresser7in1Packet': 1.1, 'wind_dir.43967.Bresser7in1Packet': 90.0, 'rain_total.43967.Bresser7in1Packet': 0.0, 'lux.43967.Bresser7in1Packet': 3849, 'uv.43967.Bresser7in1Packet': 0.0, 'battery.43967.Bresser7in1Packet': 0}

And such messages repeat periodically. So I was half-successful. Why only half? Because I can't see the messages from the interior panel - interior temperature and pressure. Does this mean that the panel is not transmitting anything on radio frequencies (868 MHz in my case) like the external module?

I already have a starting point in the form of Weewx recognizing the station as a Bresser 7in1. Searching by this designation I came across such a thread on WXforum.net: https://www.wxforum.net/index.php?topic=45249.0 and others. Unfortunately, in neither case did I find information about downloading data from the internal panel.

Could someone suggest something? If the panel actually does not send anything that the SDR dongle is able to capture, only the interceptor driver remains. But how do I get it to capture packets from the network, since I think I've set the appropriate section in weewx.conf correctly, but I still see an empty queue?

I'm counting on the wisdom of the group :) 

[vince]

Generally consoles do not transmit over RF.  When I spun up rtl-davis to use the SDR with my vp2 I had to add an inexpensive bme280 sensor to my pi to get inside temperature and pressure readings. That was reasonably straightforward.

So you need pi + extra sensor if you use SDR…

[Cameron D]

All unicast traffic in those captures is either to or from the Pi (192.168.1.153)

If you apply a filter in wireshark "ip.addr != 192.168.1.153" then all that is left is broadcast or multicast packets

The samples are only 90 and 70 seconds long, so if the remote updates are every 5 minutes then you might well have missed them.

Alternatively, the network configuration you are using does not expose that other traffic to the Pi.

[Cameron D]

And the traffic between the Garni and the Pi is:

Garni tries to open a connection on the Pi port 80. (tcp SYN)

Pi immediately closes the connection, (tcp RST, ACK) - usually a sign that no program is listening for port 80 connections, although it could be a firewall action. 

One possibility for the attempted connection might be that the Garni is testing for a local app on a phone?

[Cameron D]

sorry, I did not read your post thoroughly enough.

You have told the Garni that you are running a server on the Pi to collect the weather data - but you are not running a server.  That is why the Pi sends the reset packet and closes the connection.

[Tomasz Lewicki]

I was confused by the fact that my private Ambient Weather station sends a radio signal from both devices - the external module and the internal panel with the display. I (mistakenly) assumed that every station works that way. But your idea with the additional BM280 module is a good one. I just happen to have one spare. Except that it makes a complicated installation, and I wanted to simplify everything as much as possible :) 

[Tomasz Lewicki]

Correct, but I was hoping that by routing the TCP transmission to the Raspberry with Weewx on board I would cause the packets to be captured by Weewx.

[Cameron D]

You may have been hoping for that, but TCP/IP does not work that way. 

There are ways of doing it, but it will be interfering in the normal network traffic flow and, while OK at your home, is  probably not suitable for the installation you are describing.

I think running a parallel system where you get the RF data directly would be far preferable. It might have the added benefit that it should keep working even if the Garni base station stops.