Possible Bug - WebSocket API Missing Data Sometimes

Has anyone noticed that sometimes the Tempest observation data is missing fields?

For example, I just received:


Notice the nulls in the rain data and wind lull. Rebooting the tempest seems to fix it.

We’d have to see your device_status and hub_status messages I think, to look for the sensor status. I notice the voltage looks pretty low which might be part of the issue. My recollection the Tempest starts shedding sensors as the voltage gets low on the unit. There was a long post a month or two ago about what it does and when.

Here it is - Tempest data collectionn during low battery conditions

Not sure I follow, my devices is at 2.4v according to the post says I’m in Mode 2 and nothing is disabled?

Edit: Also if it’s battery related and not a bug, seems odd that rebooting the tempest fixes it?

Hi @dmeglio, I think there may be some misunderstanding over what observations the nulls correspond to. The first null (index 4 in the obs array; counting starts from 0) corresponds to the wind direction. The wind direction is null because the wind speed is zero. The direction is undefined if the wind speed is zero. The last two nulls (index 19 and 20) are rain accumulation values after RainCheck has been applied. As RainCheck is applied retrospectively to your station data, they are always going to be null in the real time websocket data.

You can see which fields are which here: https://weatherflow.github.io/SmartWeather/api/swagger/. Click “expand operations” in the top right.

Yeah I see that now, unfortunately it was because obs_st is undocumented in the WebSocket API… I guess I was supposed to look at the REST API to get the documentation…

Anyway, you’re correct about the rain but that doesn’t seem to be the case about wind speed. Right now wind speed is 0 and I get a 0 in the data: 1598212884,0.0,0.0,0.0,0,6,979.5,27.4,62,18342,1.08,153,0.0,0,0,0,2.4,1,0.0,null,null,0

The null only happens sometimes. And as a note, the article about the battery level changes doesn’t mention the wind sensor ever being disabled.

Yea the WeatherFlow team are aware that the documentation for the Websocket is missing, but I think that they are so snowed under at the moment it’s not their top priority.

It is interesting that the wind direction is only null sometimes. I wonder whether it is null only when the average 1 minute wind speed is truly zero, whereas other times the average 1 minute windspeed is very light and rounds to 0.0, but the direction is then defined.

You are right that the wind sensor is never disabled, but the sampling interval gets a lot longer (3 seconds, then 6 seconds, then 1 minute, then 5 minutes). This makes it more likely for the average 1 minute windspeed to be zero.

Can you share your station ID? Might help to see what is going on.

1 Like

It was reporting null for 3 days straight. I powered the Tempest off/on and immediately it went to 0.0. Not really sure what to say, just know it’s screwing up math in a program I was using because I didn’t know null was even a valid value.

Null is valid for every value.

I’m not sure I know the answer I’m afraid. There is some discussion in this thread: Calculate wind vector-direction and this thread: Wind Direction when winds are calm should not be zero, but I don’t know whether any changes were ever made. As Gary said though, null is definitely a valid value, so the simplest solution is to allow your code to handle that value correctly.

Agree, but it does say the sensor sample period can back off to greater than 60 seconds, so you have a chance of there being no wind reading in a particular obs_st. There is usually a lot of discussion regarding what direction stations should report when there is zero wind. Some folks want null (no data). Some folks want the previous reading (I guess figuring a physical sensor wouldn’t have moved).

That is the most logical value since that’s been the standard for over 2000 years.

1 Like

obligatory xkcd - https://xkcd.com/927/

1 Like