This is interesting
Some may have already done the math, but…
UDP packets per 24 hour period with one Hub, one Sky and one Air.
| Packet Type | Packets |
|---|---|
| Hub Status | 14,400 |
| Device status | 2,880 |
| Air observation | 1,440 |
| Sky observation | 1,440 |
| Rapid wind | 28,800 |
| Total | 48,960 |
This does not take into account rain, lightning and any debug data.
I’m curious, how did you count those and and where is the documentation if any on what the hub sends when to whom and how?
I used an abacus.
Seriously, I captured all the data stored it in a SQL database.
Here is the answer.
Hub Status is transmitted every 10 seconds.
Device Status and Observation is transmitted every 60 seconds.
Rapid Wind is transmitted every three seconds.
The REST API, web socket and UDP specs are here:
Thanks. You used weewx to capture and store in database? Or some other method (eager student here). Seems like a lot of data to be broadcasting on a LAN. Odd choice. A configurable target might have been desirable (not to Weatherflow devs). Probably deemed not a hug issue or traffic volume – not like streaming a security camera 
– but still, can’t say unnecessary broadcasts strike me as great planning.
I use WFArchiver. It records ALL UDP data sent by the Hub.
It is a lot of data but that’s just a small part of the data that the Hub actually generates.
Thanks for that. Looks like you wrote WFArchiver (in javascript). Curious what you think of weewx? It seems to offer a web interface for visualizing and navigating data.
Also I’m curious how you know this: just a small part of the data that the Hub actually generates.
What more data does the hub send to weatherflow.com?
Yes, I am the author. At the time I wrote it there was no other application to capture and store the data from the station Hub.
Besides the UDP data that is broadcast there is MQTT data the that is sent to WeatherFow. That more than doubled the UDP data. Then there is calibration data and at times, debug data.
As for weewx, I have not used it
Well thanks for writing and sharing it! Community is always great. Is there a spec for the MQTT data the hub sends to weatherflow. Interestingly, from a gateway that could all be sniffed too I imagine …
I plan on trying weewx. Given there’s a weatherflow driver for it:
when time permits. May try to mount Sky properly this weekend.
WeatherFlow has not published any data on MQTT from the Hub.
Rapid_wind is every three seconds in non-power-save mode, and 15 seconds(?) in power-save mode IIRC. (Davis LOOP packets are every 2.5 seconds, which is how I remember WF rapid_wind being 3 seconds.)
As an eager student, you may want to install wireshark (free software) and see all of the broadcast/multicast packets floating around from consumer devices (besides the ARP packets sent to map MAC to IP addresses every time that two devices want to communicate). WF’s 23 multicast packets per minute (if my math is correct) are a drop in the proverbial bucket compared with the frequent mDNS announcements made by most consumer devices like idle Apple TVs, Chromecasts, and Fire sticks.
Rumor has it that the guy who wrote that driver is a regular participant here… 
I should have checked my math. And I should have been sleeping.
Maybe a stupid question i thougt the hub sends data to wunderground. How is this done? Not by ftp i think and the hub hasnt a webserver too as far as i know. Are the values sent by the WF servers ? I almost should think it should be possible tot het the data by a simple wget
If this jas been asked before i m sorry thanks.
-Ron
You’d have to run a sniffer on the wire(less) to get any data the hub transmits to anywhere…
But I’m guessing (guessing…) that the heavy lifting is done server-side by WF servers after the data is received there. That’s the case with IFTTT if I recall correctly.
It wouldn’t make any sense to build in a third-party upload capability in a bunch of distributed hub devices that could break immediately if a downstream unaffiliated company changed their API or shut their services off. WF seems to want all integrations they support to flow from their servers as an intermediary.
Thanks for this I couldnt find anything by packet sniffing except the upd packets from port 50222 and a lot of traffic to the wf servers. So I let it go
the link to WU is via the WF servers. The hub ony sends data to the WF servers and broadcasts locally via UDP so we can grab it, that’s about what the hub does regarding sending data.