Feature request - add elevation data to device status or observation UDP data

Developers
1

In looking at the derived formula page, I notice that there is no way via the UDP API to calculate sea-level pressure, as the following data is not in anything emitted by the UDP API:

  • ground elevation in meters (sky)
  • station height above ground elevation in meters (sky)

Is this something we can get added to the UDP API ? I’d like to be able to calculate everything from the UDP data without needing to contact the WF servers at all.

(also, a quick scan at the REST API examples seems to indicate you might want to take a look there too. There seems to be the concept of a station elevation, but it’s not clear what device(s) that value would correspond to).

3 Likes
2

Agree, this would be nice to have. For most of what I’ve been working on, I have a goal to have no Internet dependency. So ideally, the hub should have all configuration information available for applications.

1 Like
3

The station elevation refers to ground level at the location of the station. Under each device, there is another field called agl that gives the height of that device above ground level. Therefore the height of each device is station elevation plus the value in the agl field for each respective device.

Example station elevation:

<station_meta>
 		<share_with_wf>true</share_with_wf>
 		<share_with_wu>false</share_with_wu>
 		<elevation>71.64869689941406</elevation>
</station_meta>

Example device agl:

<device_meta>
		<agl>1.75</agl>
		<name>Air</name>
		<environment>outdoor</environment>
		<wifi_network_name></wifi_network_name>
</device_meta>
4

oops - thanks for that one - so it’s in the REST API…

…but again, my goal is to be able to duplicate all the derived measurements using ‘only’ the data in the UDP broadcast messages. If we use weewx as the secret sauce it ‘can’ do that since you configure the station elevation in weewx.conf, but those of us trying to do node-red or grafana or custom code to do so via UDP only are kind of out of luck at the moment…

5

The important concept here is that “elevation” and “agl” (along with “lat”, “lon”, “indoor/outdoor” and several other user-level settings) is part of a station’s or device’s “metadata” and the Hub is unaware of most metadata. The metadata is essentially application-level information that the hardware doesn’t know (nor need to know).

2 Likes
6

True, the hardware doesn’t need to know it but applications do, and that’s the point. When the user sets up a station, they’re either configuring those values or they’re added automatically as part of the configuration process. That information is now stored in the “cloud”. But many of us want to avoid the dependency on the “cloud” or don’t even have Internet access at the location where the station is installed. For those cases, the user then needs to enter all of that information again for any third party applications they want to use.

It would make for a much better user experience if the third party applications had a way to access that meta data directly from the hub. We’re not talking about a lot of data, probably only a few 10’s of bytes. The additional code to supply should also be minimal.

7

@dsj - “The metadata is essentially application-level information that the hardware doesn’t know (nor need to know)”

understand, though disagree… if there is a design goal enable app developers to do everything UDP only (which I think you’ve at least strongly implied for a long time), then you need to give us more data in the observations and/or status messages so we can develop our standalone apps to do so…

1 Like
8

The Hub doesn’t know about that data and as designed does not have a method to store that data.

The Hub has limited memory and taking valuable memory space for the data and code required to store and transmit these items may do more harm than good.

9

Oh I dunno how getting the one missing piece of info needed to make the udp api feature complete will be the end of the world.

It’s a feature request for WF. Their call if and when.

10

No one has stated it would be the end of the world.

By-the-way, this feature and more have been asked for by several of us over the past 18 months.

And I am not disagreeing with you. I wanted this last year.

11

Impossible to know what was requested without a public bug/feature/to-do list.

12

There is a sample of the data that has been requested and it’s 1,012 bytes.

{“location_id”:1878,
“name”:“Alpers Farm, Littleton, Colorado”,
“public_name”:“Alpers Farm, Littleton, Colorado”,
“latitude”:39.60306,
“longitude”:-105.11847,
“timezone”:“America/Denver”,
“elevation”:1744.0656215548515,
“station_units”:{“units_temp”:“f”,“units_wind”:“mph”,“units_precip”:“in”,“units_pressure”:“mb”,“units_distance”:“mi”,“units_direction”:“degrees”,“units_other”:“imperial”},
“devices”:[
{“device_id”:3336,“serial_number”:“HB-00004516”,“device_meta”:{“agl”:0.0,“name”:“HB-00004516”,“environment”:“indoor”},“device_type”:“HB”,“hardware_revision”:“0”,“firmware_revision”:“94},
{“device_id”:10470,“serial_number”:“AR-00005119”,“device_meta”:{“agl”:3.04800003767014,“name”:“Air NW”,“environment”:“outdoor”,},“device_type”:“AR”,“hardware_revision”:“1”,“firmware_revision”:“20”},
{“device_id”:11971,“serial_number”:“SK-00000730”,“device_meta”:{“agl”:6.09600007534027,“name”:“Sky NW”,“environment”:“outdoor”,“wifi_network_name”:”"},“device_type”:“SK”,“hardware_revision”:“1”,“firmware_revision”:“43”}
]}

1 Like
13

You can get a good idea by just reading through the posts.

But again I agree. I would love to see a list of requests. Unfortunately, Discourse is just not designed for that that.

2 Likes
14

At this point (and back when @GaryFunk made the request a while back) the @WFmarketing response is that this feature won’t be added. The primary reason seems to be because they don’t believe the hub should know this information. If it is physically impossible because of lack of storage space or code size restrictions, please let us know as there’s no reason to try and lobby for this is that’s the case.

I’d like to make one more pitch and see if I can provide enough justification. I’ll even provide an example of how this does directly impact user experience.

Because I plan to install a station at a location that has neither cell phone coverage nor Internet access, making applications that work in this environment is a high priority for me personally. For the every application I’ve created, including the HomeSeer plug-in and ISY node servers, I have to include user interface code that allows the user to enter elevation and preferred units information. In addition, I have to add code to query the servers to pull this information to auto-populate these settings so that the user experience is acceptable. That’s a fair amount of effort and coding for every application I create. So that’s a very direct effect on me, a third party application developer. It is also an opportunity for me to introduce bugs that take time and effort to resolve.

So how has this effected users? As a software developer I tend to follow a somewhat agile release process. Start releasing when it is functional and incrementally add features in each release. Thus for most of these applications, a version gets released with manual entry of configuration prior to a release with the ability to query the servers. Between these releases I have had user’s that compare the barometric pressure between my application and the WeatherFlow App and notice slight differences. Those differences are there because the manually entered elevation doesn’t match exactly the elevation in the station meta data. Just seeing the difference raises questions on the reliability of the data which is something I think we’d all like to avoid if possible.

We all want all the data, but that doesn’t always make sense from a business perspective and just providing a couple of bits of the information that’s most useful may cover 90+% of the use cases. For me, knowing the station elevation, the Air AGL, and the user’s preferred units would be sufficient.

And I’m not buying the argument that the hub doesn’t need to know this info, the hub doesn’t need to know much, maybe just WiFi SSID, password and server IP/name, everything else is just to make the experience better for either WeatherFlow or the users.

3 Likes
15

Since no one addressed this part, it is the ground elevation in meters above standard sea level. Then each device has a height, in meters, above ground level.

16

I didn’t read that in David’s response. What I read was why ‘historically’ it has not been available up to now.

In the absence of published implementation gory details, I’m not buying that this one can’t be done for technical reasons nor that there is inherent risk in theoretically doing so.

There have already been lots of posts saying that the APIs are going to change (someday), so lets try to get this one into the ‘next train leaving the station’ so to speak before too many developers need to cook up workarounds.

17

You left out that his statement is based on past responses from WeatherFlow.

18

Gary you can choose to argue and seemingly defend WF, but about 3000 of us were ‘not’ around back in the alpha/beta days and simply are unable to find the thread of every discussion that has happened for a couple years thus far.

And regardless, answers change as more use-cases and explanations appear. Then was then. This is now. I’m asking for today’s updated confirmation that the answer isn’t gonna change.

19

I am not arguing.

This is what Bob wrote. He stated about the past. You quoted it and cut that part out.

This forum is only 10 months old.

20

Just to clarify, I did go dig up the old post that @GaryFunk made back in March where he requested this (and more). @WFmarketing responded and marked the feature request as solved. To me, marking it as solved without actually doing anything implies that they aren’t planning to add this. See Store variables on the Hub - #5 by dsj for all the details.

@vinceskahan, I agree with you. To date they have not provided any technical reasons why this can’t be done, hence my attempt to provide more justification why it should be re-considered.

Since the initial request in March, there are more users and more third party developers interested in this capability, but we’re still getting essentially the same response as before. And the response, at least the way it is presented, implies that no engineering evaluation to determine technical feasibility or engineering cost has been performed yet.

2 Likes