Peter, congratulations: you are the first developer (to my knowledge) to ask for this “station/observation timeseries” end point, which is something that we perceived as important, and has been on our featuer backlog, since Day 1.
As you clearly understand, the concept of the “station observation” is to aggregate or federate the data form multiple sensors at a single station into a uniform set of data. We also add “derived parameters” to this data, since some of those derived values require data from more than a single sensor device.
So, the answer is yes! We will have this feature one day. It has remained on our backlog at a relative low priority because, until this post, no one had asked for it… But now someone has, and we will consider that when we next look at moving tasks from the backlog to the “doing” list.
As Gary pointed out, in order to simulate this data construct, you need these formulas for the derived metrics and you pull values from the AIR or SKY as necessary. If there are more than one AIR or SKY, you have to choose one to use. We have a “primary” sensor concept on our back-end that we have not surfaced to the user (or the developer), yet, simply because not many people have more than one of each device. That is also on our backlog!
Meanwhile, your application would need to have a way to choose (or let the user choose) which device to use. Gary’s suggestion to use the lowest device_id will work for the vast majority of users. That’s how we do it currently: if a station has more than one AIR or SKY, the sensors from the lowest device_id become the primaries, by default. And only a handful of people have asked us to switch that.