# Websocket Request **URL:** \ **Category:** Developers\ **Created:** [January 29, 2019, 7:30pm UTC](https://community.tempest.earth/t/websocket-request/3066 "2019-01-29T19:30:34Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![btst.online](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/btst.online/32/16538_2.png) [@btst.online](https://community.tempest.earth/u/btst.online)\ **Post date:** [January 29, 2019, 7:30pm UTC](https://community.tempest.earth/t/websocket-request/3066/1 "2019-01-29T19:30:34Z")
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 ---
**Author:** ![GaryFunk](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/garyfunk/32/5729_2.png) [@GaryFunk](https://community.tempest.earth/u/GaryFunk)\ **Post date:** [January 29, 2019, 8:04pm UTC](https://community.tempest.earth/t/websocket-request/3066/2 "2019-01-29T20:04:12Z")
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](https://community.tempest.earth/t/feedback-and-question-about-rest-api-for-historical-data-use-case/2743/7?u=garyfunk) ---
**Author:** ![dsj](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/dsj/32/3_2.png) [@dsj](https://community.tempest.earth/u/dsj)\ **Post date:** [January 29, 2019, 9:45pm UTC](https://community.tempest.earth/t/websocket-request/3066/3 "2019-01-29T21:45:45Z")
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. ---
**Author:** ![bpaauwe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/bpaauwe/32/1056_2.png) [@bpaauwe](https://community.tempest.earth/u/bpaauwe)\ **Post date:** [January 29, 2019, 10:31pm UTC](https://community.tempest.earth/t/websocket-request/3066/4 "2019-01-29T22:31:58Z")
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. ---
**Author:** ![GaryFunk](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/garyfunk/32/5729_2.png) [@GaryFunk](https://community.tempest.earth/u/GaryFunk)\ **Post date:** [January 29, 2019, 11:44pm UTC](https://community.tempest.earth/t/websocket-request/3066/5 "2019-01-29T23:44:32Z")
Remember, the API and web socket have and will have data not available from UDP. ---
**Author:** ![bpaauwe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/bpaauwe/32/1056_2.png) [@bpaauwe](https://community.tempest.earth/u/bpaauwe)\ **Post date:** [January 30, 2019, 12:48am UTC](https://community.tempest.earth/t/websocket-request/3066/6 "2019-01-30T00:48:20Z")
> [@GaryFunk](#): > > Remember, the API and web socket have and will have data not available from UDP. Hence, why I wrote > [@bpaauwe](#): > > even if some of the UDP fields are blank 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 😉) ---
**Author:** ![GaryFunk](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/garyfunk/32/5729_2.png) [@GaryFunk](https://community.tempest.earth/u/GaryFunk)\ **Post date:** [January 30, 2019, 12:57am UTC](https://community.tempest.earth/t/websocket-request/3066/7 "2019-01-30T00:57:14Z")
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. ---
**Author:** ![dsj](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/dsj/32/3_2.png) [@dsj](https://community.tempest.earth/u/dsj)\ **Post date:** [January 30, 2019, 8:54pm UTC](https://community.tempest.earth/t/websocket-request/3066/8 "2019-01-30T20:54:48Z")
> [@bpaauwe](#): > > Is there also going to be a “federated data object” for UDP data too? 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! ---
**Author:** ![eric](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/eric/32/13553_2.png) [@eric](https://community.tempest.earth/u/eric)\ **Post date:** [February 28, 2019, 6:45pm UTC](https://community.tempest.earth/t/websocket-request/3066/9 "2019-02-28T18:45:09Z")
Split this topic on February 28, 2019, 6:45pm UTC 14 posts were split to a new topic: [Converting UDP to REST API values](https://community.tempest.earth/t/converting-udp-to-rest-api-values/3234)