Thanks for your quick response. These are helpful thoughts. I got 4.0.0b5 sorted with your help.
I did have an existing v3 installation. I wiped that out and started over with a weewx user and group and a home directory just as you said. It took a bit to get everything in the right place and working. Mostly permissions issues.
I installed on an existing Fedora 31 system that I use to serve several other httpd projects. It’s an 86_64 system. My several pi’s are already busy doing other IOT things. So getting it running on the Fedora system might reveal some other issues over time. It’s time to move to python3 in any case. It’s the only system I expose to the internet because it has robust security features. I used the tar.gz install method with setup.py. I think it probably errored on my earlier attempt and I didn’t notice. This time the egg file was installed OK and it’s working.
I manually installed your version of weatherflowudp for Python3 and it seems to be working on 3.7.5 even though I don’t have the WF hardware yet, It is monitoring the UDP broadcast and accepted all the settings from weewx.conf OK. It should work when I edit the settings with HW numbers. Nice work on keeping weewx moving forward.
So can i assume windSpeed is actually wind gust as its the latest every 3 seconds rapid wind - in which case anyone know where i can get the average wind speed and map it to an mqtt topic?
Given the 3 second (non-power-save mode) update frequency, I made the assumption that it was a close approximation of the instantaneous wind speed.
If you want to use the averages, they are in the per-minute obs_sky packets (documented in the link above) as ‘wind_lull’, ‘wind_avg’, ‘wind_gust’, and ‘wind_direction’.
The more difficult question is where you are going to stick these values in WeeWX (left side of equals sign):
The default database schema only offers windSpeed and windGust, so you may need to extend the WeeWX database schema (directions at above link) unless you want to give up the 3-second rapid_wind data and stick the obs_sky ‘wind_avg’ into windSpeed. (The Belchertown skin would be quite boring without the 3-second mqtt wind updates, but that’s my use case for mqtt.)
Between the above two links, you should be able to compose a sensor_map for almost any scenario…
Oh, and in case it is confusing, rapid_wind was named by WF because the packets are sent rapidly (every 3 seconds). The name has no relation to what the data inside those packets reflects…
No, rapid_wind is just the current speed reported every 3 seconds rather than every 60 seconds.
Wind ‘gust’ has a very precise definition that typically includes some minimal duration and offset from previous measurements. There are many such definitions, but one is at Gust | Winds, Turbulence & Air Pressure | Britannica
I have rapid_wind enabled on my WF, so I just use that and weewx seems to do the right thing…
There have been many discussions about whether station-XYZ can capture the windspeed in a microburst that’s even faster than the 3 second rapid_wind measurement, but my recollection is that it cannot. Rapid_wind just reports ‘wind’ more rapidly (often).
Thanks for the replies - it makes sense now - i guess i am looking to get average wind speed - ie to get a graph similar to the WF app wind graph.
At the moment i have a test graph of live wind speed via mqtt (thought it might look nice in the belchertown template) but thought it also needed average speed as a second line.
Nice graph - so in weewx do you know which reading the bottom line is - is there a windAvg reading? Just trying to see which one to output to Mqtt as it does not seem part of the general mqtt list this may now be off topic for this tread though and I can probably get it from the database instead I guess…
Depends on what you have configured ‘to’ graph. If you look at skin.conf you will see the aggregate_type can be min/max/avg. One example is the yearly high/low temperature graph that the Standard skin puts out - example at https://www.skahan.net/weewx/Standard/yearhilow.png
I think we’re way off anything WF related at this point. You should ask any followups in the weewx-users group in Google Groups.
I just got a WeatherFlow to replace my old Acurite earlier this week. I’m really enjoying exploring all of these new integrations I’m discovering every day.
I got Weewx set up with the WF UDP driver, and I’m sure I’ve got a lot more to learn about customizing. But in the meantime, I would like to set up a new database for various other reasons.
I have a growing DB of personal sensor data. I have all of my 5 minute archives from WeatherUnderground going back over 2 years. I want to now add this PWS as a new table. I also use the same node.js process running on my raspberry pi to send the data from all the sensors to Graphite.
But I can’t seem to get both weewx and my test node app (simply create a dgram socket, bind, and log to console) to run at the same time. Even if I set the “share_port” setting to true, it still throws the “address in use” error.
Any ideas? I’m really interested in the UDP dgrams. When I first saw the amount of raw data that thing spits out (and I don’t have to poll a remote server!) I was definitely data geeking.
If you’re running weewx, you should ideally use a secondary db for your other sensors if you want to keep everything as simple as possible. There are lots of howtos in the weewx google group.
I have an example at https://github.com/vinceskahan/weewx-minimal-secondary-db if you want a trivial example that cooks up a db and stores the seconds since epoch in a new field. You could use that as a starting point for rolling your own extension and custom db to do whatever you want.
Ok great, thanks!
For as many times I’ve told my kids how sharing is important and goes both ways…
Edit:
So now I get to move past step 1 because that was absolutely the issue! In case anyone else is new to UDP, here was the money shot that did the trick:
const server = dgram.createSocket({ type: 'udp4', reuseAddr: true });
Hi there! So I’ve walked through the process of installing WeeWx on Ubuntu and I believe I have the UDP driver for WeatherFlow setup correctly.
I’ve enabled verbose logging but I never see any of my sensors come through. All I see is “weatherflowudp: MainThread: Listening for UDP broadcasts to IP address on port 50222, with timeout 90 and share_socket False…”
After that nothing gets logged. No timeout errors or anything like that. What am I missing?
The first troubleshooting step is to confirm that your WF Hub and WeeWX server are on the same IP subnet or VLAN, since UDP broadcasts cannot cross routers between subnets.
Ubuntu’s included Python is a stable/sane version, and you should be able to enable share_socket in case you also want to run one of the other third-party WF apps side-by-side on the same system.
Out of curiosity, is your Hub uploading to the WF servers and visible on the SmartWeather web site? You would be surprised at how many owners have stopped their WF install early, never setting up the Hub’s wifi and leaving themselves with only Bluetooth access to the Hub from the smartphone app…
netcat will return the first one it hears and you’ll be able to see the content since it’s pretty obvious JSON. tcpdump will just show you that it’s receiving stuff.
root@pi3jr-wifi:/var/www/html# netcat -ul 50222
{"serial_number":"SK-00015850","type":"rapid_wind","hub_sn":"HB-00010412","ob":[1586624164,0.89,230]}
root@pi3jr-wifi:/var/www/html# tcpdump -n udp port 50222
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:56:09.119651 IP 192.168.1.189.50222 > 255.255.255.255.50222: UDP, length 106
08:56:09.121018 IP 192.168.1.189.50222 > 255.255.255.255.50222: UDP, length 99
08:56:10.147552 IP 192.168.1.151.50222 > 255.255.255.255.50222: UDP, length 99
08:56:11.476180 IP 192.168.1.151.50222 > 255.255.255.255.50222: UDP, length 101
^C
Yes, there are Python 3.x issues. Please send me an email at the address in the readme file, and I’ll send you the pre-release version with WeeWX 4.x and Python 3.x support…
