By WD you mean a ConsoleWD, right? I don’t use a desktop release (Jessie for RPi) but ust a console.
in more linux distribs you have a pi version
You can also use this to capture and archive WeatherFlow UDP data.
indeed, so new I’m not yet used to it and I personally didn’t test it yet … soon
Great, thanks all for feedback! I’ll also try to redirect the traffic on port 50222 to my different subnet. But I may give a RPi a try first.
I’m used to WD but my colleague uses a weewx with his station. I’m happy there are options. Also the default software seems to do a very good job!
I use both WeatherDisplay by Brian Hamilton on my MacBook and WFArchiver by Gary Funk on a Raspberry Pi 3b. Both are excellent for what I need to do. And both authors are WeatherFlow Field-Testers.
You have the choice of changing your network by changing the subnet to a /23 or changing the Wi-Fi router to a Bridge.
Is there a reason you have the two segregated?
I’ll set up a Sky (only) to a location without RPi or PC in the local wifi. Is there any other software I could use to read the data in another location similar to cronweatherflow ? I like WD but would only be logging wind, solar and rain. I’m also not sure WD would work without the Air (no pressure value).
I think you need a hub within RF range of the Sky, as the hub is what sends the data…
Yes, I will have one Sky and one Hub in location A and would like to log data in location B. I could probably do it with weatherdisplay but would like to avoid having a PC for this. WD is able to take data locally (within same network where Hub is) or remotely. It reads from the WF’s server I guess.
You can read from location B… as long as B has a HUB and it’s talking to the WF servers.
I can imagine different scenario but all need coding skills. As you pointed out, Sky and Hub need to be used together as the Sky can not communicate to something else. Plus the hub pre processes data and you would loose all the benefit of it if it were direct communication with the Sky.
you use some UDP package grabber and store locally to a database that you push or pull to another server but you don’t have realtime
you use an UDP grabbing package and push it to a remote database (sql allows to store remotely even 10k miles away)
Some here on forum posted code on how to grab the UDP packages but from there you need to add whatever system you would like to achieve your goal. But in any case you will need a device (PI or even an small Arduino thing cold to it I think) to grab the data and push or pull the data across
the only other option is to go grab the data again from WeatherFlow servers via the API (links on in top menu)
If a MQTT (see WeatherFlow UDP listener and MQTT publisher utility) is uses the time laps is so small, it doesn’t matter in the case of those weather data.
A VPN connection as a main part of a solution in between (a third option). But again, you have to be skilled to set one up and will have to use additional hardware.
A VPN will probably not pass UDP broadcasts, if that’s what is being suggested…
Thank you @eric and @dsfg for suggestions.
I will look into the API option. I have another setup with Hub, Sky and Air +RPi (with double wifi…, weewx) and works great. Here in this new setup I will not have the Air unit and would like to avoid another RPi and just take data from home location.
I’m not a rookie in the linux world but a complete rookie in this new world of IFTTT and other web services…
It depends on the setup and the VPN-solution. If the only use case is to transfer the WF UDP data, there are solutions but, as I said, those a not for beginners.
Still not certain what you’re trying to accomplish. Draw us a picture please.
- do you want to ‘combine’ two stations into a unified view of ‘two’ sites ?
- do you want to have two sites, but just one computer processing the data ?
- do you want something else ?
- do you want all this magic happening ‘with’ or ‘without’ use of the WF servers ?
My UDP listener and @vreihen’s driver for weewx can process just about any UDP they can hear, and feed influxdb or MQTT or weewx (sqlite3 or mariadb etc.) just fine if you can get the packets to the computer doing the listening.
But the UDP is a broadcast, so it’s not routable in general. Those messages are going to stop at the first router.
You could definitely grab multiple stations by querying the WF servers with websockets, but that is not “reading hub data from a different subnet”. It’s not even “reading hub data” really. It’s reading the very processed stuff WF saves ‘based on’ hub data.
What @vreihen and I do is read the raw data off the hub and not need (or want) anything from the WF data at all. The other local solutions basically take the same approach.
So it really comes down to what problem you’re trying to solve. Again, draw a quick picture or something. If you need a free site online draw.io is pretty easy to use to generate a quick picture.
My original post was indeed referring to reading from a subnet in the home network but now I have a slightly different situation.
This is exactly what I want to do:
… and a scheme:
Thank you for your patience - I’m not a native English speaker and sometimes have difficulties to express my thoughts in a clear way.
I’d like to grab the Sky’s data which is already in the WF cloud (“blue web page with realtime update”) and store it in my RPi at home. I’d like to do it near real-time (e.g. once per minute).
Your English is excellent.
Sounds like the websockets interface. I think the WeatherFlow PiConsole works this way if I understand things. That would give you a nice display at home too. I don’t remember if this software saves data locally or not.
There are likely other packages out there too that people have written. Hopefully some reply too.
I might add the ‘store it locally’ can be done in a lot of ways. You could save to influxdb and display to grafana. You could use MQTT. Lots of possibilities depending on what complexity you are ok with.
I found my own way using REST. It’s very easy in fact… I have a bash/python script that takes data every minute -all I needed!