WeeWX UDP driver for WeatherFlow station

While I’m a newbie to tempest, I’m experienced with WeeWx. This concept of mapping, and station ID has really taken hours to understand.

Are you suppose to just change the number, or do you change the Whole ST-###########

Best regards,

@toddhutch the default sensor map for the weatherdlowudp is based on another model than the Tempest. So, yes, if you own a Tempest you have to change the whole AR-0000444 with ST-yourstationid (always 8 digits, so if yours is 23456, then you write ST-00023456). Here is a copy of my setup including the sensor map using captain coredump’s weatherflowudp (in weewx.conf):

driver = user.weatherflowudp
log_raw_packets = false
udp_address =
udp_port = 50222
udp_timeout = 90
share_socket = False

    outTemp = air_temperature.ST-00007624.obs_st
    outHumidity = relative_humidity.ST-00007624.obs_st
    pressure = station_pressure.ST-00007624.obs_st
    outTempBatteryStatus = battery.ST-00007624.obs_st
    windSpeed = wind_speed.ST-00007624.rapid_wind
    windDir = wind_direction.ST-00007624.rapid_wind
    lux = illumance.ST-00007624.obs_st   
    UV = uv.ST-00007624.obs_st
    rain = rain_accumulated.ST-00007624.obs_st
    windBatteryStatus = battery.ST-00007624.obs_st
    radiation = solar_radiation.ST-00007624.obs_st

You’re overthinking this one. All you need to do is replace the ‘example’ sensor device id with ‘your’ sensor device id. So if you are ST-12345678 then you would simply need to…


     outTemp = air_temperature.ST-00000025.obs_st


     outTemp = air_temperature.ST-12345678.obs_st
     (and similarly edit the other lines in the sensor_map)

longer commentary for future folks asking the same question....

WeeWX is super-flexible, supporting dozens of station types as well as user-developed sensors. With great flexibility comes a little of a learning curve.

All a sensor_map does is tell weewx:

  • which measurement
  • from which sensor
  • should be saved into which weewx database element

Why ?

  • there are over 100 database elements in the db so weewx can support a zillion station variants
  • users are able to create all kinds of custom solutions for themselves…and they ‘do’ so
  • so a ‘little’ configuration is required in order to support all this flexibility weewx gives you

For @vreihen’s weewx WF driver specifically:

  • it supports multiple Air, Sky, Tempest sensors attached to one Hub
  • so if you have multiple sensors (many people do), you have to tell weewx which one to use for what

For 95% of the folks, just editing in your sensor id, replacing the example one, is all you need to do. Really.

For the other 5% you have the ability to do things like:

  • use Tempest ST-12345678 for wind speed
  • use Sky SK-234256789 for uv readings
  • use Air AR-34567890 for outside temperature
  • (and so on, in any combination you choose to set up to match your needs)

But for the default case, the example stanza will work for you ‘if’ you replace the example device id with the one for your unique sensor. It’s really that simple.


Not sure if this is the proper venue for this sort of question. Let me know if there’s a better place for it.

I have the UDP listener configured with weewx, and occasionally I notice an issue where a database entry is created with an epoch time of “300” which is impossible. This causes all of my NOAA reports from 1969 on to be populated with blank data. I have removed the spurious database entry a few times, but it comes back after a few days/weeks.

Anyone seen this?

Here’s an example:

sqlite> select * FROM archive WHERE datetime<1442894400;

300|1|5||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||0.0|||||||||| ||||||0.0|||||||||||||||||||||||||||||||244.230262691432|4.00412591497135|245.0| 0.271229199547641|3.25475039457169

My bets would be a Hub reboot whacking the clock or another device broadcasting using the same UDP port such as an IP security camera. The device uptimes on the Tempest web site should show any reboots that have happened…

Think it’s the weewx system perhaps.

The weewx timestamp in the db is what was measured in the weewx system’s clock, not in the ‘content’ of the UDP message that was saved to the db. So if you power-reset a raspi without a RTC in it, this is possible…but any recent weewx has code in there to protect against this kind of thing. It won’t start weewx until the date+time is later than the date+time on the weewx.conf file

One workaround is to simply open the weewx.conf file for edit ‘after’ your host has good time, then save the file (changing nothing). The mtime on the file should show current date+year. That should block weewx starting up until the system it’s running on has its brain straight re: a correct date+time.

To verify this check your uptime on the pi and your syslog. You should see syslog entries that were from 1969 or 1970, depending on which side of Greenwich you’re at.

(update - I posted a question in the weewx-users group asking if there’s an easy way to prevent obviously bogus timestamped data from being written. If I get an answer, I’ll edit this post with details or pointers)

Thanks for the insight. In my case, weewx is not running on a pi, but on a machine with a RTC. Also, the machine running weewx is UPS protected and hasn’t rebooted in quite some time. So I don’t think it’s an issue with the system clock being temporarily incorrect.

I am running weewx 4.1.1 and I do believe this behavior started when I upgraded from weewx 3.x to 4.x.

root@1w-rackcomputer:~# apt list weewx
Listing… Done
weewx/squeeze,now 4.1.1-1 all [installed]

Doubtful it’s v4 related. Weewx gets the timestamp for the archive record from the clock on the runtime computer. So if the computer reports bogus time, weewx believes it. That has always been the case from day one a decade+ ago.