WeeWX UDP driver for WeatherFlow station

your sensor map isn’t correct… you are mixing Tempest with air and sky …

here is mine, you need to set the correct number for you but this is the structure expected for Tempest

You might have other errors but already correct this

         outTemp = air_temperature.ST-00000xxx.obs_st
        #       outTemp2 = air_temperature.ST-00000xxx.obs_st
        outHumidity = relative_humidity.ST-00000xxx.obs_st
        #       outHumidity2 = relative_humidity.ST-00000xxx.obs_st
        pressure = station_pressure.ST-00000xxx.obs_st
        lightning_strikes = lightning_strike_count.ST-00000xxx.obs_st
        avg_distance = lightning_strike_avg_distance.ST-00000xxx.obs_st
        outTempBatteryStatus = battery.ST-00000xxx.obs_st
        windSpeed = wind_speed.ST-00000xxx.rapid_wind
        windDir = wind_direction.ST-00000xxx.rapid_wind
        lux = illuminance.ST-00000xxx.obs_st
        UV = uv.ST-00000xxx.obs_st
        rain = rain_accumulated.ST-00000xxx.obs_st
        windBatteryStatus = battery.ST-00000xxx.obs_st
        radiation = solar_radiation.ST-00000xxx.obs_st
        #lightningYYY = distance.ST-00000xxx.evt_strike
        #lightningZZZ = energy.ST-00000xxx.evt_strike

Thanks - I’ll fix my sensor map for sure, didn’t know what the Tempest values were, so that’s helpful and def saves me some time, so I appreciate it. But my problem is something else. Even when I turn on Log Raw Packets, I get the Errno 49 Can’t assign requested address problem.

this is most probably a problem with your network interface settings and not weewx …

It is most likely a problem with text indenting in weewx.conf, or perhaps the entire [WeatherFlowUDP] not being at the end of the file and mixed somewhere in the middle.

There is a sample Tempest sensor_map in Github:

I didn’t see a mention of what platform you are trying to run WeeWX on, but this description of udp_address from the readme file may be useful if it isn’t a Raspberry Pi or Debian-derived Linux:

udp_address = <broadcast>
# udp_address = 0.0.0.0
# udp_address = 255.255.255.255

This is the broadcast address that we should be listening
on for packets.  If the driver throws an error on start,
try one of the other commented-out options (in order).
This seems to be platform-specific.  All three work on
Debian Linux and my Raspberry Pi, but only 0.0.0.0 works
on my Macbook running OS-X or MacOS.  Don't ask about
Windows, since I don't have a test platform to see
if it will even work.

I don’t know how tolerant Linux Python is to files edited with a Windows text editor, but I can’t count how many times I’ve seen Windows’ different line terminators have invisibly messed up text files on Unix/Linux over the years.

Please let us know if this helps…

naaaah - weewx doesn’t care about indenting in weewx.conf, nor does it care about where in the file the station’s block is.

I don’t recall if it cares about Windows vs. unix end of line, but running weewx.conf through ‘dos2unix’ might be worth trying. I’ve seen that kind of craziness elsewhere too many times.

The posted weewx.conf looks ok to me at quick glance, once they substitute in the right ID for their tempest etc. of course. Perhaps try running my udp listener in --raw --decoded mode to see what’s going over the wire(less). If my listener also doesn’t work, it’s something in the pi setup.

Wow, I’m dumb, thanks for that @vreihen. Right in the ReadMe, of course. I’m using MacOS so needed to set udp_address = 0.0.0.0 not broadcast. Thanks so much!! (facepalm)

1 Like

Funny story. Back when I was in college and dinosaurs roamed the Earth, professors from the Technical Writing department made several pitches to have me change majors from Computer Science (CS) to Technical Writing. One of my English professors tipped them off that I was a top-tier CS major who could also write well, and apparently finding a computer geek who could write was like finding a unicorn or something at the time. Long story short, I told them that I would rather make things that people actually use as a CS major than write something that absolutely nobody will ever read as a Technical Writing major!

As the person who wrote both the station driver and readme file, I want to thank you for reaffirming that I picked the correct major way back then… :rofl:

2 Likes

One more question for you experts. :slight_smile: I’m happy with where I’ve gotten WeeWx for a few hours of tinkering today. Thank you all for all your awesome help in this forum! (Also got a rudimentary version of the Belchertown skin going!)

Anyway, wanted to run my sensor map for my Tempest past you all to see if it looks right to you all or if I’ve missed anything good that you all might do differently. Def made it easier that v4.1.1 already had lightning in the schema, although I had to use soilMoist4 for the one missing.

I see a lot of sensor maps using the wind info from rapid_wind. Is that just because it’s more frequent observed vs the wind data in obs_st? And then does WeeWx average it when it records into the database every 5 mins? Edit: Answered this one myself by reading the technical docs. The archive routine will average (or sum or max) various values from the LOOP data when it writes the archive, so better to get the rapid wind data. (I’ll assume that it’s probably better to ignore the wind_gust from the obs data and let WeeWx calculate it, since in theory the same data should be included in the rapid wind data packets as well. Anyone test this?)

[[sensor_map]]
    #signal2 = wind_lull.ST-00007481.obs_st
    #signal3 = wind_avg.ST-00007481.obs_st
    #signal4 = wind_gust.ST-00007481.obs_st
    #signal5 = wind_direction.ST-00007481.obs_st
    #signal6 = wind_sample_interval.ST-00007481.obs_st
    #signal2 = wind_lull.ST-00007481.obs_st
    #windSpeed = wind_avg.ST-00007481.obs_st
    #windGust = wind_gust.ST-00007481.obs_st
    #windDir = wind_direction.ST-00007481.obs_st
    #signal6 = wind_sample_interval.ST-00007481.obs_st
    pressure = station_pressure.ST-00007481.obs_st
    outTemp = air_temperature.ST-00007481.obs_st
    outHumidity = relative_humidity.ST-00007481.obs_st
    luminosity = illuminance.ST-00007481.obs_st
    UV = uv.ST-00007481.obs_st
    radiation = solar_radiation.ST-00007481.obs_st
    rain = rain_accumulated.ST-00007481.obs_st
    rainBatteryStatus = precipitation_type.ST-00007481.obs_st
        # 0 = none, 1 = rain, 2 = hail
    soilMoist4 = lightning_strike_avg_distance.ST-00007481.obs_st
    lightning_strike_count = lightning_strike_count.ST-00007481.obs_st
    outTempBatteryStatus = battery.ST-00007481.obs_st
    windBatteryStatus = battery.ST-00007481.obs_st
    batteryStatus1 = battery.ST-00007481.obs_st
    windSpeed = wind_speed.ST-00007481.rapid_wind
    windDir = wind_direction.ST-00007481.rapid_wind
    lightning_distance = distance.ST-00007481.evt_strike
    lightning_energy = energy.ST-00007481.evt_strike

I’ve been experimenting recently with weewx, @vreihen’s UDP driver, and the Belchertown skin with MQTT enabled. I think I am slowly understanding how everything works, but I can’t work out why the “Feels Like” temperature reported in the Belchertown skin (which I think is the Heat Index) via MQTT is always higher than the “Feels Like” temperature defined by the Heat Index in the Tempest App. Does anyone know why there is a difference, or can you point me in the direction of the right websites to read?

Weewx sources on GitHub, Belchertown skin in your installed weewx, and WF published docs for their derived measurements.

I guess my question did beg for a simple answer! I have read through much of the documentation and from what I can see the Weewx “Feels Like” is derived the same as the WF “Feels Like”. I think I need to dig more through the Belchertown source to see exactly what is going on.

What you need to do is figure out if Pat is calculating something custom or if he’s just picking an element that weewx calculated and stored on the db. Shouldn’t be too hard to do some ‘grep -Ri’ for the word ‘feels’ to figure it out.

1 Like

Hey guys, I got mine all up and running. And @jamesbellanca good job man, I am a server and network engineer and this took me a bit to get figured out how everything works.

I am using the Tempest and noticed something flawed on mine and was wondering if you guys have as well. I know its not a driver or weewx issue.

So check this out… My pressure is reporting correctly in the WeatherFlow and Weather Underground apps. Its sitting about 29.62 right now which is about right on. Oddly though… my UDP packet reports it waaay lower down at 26. So from wireshark I see that it is reporting in MB. Mine is 913.44 and if I divide that by 33.864 like we are supposed to I get 26.92.

Any of you guys experiencing this?

The pressure reported in the UDP data is the raw station pressure. This will always be lower than the pressure reported in the app/weather underground/weewx, as they’ll be reporting the pressure corrected for your station’s altitude.

1 Like

@peter Man, :man_facepalming: , That makes sense, I finally figured out the issue. Looks like my altitude on weewx was not set correctly ha. Ok… well… thats embarrassing. Thanks peter. That fixed my issue.

@josh1, no worries - it happens to us all sometimes. Glad you managed to figure it out!

Glad you got it all up and running well @josh1. You might also want to check out this thread with what I did next.

https://community.weatherflow.com/t/script-to-update-weewx-with-wf-api-data/7229