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