Websocket Request


Is it possible (yea, I know 'anything is possible)… to have a single websocket call to a Station ID to get all observations for that station? Instead of requesting obs_air, obs_sky and/or rapid_wind by Device ID. How about requesting all of those by Station ID?



One issue with that is multiple devices attached to one station. It throws off the common format though there may be a work around. It also throws off the timing of the observation.

However, David did hint at something similar in this post: Feedback (and question) about REST API for historical data use case


Yes, it’s coming! The “station observation” (aka the “federated data object”) that you see for the current conditions will eventually be a time-series available via REST and WS. And we suspect that will be the primary way most apps get their data, using the “device observation” for more advanced operations.


That sounds fantastic!

Is there also going to be a “federated data object” for UDP data too? Right now it is fairly easy to use the same function to extract data from either a websocket object or a UDP object as they are almost identical.

I realize that I can continue to use the existing API’s, but there are some advantages to using the federated object even if some of the UDP fields are blank.


Remember, the API and web socket have and will have data not available from UDP.


Hence, why I wrote

That’s even true today with the individual device observation data. I think it’s fine to leave UDP data blank for fields that are calculated on the server. It would be nice to be able to continue to use the same data structures and parsing functions for both websocket and UDP like I do today for the device based data objects.

I also realize that it adds some complexity to combine sensor data, but it’s a case where it can be done once in the hub vs. multiple third party developers having to do it so it makes sense to me. (says the the third party developer who then doesn’t have to write the code :wink:)


Since obs in an array of arrays it would be simply to add additional data array data as obs[1][data],obs[2][data], etc.

This would not break current code and allow for future expansion. I’d enjoy having more data. My only issue will be getting the users to update the tables with the new fields.

No matter what WeatherFlow does, it will be easier than dealing with USCIS and NVC the past 12 months.

I’m happy either way.


We don’t have that on our roadmap since it takes a bit of application level logic to create the federated observation and we are trying to keep the hardware free of such. That’s not just the derived metrics but also things like which sensors are considered “primary” when there’s more than one. I can see how it would be convenient, though!


If WeatherFlow would share the code used to convert the UDP data to the additional values, the third-party developers would be able to supply the same data locally and not need the Hub to do the work.


Those additional values are published on the Derived Metrics page. But an increasing amount of data in the “federated observation” (and other data available via the API) will include input from other processes and data sources that the Hub doesn’t have access to. The data from a single smart weather station is just one piece of input to the overall system! That code also includes a range of “secret sauce” - aka, proprietary intellectual property that we need to protect. :slight_smile:


As we discussed in the past, when will that page be updated?

No one is asking for your proprietary intellectual property, just everyday formulas that you use that are not proprietary intellectual property.


It’s on the list, Gary, along with updating the API docs. Neither of those things is super high priority though. If there’s a specific formula you need, let me know!


Not so much a direct formula but if it’s not proprietary,

How is Solar Radiation derived from the Broadcom sensor?


That’s proprietary :wink:


Thank you. That’s an answer we can live with…