WeeWX UDP driver for WeatherFlow station

When you install the extension it will add a [WeatherflowUDP] section into your weewx.conf - you want to include the [[sensor_map]] section under there.

It’ll look something like the following - just make sure to put your tempest sensor id in there of course…

[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-00000001.obs_st
        outHumidity = relative_humidity.ST-00000001.obs_st
        pressure = station_pressure.ST-00000001.obs_st
        #lightning_strikes =  lightning_strike_count.ST-00000001.obs_st
        #avg_distance =  lightning_strike_avg_distance.ST-00000001.obs_st
        outTempBatteryStatus = battery.ST-00000001.obs_st
        windSpeed = wind_speed.ST-00000001.rapid_wind
        windDir = wind_direction.ST-00000001.rapid_wind
        #luxXXX = illuminance.ST-00000001.obs_st
        UV = uv.ST-00000001.obs_st
        rain = rain_accumulated.ST-00000001.obs_st
        windBatteryStatus = battery.ST-00000001.obs_st
        radiation = solar_radiation.ST-00000001.obs_st
        #lightningXXX = distance.ST-00000001.evt_strike
        #lightningYYY = energy.ST-00000001.evt_strike
1 Like

I use an android app called UDP Terminal to check my Weatherflow devices are working correctly. Once loaded, you will need to enter port as 50222. It will then show you all the UDP packets coming from your Weatherflow devices together with their serial numbers.

David

1 Like

Based on vinceskahan’s post of the [WeatherFlowUDP] text…I thought perhaps my install had not gone right - my weewx.conf looks very different. So I reinstalled the driver.

pi@raspberrypi:~/Downloads sudo wee_extension --install weatherflow-udp-master.zip Request to install 'weatherflow-udp-master.zip' Extracting from zip archive weatherflow-udp-master.zip Saving installer file to /usr/share/weewx/user/installer/weatherflowudp Finished installing extension 'weatherflow-udp-master.zip' pi@raspberrypi:~/Downloads

No errors, restarted, but no change to the weewx.conf
##############################################################################

This section is for information about the station.

[Station]

# Description of the station location
location = Woodside SA

# Latitude in decimal degrees. Negative for southern hemisphere
latitude = -34.95694444
# Longitude in decimal degrees. Negative for western hemisphere.
longitude = 138.88000000

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 389, meter

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be used.
station_type = WeatherFlowUDP

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##############################################################################

[WeatherFlowUDP]
driver = user.weatherflowudp

##############################################################################

[Simulator]
# This section is for the weewx weather station simulator

# The time (in seconds) between LOOP packets.
loop_interval = 2.5

# The simulator mode can be either 'simulator' or 'generator'.
# Real-time simulator. Sleep between each LOOP packet.
mode = simulator
# Generator.  Emit LOOP packets as fast as possible (useful for testing).
#mode = generator

# The start time. Format is YYYY-mm-ddTHH:MM. If not specified, the default
# is to use the present time.
#start = 2011-01-01T00:00

# The driver to use:
driver = weewx.drivers.simulator

##############################################################################

This section is for uploading data to Internet sites

I still do not have the Sensor Map - and I do not have any of the Options mentioned in the read-me either. ie

[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

Hi Rob,

In your [WeatherFlowUDP] section of the weewx.conf file, just add your [[sensor_map]] section. Mine is:

##############################################################################

[WeatherFlowUDP]
driver = user.weatherflowudp
log_raw_packets = False
udp_address =
# udp_address = 0.0.0.0
# udp_address = 255.255.255.255
udp_port = 50222
udp_timeout = 90
share_socket = False

[[sensor_map]]
    outTemp = air_temperature.ST-00023519.obs_st
    outHumidity = relative_humidity.ST-00023519.obs_st
    pressure = station_pressure.ST-00023519.obs_st
    lightning_strikes = lightning_strike_count.ST-00023519.obs_st
    avg_distance = lightning_strike_avg_distance.ST-00023519.obs_st
    outTempBatteryStatus = battery.ST-00023519.obs_st
    windSpeed = wind_speed.ST-00023519.rapid_wind
    windDir = wind_direction.ST-00023519.rapid_wind
    luxXXX = illuminance.ST-00023519.obs_st
    UV = uv.ST-00023519.obs_st
    rain = rain_accumulated.ST-00023519.obs_st
    windBatteryStatus = battery.ST-00023519.obs_st
    radiation = solar_radiation.ST-00023519.obs_st
    lightningXXX = distance.ST-00023519.evt_strike
    lightningYYY = energy.ST-00023519.evt_strike

##############################################################################

Save the file then restart weewx and you’ll be good to go.

Cheers
Simon

As I said - when you install the extension you get a default ‘minimal’ configuration.

You NOW need to edit in the sensor map, then run wee_config --reconfigure to change which driver you’re running, then restart weewx.

http://weewx.com/docs/utilities.htm#Action_--reconfigure

Got home for a few hours this afternoon & managed to go through the editing in the sensor map, and the reconfigure…
For the 1st time I have Temperatures at least…that match the WeatherFlow App…!!
Thank you for the assistance - there seem to be extra steps that are not mentioned.
That is where us beginners get caught out.

1 Like

There is a fork of the driver with some interesting new features like backfilling data from REST, if weewx was down for some reason:

oooohhh I like the create sensor map feature…

I like that someone else is now taking ownership of all support!

I don’t like that the GPLv3 license file is missing from the root of the repository… :-1:

I see it there - (link) - or am I missing something ?

1 Like

Looks like my browser cache is corrupted. It’s there now…

Yes, and REST backfilling is even better. I just installed it and created the sensors through the driver. Cool function.

Yes, and REST backfilling is even better. I just installed it and created the sensors through the driver. Cool function.

You realise that you don’t need to generate the sensor map using the driver? If you’re OK with the sensor map that is generated automatically, you can just leave it out totally.

Especially for the unreleased version the only valid reasons to have your own sensor maps is that you have a pre-existing database which uses other fields than the ones I opted for (and you’re not willing to switch). In all other situations I don’t think there are good reasons to have an explicit sensor map.

But that’s not really true for the latest release-version of the driver (1.13) as that not yet has the feature of different mappings for REST and UDP. The bleeding edge version has that though.

The are other reasons for a sensor map in the configuration, too: if you want to use the different wind/windDir values independently, for instance: rapid_wind vs. obs_st
I use the obs_st values to be stored in the database, the rapid_wind data for my live charts and gauges.

The unreleased version uses rapid_wind when fetching from UDP but obs_st when fetching from REST. I’m not sure why you’d want the obs_st values even when using UDP-data. The only reason I can think of is if weewx is aggregating them in a different way than Tempest and you prefer the Tempest way, but I’d think that if they differ then wouldn’t that be a bug somewhere?

The obs_st packages have, as far as I know, some kind of QoS and won’t just get lost, if missed. Especially with vector data and the wind’s fluctuating nature this might have impact. And if the hardware provides an aggregation, then, yes, I’d prefer this.

1 Like

OK, you didn’t really convince me, but if that’s what you think is important, then by all means do it like that :slight_smile:

But since you then have both fields, you should be able to compare the two?

I don’t store the rapid_wind values. they just move the gauges every three seconds, and away they are…
I could store them, would be interesting to compare them.

1 Like

Nope, unless you’ve removed functionality from the upstream you forked from.

It’s also used to let you pick+choose among which Tempest(s), or Air(s), or Sky(s) you get what from. Lots of people have multiple sensor suites on their setups.

Example - an old Air in shade will always be more accurate in temperature than a Tempest that’s in the sun.

2 Likes

That’s true, and of course one of the reasons why I’ve kept the functionality. Are there really “lots of people” doing that?

Wow, it almost feels like people are very keen to point out that there are reasons… Like I made a very controversial statement. Let me, for peace’s sake, reformulate a bit then:

=>

“My goal has been that most users have no good reasons to use time to add an explicit sensor map to their weewx.conf file.”

1 Like