I have been listening and analyzing UDP packets on port 50222 for the past few days only see the following types of packets. Where are the others?? None of the other packet types ever get transmitted. Why?
- hub_status
- rapid_wind
- device_status
- obs_st
Sounds reasonable to me. Are you expecting rain/lightning events when there arenât any such events ?
The only other two are evt_precip and evt_strike and those only happen when it starts raining or when there is a lightning strike.
Thanks for the reply. Here are the stats from monitoring UDP for about 18 hours. During this time precipitation and lighting did occur and had a lot more reports on the mobile app but the UDP data showed nothing to little in those categories.
evt_precip 2
evt_strike 0
rapid_wind 14,238
abs_air 0
abs_sky 0
obs_st 718
device_status 718
hub_status 4270
Just a thought but is it possible that the continuous loop I use to monitor the UDP packets is just missing some because of timing?
Yes - easily possible to miss a small percentage depending on which program youâre running, how itâs written, and how perfect your network is. There were many threads with data on this some years ago when the Air/Sky first came out.
If you had 718 minutes up, youâre catching over 99% of the expected hub_status and rapid_wind messages which is pretty good.
I never bothered measuring events. I found the lightning sensor completely useless here and I can hear the rain on the roof when it starts to rain.
1 Like
Network aside and a few packets missing due to timing I can deal with.
I need to still understand why very littel evt_precip and zero evt_strikes were collected via UDP while the mobile app was full of data. Can someone on the Tempest dev team chime in here?
I know strikes are crowdsourced on the WF server side, so you âneverâ see strikes lining up with what you see in the UDP broadcasts. Again, there are a zillion threads about this. What you see in the app is some undisclosed magic math aggregate of lots of sources of info, of which your station is one.
Uncertain about evt_precip and whether they do the similar magic math stuff there.
Hi @tim9,
Zero evt_strikes coming through could indicate that your Tempestâs lightning sensor was not detecting lightning. See more info on lightning detection
For lightning, the REST API would be a better resource to access all of the lightning data available to your station.
On the other hand, a lightning sensor parameter adjustment could be helpful to allow your sensor to detect more lightning strikes. Better hardware detection would allow for more evt_strikes reported over UDP.
evt_precip is defined as a rain start event: UDP Broadcast
for one continuous rain event, you would typically only get 1 of those messages
the condition for reset is if rain signals are not detected for at least 30 minutes and then resume
1 Like
@WFstaff, it appears from the mobile app that the lightning sensor is working because the mobile app shows them just fine. I am questioning the udp reliability. Why are those not consistent with the data on the mobile app? The app I am building really needs to work on local network only and it appears my only option is to use udp packet. Am I wrong?
Because WF add additional lightning data through their backend servers that has not been detected locally by your Tempest lightning sensor. Using UDP will only show the lightning strikes that have been detected locally
4 Likes
Itâs also worth pointing out that obs_air and obs_sky are in reference to two separate devices. The Weatherflow AIR device was used to collect Temp, Humidity, Pressure, and Lightning. A seperate SKY device collected wind, rain, and UV/solar.
The Tempest device smashed the two together into one device. The Tempest device will never report obs_air or obs_sky values. I donât think either the AIR or SKY devices are sold anymore.
2 Likes
Good to know. Thanks. Iâd like to see more clarity on what data to expect
What exactly is unclear ?
UDP is what your station read from its sensors and should match exactly with what WF displays in the mobile app for the same time period. Almost.
There are two exceptions:
-
lightning will never match because WF generates a synthetic value for your reading based on some undisclosed math and other sources of information. This is documented (here)
(you cannot turn this feature off)
-
rain similarly will not match by default, but you can turn their NC Rain feature off if you want to just see what your station reported with no alteration - see (here)
(many folks want to see âwhat did my station reportâ so they turn that feature off)
Also - as your Tempest approaches a dead battery state it will slow down how often it reports some things and will even start to shed lower priority sensors from reporting. Itâll go back to a normal mode as the battery charge level recovers to normal. This is documented in a bunch of threads, but basically if your battery is in a good charge state you would not see this happening.
2 Likes
The unclear part is the obs_air and obs_sky. I cant say I disagree with OP. It took me some looking around myself to figure out what the obs_sky and obs_air were myself. It wouldnât hurt to put a sentence or two in the UPD documentation describing the data source.
Itâs in the obs_whatever name. obs_air = the original Air sensor. obs_sky = the original Sky sensor. obs_st = the current Tempest sensor. Just look at the API to see what gear emits which readings.
https://weatherflow.github.io/Tempest/api/udp/v171
The device_status message values can differ based on gear if you look at the API docs. That section reiterates which sensor emits which readings.
AndâŚ
- Air devices have serial numbers starting with AR
- Sky serial numbers start with SK
- Tempest serial numbers start with ST
- Hub serial numbers start with HB
2 Likes
Vince, it is unclear to me. Perhaps not to you who works with the API a lot more but for people like me just walking up to it for the first time needs more information. Your explanation here is perfect and would be a great addition to the UDP documentation. Even just a link to the documentation you just posted would be of great help.
This is more helpful information that, if available on the UDP documentation, would help reduce discussion topics and support tickets. I had no idea what a Sky sensor is/was.
1 Like
The forum software WF uses is particularly difficult (for me) to find stuff ink especially history.
If you use Google ala: "site:weatherflow.com what is an Air or Sky" youâll find all kinds of good things that might not be currently linked into WFâs web too obviously. It does help sometime.
For the forum organization here, best I can tell you is click on the blue Developers icon in the heading of the forum messages and the forums software will limit you to just developers. The link to the API is on the page the banner links to.
FWIW - I bookmarked a link to the UDP API about the second hour I started messing with writing my UDP listener. Also bookmarked @vreihenâs weewx driver and @peterâs PiConsole github pages. Then I donât have to search usually.
WF kinda scrubbed most mention of Air+Sky from their website pretty quickly after they went all-in on the Tempest, so it can be rough finding the history so many years after the fact.
Iâm very aware of the API documentation, but it isnât clear anywhere what âSKYâ is or âAIRâ is. Being a newcomer to the Tempest product line, I had no idea such devices ever existed. To see obs_air and obs_sky in the documentation for what someone new to the product can only assume is for one deviceâŚnot three. When you read the documentation, itâs easy to assume it is for only the Tempest product. It is confusing.
The âAirâ device (WF-AIR01) is still available. . .it makes an excellent indoor monitoring weather station. . .but the price is pertnear outrageously high! (The âSkyâ device (WF-SKY01) is no longer produced. It can only be obtained if someone has one for sale (or to give-away). I have my Original SWS (SmartWeatherStation) plus another one as a complete backup.