UDP JSON numbers type

Developers
,
1

Relatively new here, just got my Tempest (which I love) last week and I’m now trying to write a simple Linux UDP relay daemon in C/C++.

Given the nature of the language I’m using, I’m trying to determine if it’s possible to “typify” the various numbers or should I just consider everything as "double"?

For instance, in the UDP documentation, is the presence of a decimal point and subsequent decimals an indication that the number is to be considered a float with that max number of decimal digits? And conversely, if a number doesn’t have decimals, can it always be considered an integer?

For example I always considered the UV index to be an integer scale from 0 to 11+. However I see that "obs_sky" has an UV index of "10" while "obs_st" is reporting "0.03" and my Android Tempest app is reporting UV index as "6.7".

2

I’m not sure if it is relevant, but winddirection can be NULL, when there is no wind at all.

3

If the amount of memory your script will use isn’t a constraint, I would just consider everything as double to be on the safe side. Otherwise based on my experience the following fields will probably always by of type integer:

Time Epoch, Wind Direction, Wind Sample Interval, Illuminance, Precipitation Type, Lightning Strike Count, Report Interval

Everything else (except perhaps Solar Radiation and Lightning Strike Avg Distance - I’m not certain if these are always integer) will have some number of decimal places.

2 Likes
4

For parsing JSON, using a parsing library is the right way to go, and from the results you can usually detect the type of number that was parsed, integer vs float.

On a more fun note are the inconsistencies with some numbers like the firmware_revision field. In the device_status and obs_st messages I see, firmware_revision is a proper integer. In the hub_status messages, firmware_revision is a string of the integer instead. Keeps you on your toes while writing code. :slight_smile:

3 Likes
5

Yes of course I’m using a parser.
But if a number like the UV shows up in "obs_st" as "0.03", and in "obs_sky" as "10", what can even the library do?

I’ll probably get a double in "obs_st" and an int in "obs_sky", which is kind of confusing.

6

If you’re writing a relay daemon, I’d think you want to relay whatever the hub reports verbatim.

I would not presume absence of a decimal point in the documentation means anything either way, unless the docs say something specific.

7

Well, passthrough relay is one of the options, in which case I 100% agree with you.
But I’d eventually also like to do some preprocessing and possibly repackage the data in a different format.

8

Could a staff member explain to me why the UV index shows up in "obs_st" as "0.03" , and in "obs_sky" as "10"?

Is it just a typo? Should I read "obs_sky" as "10.0" and use "double" everywhere?

9

Fair enough, I’ve seen people try to parse JSON manually and in really strange ways. I just wanted to be sure that you weren’t on that path. Nice choice with C++. :slight_smile:

As for the different types, I’m writing a collector for this data as well, and I’ll be massaging inconsistencies into more consistent types for consumption by other systems via mqtt topics. I’ve noticed slight changed between the same UDP message when echoed back via the WebSocket channel. I’m not sure if WF plans on correcting some of the inconsistencies, but until they do, we’re going to have to deal with them.

Example UDP and WS values from my Tempest

udp - [1600721177,0.45,1.82,2.86,89,3,996.13,23.86,41.79,71865,5.11,599,0.000000,0,0,0,2.790,1]
ws  - [1600721177,0.45,1.82,2.86,89,3,996.1, 23.9, 42,   71865,5.11,599,0.0,     0,0,0,2.79, 1,0.0,null,null,0]
10

That’s the route I’m planning on taking. To keep the precision of the existing floats, promote the ints to floats where needed.

1 Like
11

I get UV as a decimal on Sky and Tempest.

1 Like
12

Did Microsoft hack your autocorrect. :rofl:

2 Likes
13

20200921_200125
20200921_2001253000×4000 2.53 MB

4 Likes
14

When in doubt just follow the respective API and deal with any inconsistencies you find there.

They haven’t really changed anything in the public interface in a long time. You might see ‘internal use only’ things changing a bit, but they’ve been pretty good about mentioning them in release note-like info (after a number of us raised a ruckus for many months long ago).

1 Like