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.
On Monday, 31 March 2025 at 6:10:31 am UTC+10 Tomasz Lewicki wrote: > 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 :) > > wtorek, 25 marca 2025 o 02:59:05 UTC+1 Cameron D napisał(a): > >> 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. >> >> On Tuesday, 25 March 2025 at 6:24:10 am UTC+10 Rainer Lang wrote: >> >>> @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. >>> On 24.03.2025 05:42, 'Cameron D' via weewx-user wrote: >>> >>> 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 >>> >>> On Sunday, 23 March 2025 at 5:48:59 am UTC+10 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 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. >>>>>> >>>>>> 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 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/805d8c77-046b-4f35-9d0b-ed090a1536b1n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/805d8c77-046b-4f35-9d0b-ed090a1536b1n%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/3004bf18-0109-4611-96b8-9d0cf63d846cn%40googlegroups.com.
