iOS app live wind updates stop for 30 seconds of every 60-second cycle

Hello all. Semi-pro weather observer here with all kinds of weather equipment over the years. Also have prior programming experience and am sensitive to software “bugs”. I’ve had my new Tempest up and running since June 1st. I have installed the iOS Tempest weather app on both my iPhone 8+ and iPad mini v.2. iPhone is running iOS 13.4.1. iPad is running iOS 9.3.5. Weather app on both devices is most recent version, downloaded from App Store to both devices on 6/1/2020.

After getting to know the program over several days and carefully watching how the data displayed and updated on the screen(s), I began to notice that the roughly 3-second live wind updates would work for 30 seconds and then stop working for the next 30 seconds. When the live data stopped, the wind direction and speed would match the values of the 1-minute average wind and would remain frozen for the next 30 seconds until the new 1-minute average update took place. I was able to determine that the app was actually “aware” of the changing live readings because whenever the peak gust occurred during the non-live period, the value would be displayed properly in the max gust field when the next 30-second live period began and the new 1-minute average values updated on the screen. I am also running on a separate PC the Weather Display program connected to my Tempest. When the live wind data ceases on both iOS devices, it still continues to update every 3 seconds in the Weather Display program.

One other fascinating observation I found was that this bug temporarily stops, and live data updating all 60 seconds every minute continues whenever there is active lightning detection in progress! As long as lightning is being detected the bug stops. However, after lightning detection ends (I don’t know exactly how many minutes after the last detected strike, but no more than 1 hour later) the bug returns and the 30-seconds on, 30-seconds off cycle reappears.

Finally, I am making the presumption this behavior is a bug because if I view the live data from my web browser, the data from the wind remains live with continuous 3-second updates throughout all 60 seconds.

I don’t have an android device to test the app out on to see if there is similar behavior. However, I can confirm that it does occur on different iOS devices. Thanks for your help in reviewing this and hopefully fixing it so the wind data is always live all the time.

1 Like

I can confirm the same thing happening on my iPhone XS running iOS 13.5.1. I can’t test the lightning issue as there is not currently any lightning, but I do see it stop for 30 seconds just as you reported.

1 Like

Hi Stephen and welcome to the Tempest Community! Thanks for the excellent observations and detailed report. I can give you a couple answers (or potential answers) now, but we’ll need to dig deeper to figure out everything here.

One thing to know is that the 3-second live wind or “rapid wind” messages received by your phone are sent over websockets (WS), which are essentially a ‘best-effort’ protocol and are not re-sent if they are not received. That said, while it’s somewhat normal to expect a rare message or two to be dropped once in a while, especially with busy Internet traffic, yours is the first case I’ve heard of with such a significant and regular dropping of messages.

Yes, that makes sense because the one-minute average is not calculated by the app, and therefore doesn’t depend on the 3-second readings. It’s not even calculated on our servers - the one-minute wind speed & direction are calculated on the hardware itself.

This also makes sense because I believe WeatherDisplay is using the local UDP broadcast (sent directly from your hardware) rather than the remote WS and REST data channels that the app uses (although I think that’s an option in WD now).

That is truly bizarre and I suspect it’s a red herring (though anything’s possible!)

That does indeed imply that this is a bug in the app, rather than somewhere deeper in the system.

Thanks, Keenan.

We’ll take a look soon and see if we can figure out what’s going on. If you have any further information that might help us troubleshoot, please share it here.

1 Like

Thanks for your quick response to my post! I’m more than happy to provide feedback from everything I observe in the app’s performance (and the Tempest itself!). We had a brief, but torrential thunderstorm here a few nights ago so I was paying close attention to the high winds occurring during the downpour. It was then that I noticed that the live-winds kept updating continuously. But, then just as strangely after the lightning was gone the bug came back…lol.

By the way, with regard to Weather Display. I’m not so sure that program is using direct UDP because in order for the program to work you have to specify the Weatherflow stationID. There is no set up that directs the program to a specific local port on the PC. I’m thinking it retrieves the info the same way your app does. Feel free to correct me on this point.

Maybe it just needs the Station ID so it can harvest the serial number(s) of your device(s) to know which ones to look for in the UDP broadcast packets.

But aren’t the UPD packets broadcast over a specified port number inside the PC? Don’t you need to know which port number is being used in order to “connect” to that opened port over which the packets are being broadcast? I don’t know if it works the same in MAC or Linux, but in PC’s you have to have an opened port through which the packets are sent and received. This is a minor issue and separate from my wind data app problem. I presume the StationID is utilized somewhere in the UDP data? I just don’t understand how with just the StationID alone you could connect to the UDP broadcasts without a known and specified opened port in the windows firewall.

The Hub broadcasts on port 50222. Every device on the same network can listen to the packets on that port.

Weather Display uses the Station ID when it examines the packets to know if that packet is to be parsed.

1 Like

Ok, so should I infer that Weather Display, knowing about port 50222, opens that port and having been given the StationID by the user, makes the connection over the LAN instead of remotely? That certainly makes sense. Thx.

That is a good question! It’s possible WD supports both local (UDP) and remote (WF & REST), but I don’t recall. Probably best answered by Brian, the developer of WD, who occasionally appears on this forum as @weather-display. Or you might check in on his forum: https://www.weather-watch.com/smf/

PS: Using the remote API (WS & REST) is the preferred method for third-party applications, since that’s the only way to benefit from the data QC processes performed in the Tempest Cloud, as well as the forecast information (which is not available locally). The UDP broadcast is there for the relatively few applications that need to operate when not connected to the Internet.

2 Likes

Hi @dsj,
I have an update on the wind bug. About an hour ago my Tempest detected lightning (for the first time in 8 days). It didn’t take me long to find out that the “bug-free” period of the wind remaining live only lasts for 30 seconds after the most recently detected lightning strike. So, as long as lightning detection keeps resetting the timer back to zero AND the timer does not go past 30 seconds, the 3-second wind updates will continue. As soon as the lightning timer exceeds 30 seconds the bug comes back and the 3-second updates stop until the beginning of the next 1-minute average wind speed update. Then it’s 30 seconds on, 30 seconds off as before, or, until the lightning timer is reset to zero again. I’m hoping you can fix this in your next rollout. I see you just did one 4 days ago, too soon after to include the fix, which I understand. I’m surprised many others have not talked about this bug. I think one of the most interesting features of the Tempest is the 3-second speed updates! Thanks again, David, for your attention to this.

1 Like

Thanks, we’re investigating!