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.
poniedziałek, 31 marca 2025 o 06:57:56 UTC+2 Cameron D napisał(a): > 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/713e929e-0458-4a8f-843d-b663c4305a1an%40googlegroups.com.
