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…
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.
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
[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
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.
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.
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.
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.
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.”