I’m confused too. It’s been this way for the 18 months I’ve been working on the project. The Rapid Wind data matched almost perfect when I did the calculations. I found one small issue which I emailed David about and he confirmed the code I used was almost identical to the WeatherFlow code.
Hmm, yes, I did say that… but I was wrong! In fact, the Smart Weather apps do display direction as NULL when speed is zero, but that logic is on the client side. The direction is reported as zero (not NULL) in the rapid_wind message, but it should be NULL, since wind direction is undefined when wind speed is zero. We may address this in a future firmware update, although it would probably break a lot of things downstream, so I’m not sure what the appetite from developers would be for that. The alternative would be to just make sure developers know they should treat direction as NULL when speed is zero.
You can use 360 when wind is actually from the North.
That would break any software that tears apart the data and expects everything as a numerical value like all your other measurements that I’ve seen so far other than calibration messages, but as long as we know to trap for that kind of thing, I guess we can deal with it before you updated a firmware (if we knew in advance).
When you say NULL do you mean a value of
'' (like single-quote single-quote with no spaces in between) or a literal string NULL ?
Also disagree with the suggestion to use 360, as that seems pretty kludgy to me.
It’s JSON data so the field would contain the word null with no quotes, just like it does now in the Sky data.
If the application is written correctly it will cause no issue.
I’m fine either way.
I have been going through my code in WFArchive and I am finding some areas where I am using zero instead of null. It’s a pain to fix but better to fix it now than to dig the hole deeper.
After giving this more thought I am going to convert the zero reading to null before I handle the data. It is a better way to handle a ‘no value’ value. It should be NULL and you should consider changing it.
Give developers a period of time to prepare and just do it. I’m going to code for it today.
It is only logical.
@dsj, I have a question.
In obs_sky, when the values of the obs index 4, 5 or 6 are zero, should these be NULL? If obs index 7 is zero, should it and index 4, 5 and 6 also be NULL?
I think any zero wind reading should actually be NULL instead of zero.
Think I disagree a little…
4 = min, 5 = ave, 6 = gust, 7 = direction
Min can certainly be 0.0 with a non-zero average and gust during the obs_sky period, meaning direction should be displayed as whatever it averages out to be (possibly for the non-zero measurements, whatever WF indicated elsewhere here recently)
But if all speeds were 0.0 then I’d agree with 7=NULL
If the measurement is 0.0 for speed, then the reading should report 0.0 (what it was observed to be) and ‘not’ NULL (which to me is ‘no reading or not-applicable’)
I don’t think so. The wind speed can be zero (dead calm), and that’s different than null. In that case, direction is null but speed is 0.0. Likewise, if index 7 (direction) is 0, that’s a perfectly valid direction and independent of speed.
Correct. The only time you’ll see null in the speed fields (index 4, 5, 6) is when the sonic sensor has failed to take a measurement for some reason. And, in that case, direction (index 7) should also be null.
These answers are why I am asking. I know very little of general weather.
Continuing the discussion from Low winds mostly northerly:
I have the same exact issue.
This should have been fixed in the latest firmware release (v98).
yeah, they fixed it by turning the real wind to the North
@dsj I didn’t check long enough to be 100% sure, but it almost looks as you have reintroduced this bug. Low wind speeds are mostly northerly again.
Hi Sunny. That code hasn’t been touched since the bug was fixed so it’s unlikely to be reintroduced, but you never know!
Looking at your rapid_wind data there are a fair number of “0@0” obs, but the bug of those being used in the average does not seem to be there. There do seem to be a lot of 0 mph obs in your 1 min dataset, but that may be because you have the device in low-power mode, and it’s easier to get a full minute’s worth of obs of nothing but 0s when winds are near calm and there are only 4 observations taken per minute. Note the direction when you were seeing non-zero wind was still mostly northerly (with a large spread from NW to NE, clockwise), so no bug there either as far as we can tell.
PS: This graph just says that everything looks good, data-wise
Cool. It must be just that… Mostly northerly winds. Thanks for checking.
sorry, but it wasn’t solved. I posted https://community.weatherflow.com/t/app-version-3-24-beta-release/4148/24?u=sunny. A weak wind that is over a long stretch westerly, is averaged with the null values when zooming out to something northerly.
Thanks. The original issue was related to the calculation of direction in the one-minute observations on the hardware itself (in firmware). You’ve discovered what may be a similar issue with the calculation of direction for other zoom levels, which is done on the back end. We’ll check it out!