I do not claim to be a programmer or have more than a limited grasp of Python. My thought was to go with code re-use, and write a simple program as a replacement for rtl_433 to capture the WeatherFlow (WF) UDP packets and pipe them into the existing weewx-sdr stuff. WF's JSON isn't much different than rtl_433's JSON packets, and the sensor-mapping code is already there in the weewx-sdr setup that would also apply to the WF packets. Hence, floating the idea of making the current weewx-sdr stuff into a weewx-broadcast station type, and letting the user set their own external program to feed it the broadcast packets regardless if they came in from an SDR, over the ethernet cable, or were picked off off of the air via Bluetooth LE.
The holy grail (a single weewx-json driver) seems like it would quickly morph back into another weewx-sdr, since one thing that is certain in the software universe is that vendors will find ways to implement non-standard standards. WF chose to send their weather observations as a list in their JSON "obs" field, so getting the temperature requires parsing the list and not just saying something like temperature=pkt['temperature'] or however the Python syntax goes. All of their station status packets are "proper" JSON, though. I can see other stations deciding to do similar weird things in the future. Doing a weewx-wu seems like a good idea, since more than one station type sends that packet format. Since everyone else here has a gazillion times more familiarity with the weewx layout, Python, and what the pain points are with other vendors' stations, I'll pass on making a recommendation for how best to proceed. I'm also not opposed to finishing my WF-specific station code that's about 50% complete, but would be hesitant to encourage others to use that spaghetti knowing how little I know about Python and how ugly the code will be.....
