WeatherFlow Tempest | WU Rapid fire

234 views
Skip to first unread message

fpu...@gmail.com

unread,
Dec 1, 2020, 10:56:04 PM12/1/20
to weewx-user
I asked this question on the WeatherFlow forum but I think is a good idea ask it here since its directly related to WeeWx.

I recently installed a WeatherFlow Tempest and today I migrated it to WeeWx, one of the data that I'm posting is to WU. 

The question is related to Rapid Fire feature, if I enabled it the Gust data is missing from the WU data, is there a way to report it with Rapid Fire set to true?

Thanks.

fpu...@gmail.com

unread,
Dec 1, 2020, 11:00:15 PM12/1/20
to weewx-user
Here is an example from todays data. 

When RapidFire was set to True the "wind speed" increased but "wind gust" was missing. 

Screen Shot 2020-12-01 at 10.58.17 PM.png

vince

unread,
Dec 1, 2020, 11:35:27 PM12/1/20
to weewx-user
What does your weewx.conf stanza sensor_map for the driver look like, and do you actually have rapid_wind enabled for your station via the Tempest app setup ?

I guess I'm wondering if you're using the obs_st mapping of wind (which is once/minute) and not the rapid_wind mapping of wind (which is once every 3 secs 'if' enabled in the Tempest app), but that's just a guess.  You need to provide more info into your configuration.


fpu...@gmail.com

unread,
Dec 1, 2020, 11:44:40 PM12/1/20
to weewx-user
Below a copy of the sensor_map.

 I can see 3 seconds update in the Tempest website but not sure if its related with the "Tempest app setup", I have to double check that since I'm not sure where that setting is (I'm new to WeatherFlow).

If I enabled rapid fire in WeeWx, I see WU getting the RapidFire interval but with the missing Gust value. 

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

vince

unread,
Dec 2, 2020, 11:47:51 AM12/2/20
to weewx-user
On Tuesday, December 1, 2020 at 8:44:40 PM UTC-8 fpu...@gmail.com wrote:
 I can see 3 seconds update in the Tempest website but not sure if its related with the "Tempest app setup", I have to double check that since I'm not sure where that setting is (I'm new to WeatherFlow).


If you see updates every 3 secs you're likely in rapid_wind mode, so you're probably ok there.

If I enabled rapid fire in WeeWx, I see WU getting the RapidFire interval but with the missing Gust value. 


I really have no idea there unless there's a timing thing.  WU is weird.

I wonder if it's possible to have weewx print out what it's sending WU field-by-field so we could see if it's a weewx (sender) thing, or a WU (receiver) thing.


fpu...@gmail.com

unread,
Dec 2, 2020, 2:06:00 PM12/2/20
to weewx-user
This log works for you? 

Dec  2 14:03:27 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:26 EST (1606935806)

Dec  2 14:03:28 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A27&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=321&windspeedmph=3.3

Dec  2 14:03:28 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:27 EST (1606935807)

Dec  2 14:03:30 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A29&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=317&windspeedmph=4.1

Dec  2 14:03:30 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:29 EST (1606935809)

Dec  2 14:03:33 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A32&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=022&windspeedmph=8.9

Dec  2 14:03:33 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:32 EST (1606935812)

Dec  2 14:03:36 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A36&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=005&windspeedmph=5.1

Dec  2 14:03:36 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:36 EST (1606935816)

Dec  2 14:03:39 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A39&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=298&windspeedmph=1.1

Dec  2 14:03:39 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:39 EST (1606935819)

Dec  2 14:03:42 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A41&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=293&windspeedmph=4.7

Dec  2 14:03:42 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:41 EST (1606935821)

Dec  2 14:03:45 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A44&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=006&windspeedmph=6.0

Dec  2 14:03:45 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:44 EST (1606935824)

Dec  2 14:03:48 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A47&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=299&windspeedmph=5.6

Dec  2 14:03:48 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:47 EST (1606935827)

Dec  2 14:03:51 weewx-vm weewx[9466] DEBUG weewx.restx: Ambient: url: https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&ID=KMDMILLE9&PASSWORD=XXX&softwaretype=weewx-4.2.0&tempf=47.9&humidity=040&dateutc=2020-12-02%2019%3A03%3A50&realtime=1&solarradiation=219.00&rtfreq=2.5&baromin=30.123&dewptf=24.7&rainin=0.00&UV=1.35&dailyrainin=0.00&winddir=311&windspeedmph=5.5

Dec  2 14:03:51 weewx-vm weewx[9466] INFO weewx.restx: Wunderground-RF: Published record 2020-12-02 14:03:50 EST (1606935830)


fpu...@gmail.com

unread,
Dec 2, 2020, 2:13:53 PM12/2/20
to weewx-user

fpu...@gmail.com

unread,
Dec 5, 2020, 8:58:38 PM12/5/20
to weewx-user
Is there a way to add the "windgust" when rapid fire is enabled?

gjr80

unread,
Dec 5, 2020, 10:26:00 PM12/5/20
to weewx-user
Hi,

Perhaps this needs a more philosophical approach.

For WU RF field windgust is taken from WeeWX field windGust. RF uses loop packet data so for windgust to appear in the WU RF upload you need to have WeeWX field windGust in your loop packet.

If I understand correctly the weatherflow driver emits loop packets that contain WeeWX field windSpeed; the driver does not emit WeeWX field windGust. Packets that contain windSpeed are received every three-odd seconds. If I have understood correctly what does windGust mean in this context? Generally speaking, windGust is taken to be the highest wind speed seen over some period; in a WeeWX archive record context (which for arguments sake covers five minutes) then windGust would refer to the highest wind speed seen over that five minute period. When you are receiving wind speed values (only) every three seconds what does windGust mean? The highest wind speed value seen in that three second period? If so then you are going to have problems because your station/driver just does not provide the data for you to determine that, you get one wind speed value every three seconds.

If the issue is fixing a display/processing deficiency in WU then there may be some things you can do with a couple of WeeWX services or in the driver to 'manufacture' windGust, but I think you will find these result in other consequences.

For what its worth this is not unique to weatherflow stations. I cannot think of any station (driver) that emits high frequency loop packets that contain windGust. All such stations/drivers that I am aware of emit windSpeed only in loop packets.

Gary

fpu...@gmail.com

unread,
Dec 5, 2020, 11:19:53 PM12/5/20
to weewx-user
Thanks Gary for your analysis, it make sense, I will have to dig a little bit more in other stations since I think I have seeing other (not WF) sending rapidfire with windgust at the same time. Not sure where / how they calculate it. 

In the same line of thought is there a way to increase the WeeWx WU report interval? Right now it report every 5 minutes and I have seeing stations reporting every 1 minute so it seems to be supported by WU.

Thanks,

Frank.

gjr80

unread,
Dec 6, 2020, 12:46:44 AM12/6/20
to weewx-user
Frank,

Experience has shown that some stations do not play well when using RF. Such stations are usually what we call partial packet stations (ie the loop packets they emit do not always include all observations). As a result caching of loop packet data is applied when operating in RF mode and this allows partial packet stations to play much better with RF (though I still have my suspicions that RF, caching and partial packet stations cause the occasional problem) . You might like to try and find some Davis RF stations to see if they populate wind gust on WU, Davis stations play pretty well with WU and in RF and they do not emit windGust in loop packets.

By your question re increasing the WU report interval I assume you mean 'reporting more often' rather than actually increasing the report interval (which would report less often). The answer is 'it depends'

A little background. WeeWX can report to WU on receipt on an archive record (non-RF mode) or on receipt of a loop packet (RF mode). How often a station reports depends on what mode it is operating in and its archive interval or the period between loop packets. For example, a station with a one minute archive interval with loop packets every 2.5 seconds operating in non-RF mode would see WU update every one minute (in this case the interval between loop packets is irrelevant); a station with a five minute archive interval with 60 seconds between loop packets and operating in RF mode would also update WU every one minute (in this case the archive interval is irrelevant). There is one constraint though; the WeeWX archive interval needs to be a multiple of one minute, so you cannot do non-RF updates every 30 seconds, one minute is as low as you can go with non-RF. So provided you observe this constraint you can post more often by operating in non-RF mode and reducing your archive interval. To go under one minute you need to operate in RF mode and have loop packets arrive in sub-one minute intervals.

Further complicating the matter (or rather giving the user more control over RESTful uploads) is the post_interval config option. post_interval specifies the minimum period in seconds between posts (the documentation implies that post_interval affects archive record based posting (ie non-RF mode) but I believe it is actually used in RF mode as well (why you would use it for RF posts I don't know)). If you specify post_interval = 900 then posts will only be made if a least 900 seconds have elapsed since the last post. post_interval is intended for use with services that only want to hear from your station every (say) 15 minutes but you are running your station with a five minute archive interval (which would normally result in posts every five minutes). post_interval defaults to 0 which means every archive record/loop packet results in a post being made.

Gary

vince

unread,
Dec 6, 2020, 1:16:30 PM12/6/20
to weewx-user
On Saturday, December 5, 2020 at 7:26:00 PM UTC-8 gjr80 wrote:
When you are receiving wind speed values (only) every three seconds what does windGust mean? The highest wind speed value seen in that three second period? 

Let me explain the WF gear and UDP API that the weewx driver uses a bit...

Wf has two basic wind-related measurement elements in the UDP API...
  • obs_st is the station observation from the Tempest sensor suite.   It has the usual wind things in it (speed, direction, gust, gust direction) for three different measurements they emit, called 'lull', 'avg', and 'gust'.  Their wind lull and gust are the min/max 3-sec averages within that 60-sec obs_st period.  The avg is of course the overall average through that 60-sec window
  • rapid_wind is a separate observation emitted every 3 seconds.  It has speed+direction elements, which are averages within 'that' 3-sec rapid_wind window
The obs_st and rapid_wind measurements aren't emitted at the same time, so there's some offset in periods there, but for discussion lets assume they were aligned perfectly.  So theoretically if you had a magical one 3-sec 20 mph wind event at 'just' the right time...
  • the one 'wind gust' emitted by obs_st would have 20 mph (max 3-sec wind in that 60-sec period)
  • there would be one rapid_wind 'speed' that was 20 mph (wind average speed in that 3-sec period)
  • there would be 19 rapid_wind observations with wind zero for speed (no wind in 19 different 3-sec periods)
  • the obs_st min would be 0 mph (min for a 3-sec period over that 60-sec observation period)
  • the obs_st avg would be 0.15 mph (do the math...)
That said, WF is kinda a strange beast, as it has all kinds of asynchronous observations for:
  •  obs_st for most typical observations
  • rapid_wind for more often 'also' reporting some wind info
  • lightning events
  • rain start events
  • lightning strike events
  • device health status measurements
  • hub health status measurements
The real question to me is what should weewx post to WU in terms if 'which elements are posted' and should it be different rapid-fire or non-rapid-fire ?

An alternate question is whether the WF-UDP driver is doing the right thing re: partial packets and getting wind gust info into the LOOP packets to begin with.

But personally I wonder if changing the sensor_map to use the obs_st wind value rather than the rapid_wind speed value will get the original poster more of what they're looking for if they turn rapidFire on.  Unfortunately I don't have any WF gear anymore so I can't do that test...


Reply all
Reply to author
Forward
0 new messages