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?
–Sam
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 
)
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!