In case anyone is looking for it, here is my weewx UDP station driver:
A lot of the comments/docs are from mwall’s SDR driver, the syntax of which I am ultimately hoping to replicate to support multiple Air + Sky sensors on the same Hub. For now, it ignores sensor addresses and imports whatever it sees as if it is coming from one sensor…
Very nice!
Looking fwd to the updates 
(Can one of the moderators please move this thread over to the Third-Party Integrations section? Thanks!)
Just wanted to post an update that I spent a good part of the weekend completing the sensor-mapping stuff (borrowed from mwall’s weewx-sdr driver) that I’ve wanted to add since day one. A good deal of the old, cobbled-together code was scrapped in the process, enough where I finally feel comfortable calling it a v1.0 driver. Basically, it allows you to pass every value from every received UDP packet up to weewx as a LOOP packet, where they are mapped to weewx’s database field name values in the weewx.conf config file.
Since there was such a radical code change, I’m running it on my test weewx instance until later this week before I post it to GitHub as the “master” branch. I want to be sure that it is just as stable as the current 0.3 version before I release it into the wild…
I have just created a master branch and committed v1.00 to GitHub:
https://github.com/captain-coredump/weatherflow-udp
Please recycle the electrons that make up previous versions responsibly, per local laws. 
The readme file explains the sensor_map feature and configuration. Without a proper sensor_map in weewx.conf, this driver will not log ANY data! The naming syntax was borrowed from Matthew Wall’s weewx-SDR driver. I enjoyed the hours that I spent writing the readme file to explain everything, and hope that you enjoy reading it just as much when setting up the new/final version.
Before you curse me out for the added complexity of the sensor_map feature, let me explain the rationale. I have an Air unit in my basement, logging the temperature/humidity into weewx as indoor sensors to watch the furnace for failure. I also have an Air located outdoors, logging temperature/humidity/barometer/lightning as outdoor sensors for weather purposes. Using the sensor_map feature, I can decide which sensor’s data gets stored in weewx…with granularity down to the individual sensor. In addition, I can choose to ignore certain sensors, like the lightning sensor in the basement. Not sold yet? Rumor has it that making a $7.95 Arduino NodeMCU or ESP8266 send UDP packets for things like water levels and soil moisture is a trivial thing, and it would probably take less than a dozen new lines of code in this driver to bring all kinds of additional sensors into weewx beyond what are available in the Air (and soon the Sky) today.
I have been running this driver in a test weewx instance as it was developed. Other than the socket timeout dump when my Hub was doing an upgrade (now handled properly), it has been running for a week in final form without any observed issues.
My usual disclaimer applies. I am not a programmer by trade, and did not sleep in a Holiday Inn Express last night. Please let me know via GitHub or here if you find any bugs. Also, if someone else can try installing it and let me know if it works for them, I’d be extremely grateful…
ok, installed a second weewx on a spare PI. It is running now on a standard skin with no other extensions, not sending data anywhere. Pure local, it is receiving data from my Air module.
Just wondering, will the extra non usual data like battery level etc be displayed or do we need to recode the skin for that ?
Didn’t dig into this yet, so consider that the lazy coder question
Also no sky data for me at present time, can’t test that part for you.
Only thing I would change is the name of the zip, it is called master.zip and if every module writer calls it the same, it’ll be hard to know what module you’re looking for. Maybe give it a more explicit name ??
As far as I know, every value is being passed up to weewx. What you do with it is between you, weewx, and the sensor_map config. My test was to make a sensor_map entry that put my Air’s battery voltage (3.41) into the indoor temperature (inTemp) field in weewx. The result was that it suddenly dropped to near freezing (3.4 C) in my house when the next 5-minute weewx archive cycle ran. When I find some free time, I do intend to graph battery voltages from all sensors in weewx for my own amusement.
Note that the “todo” file lists figuring out what to do with the lightning sensor data as my next step. I have been following the lead of other weewx packages with everything that I have done, and think that Matthew Wall’s lightning sensor setup will be how I tackle this:
https://github.com/weewx/weewx/wiki/as3935
Unfortunately, that is a function of GitHub. They tie the download name to the branch name, and “master” is the convention used by everyone for their production-ready code…
If anyone cares, I just committed v1.01 followed by v1.02 to GitHub. There were no bug fixes in either version, so don’t feel obligated to upgrade.
v1.01 fixes an oversight that I discovered when double-checking my work following my answer to @eric above. Somebody who shall remain nameless (@vreihen!) forgot to pass the device_status and hub_status packets up to weewx. Feel free to log your hub’s uptime or radio signal RSSI now!
v1.02 adds a user-defined protocol extension, so that someone who wants to create an army of evil IoT sensors around their house can store the info into weewx using UDP broadcasts. Probably of no use to anyone but the Arduino sketch that I have open in another window right now, but there’s info in the readme file…
upgraded to 1.02 and running. No hiccups since yesterday …
have pushed the upgrade to my weewx pi … all is running fine
Thanks for the nice work
@vreihen
As I now have the sky I’ve more data coming via the driver though I wonder
Can it be the UV data is 1 digit with nothing after the “,” ?
For me it is 0 or 1 or 2 but never the detaiied data like 0.4 I had this morning.
I looked in meteotemplate and the stream coming in shows just 1 and not for ex 1.2 though WF shows 1.2 and when it is 0.7 I get 0.0 on meteotemplate current bloc.
Can you see if this is related to the weewx driver ? Locally it does show 0.7 but when send to the site it is 0 …
thanks
It going to depend on how the value is stored. The Sky has UV as a decimal. If the application is storing is as an integer then it’s going to round the number to 0, 1, 2, 3…
It is being stored in weewx correctly:
I assume that you are using Matthew Wall’s weewx MeteoTemplate uploader extension. Looking at his current code, it appears that he is formatting UV with zero decimal digits. Feel free to edit /usr/share/weewx/user/meteotemplate.py and make the change near line 215 and let me know if it fixes the problem:
‘UV’: (‘UV’, 0),
-to-
‘UV’: (‘UV’, 1),
If that doesn’t solve the problem, I’ll dig deeper into a possible I18N problem with locales that use commas in place of decimal points…
that did the trick 
I installed weewx with the WeatherFlow extension today on an old Mac Mini that I had laying around, and it’s working great. The WeatherFlow weewx extension wasn’t hard to configure, and I did have to use the udp_address value of ‘0.0.0.0’ on the Mac, as directed.
Thanks for providing this!
I have just committed updated driver v1.03 to GitHub:
https://github.com/captain-coredump/weatherflow-udp
One of the two changes in this revision is a more graceful handling of a specific packet corruption that caused weewx to exit. Although it has only been reported happening once, I strongly urge everyone to update as a precaution.
The other change added a weewx.conf option share_socket, with the default False. Driver v1.02 and earlier were greedy, and did not share their UDP socket with other apps running on the same system. If you are running another app listening for WeatherFlow UDP packets on the same box as weewx (like a certain home automation package), feel free to set share_socket = True. I left the default as False, to match v1.02’s behavior until I get some feedback that none of the major Python server platforms have issues with sharing the socket.
As always, there are details and credits in the readme and changelog files…
Little question
to upgrade the driver, just run install again with the new package ? Or uninstall old and install new. One of those questions I never digged …
might be handy to know
thanks
I’m embarrassed to say that I don’t know! I would suggest backing up weewx.conf before running wee_extension, in case it tries to blindly apply the config changes already in weewx.conf. I used the “worst case” procedure from the readme file, since I did my edits on the running file in the live program tree.
I did make a note in the todo file that I plan to implement the code so that wee_config can ask a few questions and build a basic sensor map in weewx.conf, which will probably be the next release (v1.10) barring any other bug discoveries. This should make it easier for everyone to do the install and updates…
ok, went to test
just run the installer again and it’ll override the files but not the settings in weewx.conf, just did it and it didn’t die 
thanks for the update
I just got around to updating to the new WeatherFlow UDP driver. I had one instance where weewx quit unexpectedly, but I don’t know what the issue was. I caught it quickly and restarted it, and all was well.
I’m running the home automation package that listens to the same socket, so I added the share_socket = True value to my weewx.conf file. So for, all is good, and I’l watch it and report back if anything interesting occurs.
Thanks!