Hello @WFmarketing !
What is quite strange is in REST APIs, you called the station pressure Barometric Pressure 
1 Like
In one way of thinking it is. Itās pressure at the barometer. 
2 Likes
Youāre right @GaryFunk 
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:
- 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] - 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
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 ) 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. 
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