Nice - I have HA and my mqtt/telegraf/influxdb/grafana stuff in Docker already. Super fast.
As you’re likely aware from weewx-development forums, I got weewx v4 running in simulator mode under Docker vs. python3 current debian+ubuntu, so it should be straightforward to try your driver under Docker versus those. Adding in an older version that uses python2 shouldn’t be a big deal. Let me see how bored I am tomorrow as the lockdown continues here too.
See GitHub - vinceskahan/weewx-docker: weewx in docker for a variety of os and build the debian10 python2 setup.py variant to get to a running simulator weewx+nginx.
Then ‘docker exec -it containername bash’ to log into the running container interactively. wget and wee_config etc. to install/run your driver under python2 in deb10 using weewx v4.
Email if I lost you there anywhere.
Thanks! I’ll give it a shot once I get the HA emergency stabilized…
Hi all,
After a week or so of trying to get WeeWx setup and working with my Tempest using the WeatherFlow-UDP driver, I just wanted to provide a few tips that might help folks.
1.) The instruction for the WeatherFlow-udp driver leaves out something important and is not very obvious (to me at least). In the instructions, it states to copy the weatherflowudp.py script into …/weewx/bin/users and that’s it. Unfortunately there’s an important step that requires copying the contents of the edits in your weatheiflowudp.py into the actual weewx.conf file located in …/weewx/. My weewx.conf file looks like this (in the snippet below “00012345” needs to be replaced with your Station ID number):
##############################################################################
[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.ST-00012345.obs_st
outHumidity = relative_humidity.ST-0012345.obs_st
pressure = station_pressure.ST-0012345.obs_st
lightning_strikes = lightning_strike_count.ST-0012345.obs_st
# avg_distance = lightning_strike_avg_distance.ST-0012345.obs_st
outTempBatteryStatus = battery.ST-0012345.obs_st
windSpeed = wind_speed.ST-0012345.rapid_wind
windDir = wind_direction.ST-0012345.rapid_wind
windGust = wind_gust.ST-0012345.obs_st
# lux = illuminance.ST-0012345.obs_st
UV = uv.ST-0012345.obs_st
rain = rain_accumulated.ST-00012345.obs_st
windBatteryStatus = battery.ST-0012345.obs_st
radiation = solar_radiation.ST-0012345.obs_st
# lightningYYY = distance.ST-0012345.evt_strike
# lightningZZZ = energy.ST-0012345.evt_strike
##############################################################################
Also, I’m using a Mac so I uncommented the “udp_address = 0.0.0.0” line. If you’re using a pi or something else, I’ve heard the standard "udp_address = " works fine.
2.) This link ( WeatherFlow Tempest API Websocket Reference) helped me track down how to get weewx and the WeatherFlow driver to read Wind Gust. Unlike wind and wind direction that uses the “rapid_wind” call, wind gust uses “obs_st”. You can see this in the snippet above. Wind and wind direction end with .rapid_wind while wind gust ends with .obs_st.
3.) If you’re trying to get your Tempest data to update data to Weather Underground faster than the standard 15 minutes, you can use the rapid fire option within the Weather Underground portion of your weewx.conf file. The confusing part of this section is that it calls for your “password” for Weather Underground. This isn’t your actual password and is instead is your device “Key” in Weather Underground. The station ID in Weather Underground is as you would expect.
These three tips helped me get things going on my system. I am now getting my Tempest data uploaded to Weather Underground accurately with all categories and doing it every 2.5 seconds (which is the default for rapid fire). Our Tempest stations appear to be able to handle this interval which is pretty cool. Anyways, thought I would share and I hope this helps!
To be clear with my needs with weemx, I’m in a Apple HomeKit house and I also have a Homebridge setup that pulls the feed from my weather station on Weather Underground and allows me to interact with it for HomeKit automations. The main purpose for WeeWx for me was to get the intervals for Weather Underground updates to be fast and the rapid fire 2.5 second interval did the trick. I now have up to the second data getting fed into Weather Underground AND my Homebride/Homekit environments. Now, I can use wind speed to turn off/on devices if I need to. Yes, I would be nice if Apple would make this native but for now, this has been quite the great magic triangle.
Geez guys, don’t take a week battling things - use the forum here for the driver or the weewx-user google group to get some help.
FWIW, you might want to reread the readme file. All you do is download the zip file from github and use wee_extension to install it. There is also a sample sensor map link on the readme page, so you’d just need to edit your station id in place of the demo one in the example.
I definitely used this forum and Google groups to try to make sense of it. I also installed using the wee extension command but the full driver and sensor information didn’t populate to my conf file. Regardless, figured it out and also figured out how to add wind gust. It was a good experience but many of the posts weren’t clear on the contents that needed to be in the conf file. All-in-all, everything is working great now!
I actually had to go back and read the “readme” file, to confirm that it was correct!
Installation should be as simple as grabbing a .ZIP download of this
entire project from the GitHub web interface, and then running this
command:wee_extension --install weatherflow-udp-master.zip
Worst case, a manual install is simple enough. At least on my Raspberry Pi,
copy weatherflowudp.py from bin/user to /usr/share/weewx/user/weatherflowudp.py,
and then edit /etc/weewx/weewx.conf and add the new station driver settings
per the info below.
https://github.com/captain-coredump/weatherflow-udp/blob/master/readme
This makes me wonder how many people actually read the “readme” file through to the last paragraph, lines 174-179? I guess that there’s truth to the saying that anyone looking for a career as the least-read author in the world should become a user manual writer. 
On a side note, I spent the weekend updating my “production” WeeWX Raspberry Pi. Went the whole nine yards, Raspios Bullseye, WeeWX from 3.9.1 up to the current 4.5.1, Python2 to Python3, etc. The most time-consuming thing was upgrading the Belchertown skin from an early pre-1.0 beta to the current release. I had made all kinds of hacks/edits to the early beta HTML and CSS to make it display without the station banner stuff on my wall-mounted Fire 10" tablet, and now have it all simplified to a surprisingly-short custom.css file. The jury is still out on the quality of the new Aeris forecast data source over the old DarkSky forecasts.
I did have a crazy thought about adding the WF “better forecast” API as a custom Belchertown skin data source. After remembering that most Belchertown deployments are on public web sites and the WF forecast is only licensed for personal use, I gave up on that crazy idea…
And put in for corporate match too !!!
I would love to setup WeeWX but my pi sits on my default VLAN and the Base Station for the Tempest sits on the IoT VLAN and thus can’t listen to the UDP broadcasts. I setup the port on the switch to also send the IOT VLAN to the PI’s and then setup the PI with VLAN support and mapped an address to it. Was able to ping the pi from both the default VLAN and the IoT VLAN.
But the same issue seems to happen only eth0 listens for the broadcasts. If I could find a way to have the UDP listener map to a interface eth0.vlan12 I may try to setup WeeWX over the Christmas holiday.
Depending on what firewall you have you may have the option to forward a specific broadcast port.
I do this on a pfsense firewall using udpbroadcastrelay to forward just 50222 between my IoT VLAN and where the PI is located.
Cheers
Simon
Out of curiosity, what happens if you set udp_address to be the broadcast address on your IoT subnet? If your IoT subnet is 192.168.12.0/24 for example, try 192.168.12.255 or 192.168.12.0.
Nobody has ever reported issues on Raspberry Pi’s with both ethernet and wifi interfaces in use at the same time, so I’m scratching my head about why it doesn’t work with tagged/untagged VLANs on the same ethernet port since the kernel also treats them as two separate interfaces…
I will have to rebuild the instance this weekend. I have since moved to a Pi 4b with more memory. It will be interesting to try again.
I am running untangle as a firewall, no rules that I know of for broadcast relay and forwarding. I have posted this before on their forums for IoT issues with discovery.
Another thought. Do your switches consider the “default” VLAN to be VLAN 0? If so, how about sending your IoT VLAN to the Pi untagged, and send the “default” VLAN tagged referenced as eth0.0? 
Personally, I would just connect the Pi’s wifi to your IoT wifi network as a second interface, since the WF Hub is already connected to it via wifi…
Yep default VLAN is untagged VLAN 0. Didn’t think about reversing. As for the Wi-Fi that could be a fallback option. I disable Bluetooth and Wi-Fi on all my PI but it may be worth a experiment.
Just created the profiles just need to find time now to configure the Pi, Switch and a few other things. I have 15 to the end of year off so I will make time to do some testing:
FWIW - you might try my UDP listener which I ‘know’ will listen on both interfaces on a ubuntu system because I see double the data to the point where I put in an option to only listen on one interface (actually, one ip address for the box). I’ve tested it in the past and if I run it on a wifi+ethernet pi it seeeeeeems to only listen on one.
Github link is (here). If you run it with weewx make sure to set shared_sockets=true for weewx or stop weewx temporarily.
update - I did ‘not’ try it with multiple VLANs but from a listener perspective that wouldn’t matter. It hears what it hears.
Thanks…I love debugging tools. Can’t wait for my PTO to start so I can dedicate time to this.
If you have a *nix host with an ETH iface AND a WLAN iface on the desired networks, you may wish to investigate this udp replicator.
I’ve not tried it, but considered it when my weewx host had ETH, but no WLAN.
Well I got WeeWX to work with my IoT VLAN and default VLAN on a single port. Default untagged network stayed as it was and the IoT VLAN 12 was enabled on the port. I configured VLAN support on the Pi and set a static for the 192.168.12.250 VLAN adapter on eth0.12. Was able to ping so half way there.
Now the hard part was determining why UDP wasn’t showing up when I configured the weatherfow-udp station driver and ran into two things. One was the address needed to be 0.0.0.0 using 192.168.12.255 didn’t seem to work when I had “log_raw_packets” on. Once I went to 0.0.0.0 configured I was able to see my station packets. I then had to adjust the stanza’s with my station id for the sensor map. I am still going to work on sensor map but this is a great retry of getting this to work on the new Pi. I have a bunch of other customization to do but one step at a time. Thanks everyone for your help.
Great stuff - congratulations. Now set up Belchertown for a really slick looking skin !
