If you are running Python code it is blocking. Meaning it runs code one line and function at a time if you get two packets within .1 ms it is possible a packet may get dropped.
With Node JS I read a packet and one routine saves it to the database while another processes it. Both run at the same time.
it"s possible to receive a hubstatus, device status, skyobs and airobs at the same instant. in this case all right routines did their job in parallel.
That is not correct. The ‘default’ of the python socket library is blocking. It can be set to non-blocking. I just haven’t gotten around to it yet.
It is correct. You are confusing code execution with IO handeling.
Python executes code synchronously where as NodeJS executes code asynchronously . This is the entire reason I switched from Python to NodeJS for this project. Otherwise, I prefer Python for small devices, as most everyone else does.
Not weewx-related, but a status update with some data for my UDP listener…
Putting my python listener which posts to MQTT, read by telegraf and saved to influxdb setup all on one wired ethernet pi3+, is pretty darn close to 100%. In 1000 minutes I missed ‘one’ sky status and ‘five’ hub status messages. All the observations made it to the db. That isn’t too bad. I set the python socket up as non-blocking just in case, which had a tiny effect, but not too much.
I’m going to let it run for a day or two more and then add weewx with the WF driver onto the same pi3+ to try to get to closure on the original question of whether the weewx driver misses anything it’s listening for…
ok @vreihen - I’m calling your driver good (ok, really good). Zero partial archive table records that I was seeing on the previous multi-pi some-wifi setup.
Putting everything on the same wired pi3+ was the ticket. I’m missing perhaps 3-5 hub status messages per day, even with weewx running using the vanilla Standard skin. No observations missed. No air/sky observations missed.
I did ‘not’ rewrite my listener that’s running in parallel on the same pi3+ to be threaded in order to try to split it into listening and processing/saving threads, as it doesn’t seem to be necessary (although I might try someday as a programming exercise). I did change it to open the socket non-blocking for listening, so it should listen a ‘little’ better, but it was pretty darn good before on the faster wired pi3+.
I’m getting my feet wet with this kind of stuff, so I’m doing this poorly.
So far I’ve downloaded the Weewx WF extension and installed it. It says it’s listening for the WF packets, but the html page hasn’t been updated all day.
when I run tail -f /var/log/syslog I don’t see any errors from Weewx.
Just wondering what I might’ve done wrong?
The weewx google group is where you want to ask those kinds of questions…
My recollection of the WF driver is that you need to hand-edit your weewx.conf to define the sensors and the sensor serial numbers. See the top of the driver file for a nice readme.
You could also run the daemon interactively and see each LOOP packet go by in realtime. Again, the weewx group and their docs+wiki is where to ask that kind of stuff.
Followup - just once here 
I did a weewx install on a clean pi-zero and the driver seems to work ok, with some caveats…
Couple other things…
I tried to do this in a Vagrant VM and got nothing because I have a NAT’d VM and the broadcasts aren’t making it through the NAT to the VirtualBox local LAN the VM runs on. I’m guessing a bridged VM would’ve worked (untested)
you might want to do a quick test on your weewx system to see if it’s hearing the UDP broadcasts. Here’s a tiny python script that will print out what it hears from the WF broadcasts…
#!/usr/bin/python
#
# quick listener script to verify you can hear the WF UDP broadcasts
#
# credits:
# - lightly edited from a online doc I found someplace, but lost the original URL for,
# so unfortunately I can't credit the original author who did the heavy lifting. Sorry.
#
MYPORT = 50222
import sys, time
from socket import *
s = socket(AF_INET, SOCK_DGRAM)
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
s.bind(('', MYPORT))
while 1:
m=s.recvfrom(1024)
print m[0]
Set “log_raw_packets = True” in the weatherflow-udp driver section of your weewx.conf file and restart the software. Assuming that you have a Sky paired with your Hub, you should start seeing rapid_wind packets every 3 seconds (or 15 seconds in Sky power-save mode).
log_raw_packets = False
Enable writing all raw UDP packets received to syslog,
(or wherever weewx is configured to send log info). Will
fill up your logs pretty quickly, so only use it as
a debugging tool or to identify sensors.
If you see the packets coming in, check your sensor_map settings in weewx.conf. If you then run weewx interactively on the console as @vinceskahan suggested, you should see the LOOP packets as they are received.
If the LOOP packets are coming in and being processed, weewx should update the web page every 5 minutes (assuming the HTML file target directory is configured correctly).
Before I forget, disable log_raw_packets when completed, to save the log space (and write cycles if you’re running on a Raspberry Pi with flash storage)!
FWIW, I do have auto-config with building a basic sensor map on my to-do list as the next version…
Thanks! I didn’t realize there was a Google Groups for this. I’ll check it out!
Wonderful. This got me up and going – now the HTML page is displaying the correct values from both the AIR and SKY.
My issue was that I didn’t know I had to replace the fake SNs in the weewx.conf file with my own actual SNs.
The log_raw_packets option really helped me out there.
Glad to hear that everything is now working!
I’d like to take credit for the log_raw_packets idea, but both that and the sensor_map concept were inspired by weewx contributor Matthew Wall’s SDR station driver. For those not familiar with it, his SDR driver uses rtl_433 and a cheap < $20 USB software-defined radio dongle to pick wireless packets off the air between numerous consumer weather station brands and their consoles. Thanks to whoever on the dream team at WeatherFlow came up with the UDP broadcast idea, WF owners do not have to resort to workarounds like this or hacks like inserting a packet sniffer inline between a weather station bridge to pick off cloud-bound observation packets…
I am trying to set WF up in weewx - i have edited the conf file to log so i can see the raw packets but i get is:
Jan 28 16:01:44 weewx weewx[28519]: weatherflowudp: MainThread: raw packet: {‘firmware_revision’: 22, $
Not sure how to get the info i need for the sensor map.
My conf is:
station_type = WeatherFlowUDP
[WeatherFlowUDP]
driver = user.weatherflowudp
log_raw_packets = True
# udp_address =
udp_address = 0.0.0.0
# udp_address = 255.255.255.255
udp_port = 50222
udp_timeout = 90
share_socket = True
Any help would be great.
Andy
Hello Andy
did you define the sensors ??
here is my config
[WeatherFlowUDP]
driver = user.weatherflowudp
log_raw_packets = False
udp_address = <broadcast>
# udp_address = 0.0.0.0
# udp_address = 255.255.255.255
udp_port = 50222
udp_timeout = 90
[[sensor_map]]
outTemp = air_temperature.AR-00000xxx.obs_air
outTemp2 = air_temperature.AR-0000xxxx.obs_air
outHumidity = relative_humidity.AR-00000xxx.obs_air
outHumidity2 = relative_humidity.AR-0000xxxx.obs_air
pressure = station_pressure.AR-00000xxx.obs_air
lightning_strikes = lightning_strike_count.AR-0000xxxx.obs_air
avg_distance = lightning_strike_avg_distance.AR-0000xxxx.obs_air
outTempBatteryStatus = battery.AR-00000xxx.obs_air
windSpeed = wind_speed.SK-0000xxxx.rapid_wind
windDir = wind_direction.SK-0000xxxx.rapid_wind
lux = illuminance.SK-0000xxxx.obs_sky
UV = uv.SK-0000xxxx.obs_sky
rain = rain_accumulated.SK-0000xxxx.obs_sky
windBatteryStatus = battery.SK-0000xxxx.obs_sky
radiation = solar_radiation.SK-0000xxxx.obs_sky
lightningYYY = distance.AR-00000xxx.evt_strike
lightningZZZ = energy.AR-00000xxx.evt_strike
change the xx with your numbers and or add/remove what is not needed
Fab thanks - just found the sensors and now running thanks for the reply…
Andy
Note to the idiot programmer who wrote that code - put in a syslog alert and graceful exit if the sensor_map is not defined…
Yeah. Programmers can’t think of everything.
I’ve installed the weewx for a test and works fine. I wonder how to present the lightning data (count, distance, etc.) in the html page.
You need to extend the database schema, as explained starting at “Configuration” on this page:
https://github.com/weewx/weewx/wiki/as3935#configuration
No need to install the driver for that piece of hardware. The WF driver will populate the fields if you un-comment the two lines in the sample sensor_map and edit for your Air’s device name. After that, you will need to edit the HTML template to display/graph the data from the new database fields.
As the todo file notes, I have not personally set this up on my own WeeWX server. If you do get it set up, please let me know how well it works!
Sure…but I’d suggest an alternate approach that uses some unused elements already in the schema, rather than customizing the schema and altering the underlying db setup. More user-friendly especially for new users.
I took that approach re: capturing battery voltages, although I needed to tweak the cheetah skins a little to get them displayed on the resulting web page too. That’s far easier than messing with the db.
Lots of examples on the weewx google group if you search there, and asking there would be your best bet if you get stuck. ‘Lots’ of experienced users there who have been there done that before.
Default schema is in schemas.py if you’re looking for the elements. I guess I’d suggest using soilMoist1(through soilMoist4) if you need 4 elements that almost nobody uses. @vreihen’s driver is pretty slick in that you can map anything to anything in the weewx.conf file, as long as you tweak the skins (which is easy) to display the values when the html files generate periodically. Very flexible.
My sensor map takes that approach for battery voltages.
I might add that I did some crimes against weewx in the mapping below, specifically by using the battery status elements to store floats. The default skin uses Davis mappings where battery status is a boolean (1=bad, 0=ok), so there is a little patching of the skin file to get the battery voltages to display. PM me if you want a patch for weewx 3.9.1 that takes care of this for you.
[WeatherFlowUDP]
driver = user.weatherflowudp
log_raw_packets = False
udp_address = <broadcast>
# udp_address = 0.0.0.0
# udp_address = 255.255.255.255
udp_port = 50222
udp_timeout = 90
share_socket = True
[[sensor_map]]
outTemp = air_temperature.AR-00013349.obs_air
outHumidity = relative_humidity.AR-00013349.obs_air
pressure = station_pressure.AR-00013349.obs_air
outTempBatteryStatus = battery.AR-00013349.obs_air
windSpeed = wind_speed.SK-00013695.rapid_wind
windDir = wind_direction.SK-00013695.rapid_wind
rain = rain_accumulated.SK-00013695.obs_sky
windBatteryStatus = battery.SK-00013695.obs_sky
radiation = solar_radiation.SK-00013695.obs_sky
UV = uv.SK-00013695.obs_sky
#--- These have no default elements in the weewx schema, so if you don't want to extend the
#--- schema, you'd need to map these to unused elements in the db and tweak the skins to match.
#-- See the weewx user and customization guides and the weewx-users google group for help.
#--
#--- hint: soilMoist1, soilMoist2, soilMoist3, soilMoist4 are generally unused
#---
#--- (reminder, you'll need to tweak your skin .html.tmpl files to match this custom mapping)
#---
# soilMoist1 = lightning_strike_count.AR-00013349.obs_air
# soilMoist2 = lightning_strike_avg_distance.AR-00013349.obs_air
# soilMoist3 = illuminance.SK-00013695.obs_sky
#--- my serial numbers just so I don't need to always look them up
## SK-00013695 AR-00013349 HB-00010412