REST API - "barometric_pressure" will be deprecated in favor of "station_pressure"

Hello @WFmarketing !

What is quite strange is in REST APIs, you called the station pressure Barometric Pressure :thinking:

1 Like

In one way of thinking it is. It’s pressure at the barometer. :wink:

2 Likes

You’re right @GaryFunk :rofl:

More seriously, I recommend renaming (in API) barometric_pressure to station_pressure. And to declare barometric_pressure as deprecated… What do you think about it?

4 Likes

I agree. It’s too ambiguous as it is.

5 Likes

The only thing that makes sense to me is to have “station pressure” and “sea-level pressure” . . . and forget all of the other names. Station pressure is measured and sea-level pressure is computed . . . always and everywhere . . . no matter what anyone wants to call it.

4 Likes

Good catch, @pierre !

We agree. The barometric_* variable names will be deprecated in favor of station_* in the REST API. In practice this means two steps:

  1. we’ll add station_pressure and station_pressure_indoor to the response (probably today), using the same values as barometric_pressure and barometric_pressure_indoor.
    [this is when you can make sure your apps use the new variable name]
  2. After about a month, we’ll remove the barometric_* variables.
6 Likes

Hello @dsj !
Thanks for this answer. It is exactly what I wanted to hear :wink:
Could you, please, consider a longer delay between “deprecation” and “deletion”? It’s really important for me as a full deployment (speaking about my application only, not for others :wink: ) can take more than a month. 2-3 months seems (from my point of view) a more reasonable duration…

1 Like

Why are there two and why is only one tagged with location?

1 Like

Ok, we’ll keep it there for at least 3 months!

There are two because one is indoor and the other is outdoor.

Both of them are tagged with location, but one tag is implicit and the other is explicit. :wink:

2 Likes

I understand that if the Air is indoor then the reading would indoor. But I don’t understand why you have two different variables. It is either, not both. I just learned of this today. Outdoor keys are not named outdoor but indoor keys are. It’s overly redundant and while it is easy to code for it’s an unnecessary pain.

Interesting.

Thank you so much @dsj… You rock!

1 Like

David is the BEST but don’t let him know we think that.

2 Likes

Ah, I think there’s some confusion here stemming from the multi-device nature of smart weather stations.

First, some background: A single station can have multiple devices, as you know. And because it’s sometimes nice to get the data from the station itself (rather than from each device), the API provides a federated observation at the “station” level as a convenience. It’s “federated” because it’s a selective combination of data from whatever devices are attached to that station. If you have two outdoor AIR units, for example, only one (the one designated “primary”) will populate the “barometric_pressure” field (the “primary” flag is set at the parameter level, by the way). This federated station observation also returns a bunch of derived data (things the devices don’t measure directly), including sea level pressure.

With that, note that it’s only in the station observation where we distinguish between indoor and outdoor measurements - there is currently zero or one of each, depending on your station’s configuration. Both fields are contained in the “obs” object, so they can’t have the same name. We haven’t actually fully fleshed out the whole “indoor” definition of that object yet, however, since the vast majority of users don’t have an indoor device. So, consider it a draft and expect some weirdness.

Finally, to hopefully clear up the current confusion about this renaming: the only place in the API where we are changing the string “barometric” to “station” is in the station observation, not the device observation. @GaryFunk is correct: there’s no need to change the name in in the device observation. In fact, there’s only one “pressure” value in that observation, and it’s not labeled (except in the documentation).

1 Like

Ahh, now I understand your methodology. Yes, this could get rather confusing.

If you have two outdoor Air units, will the second be named with the “_outdoor” sufix?

It could, but only if we change the definition. Currently, the second value simply wouldn’t be there, because we’ve defined the station observation to have only one set of outdoor parameters (temp, humidity, wind, etc.).

You can tell individual units apart by the serial number in the observations, but that wouldn’t tell you indoor or outdoor (I can’t find a location element in either schema in the published UDP docs online). Of course that wouldn’t get you ‘which’ outdoor Air easily even if there was a location element in obs_air.

Possibly related. I notice that obs_air’s “obs” element is an array. Unfortunately the serial number of the air is outside that array. If it was ‘inside’ the array than obs_air would be an array of the observations for however many units you have. Same would go for a multi-Sky setup. Just a thought…

So

{
	  "serial_number": "AR-00004049",
	  "type":"obs_air",
	  "hub_sn": "HB-00000001",
	  "obs":[[1493164835,835.0,10.0,45,0,0,3.46,1]],
	  "firmware_revision": 17
}

might be alternately shown as:

{
	  "type":"obs_air",
	  "hub_sn": "HB-00000001",
	  "obs":[["AR-00004049", 17, 1493164835,835.0,10.0,45,0,0,3.46,1]],
}

or something going down that road a bit…

You won’t. The Hub does not know those details. It only know which devices are connected. Just as the user have to enter configuration data for WeatherFlow, the used will need to enter information for the local UDP application.

I originally thought that was the reason for the array of arrays