# Heads-up: Forthcoming changes to API (REST & WS) **URL:** \ **Category:** Developers\ **Tags:** rest\_api, websocket\ **Created:** [May 24, 2019, 8:08pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601 "2019-05-24T20:08:48Z")\ **Posts on this page:** 20\ **Page:** 1
**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:** [May 24, 2019, 8:08pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/1 "2019-05-24T20:08:48Z")
In support of some forthcoming changes to the way rain accumulation is calculated and presented in our apps, we will be pushing an update to the API next week. This message is purposely vague as to exactly what is changing, but that will become clear soon. The goal of this post is to give you enough information to make sure nothing breaks in your apps when we push the changes. An important reason for this heads-up is that we will be removing two fields from the station observation: `precip_accum_last_1hr` and `precip_accum_last_24hr` - these guys were never officially documented, so hopefully none of your apps are using them. But please let us know if that’s not the case. The main purpose of this update is the addition of five new elements to the end of the “`obs`” array within the SKY observation ("`obs_sky`"). That is, this array will be growing from 12 elements to 17 elements with no change to the first 12 elements. You may also notice the addition of several new “`precip_*`” fields to the station observation response. Please ignore all of these new values for now. We will explain what they mean soon. Finally, there will also be some changes to the undocumented, unofficial “Summary Object” found in the AIR and SKY observation, but no one should be using those objects, right? If you are, please let us know ASAP. Note: These changes only affect the REST and WS interfaces. They do not apply to the UDP interface. Note also: These changes will not affect all devices at the same time. The number will start small and increase over time. ---
**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:** [May 24, 2019, 8:29pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/2 "2019-05-24T20:29:12Z")
---
**Author:** ![pierre](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/pierre/32/184_2.png) [@pierre](https://community.tempest.earth/u/pierre)\ **Post date:** [May 26, 2019, 4:58pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/3 "2019-05-26T16:58:02Z")
Hi @dsj! Thanks for the heads-up. Unfortunately I do… Actually I’m using `precip_accum_last_1hr` from the REST API in [Weather Station](https://weather.station.software) to: - provide “compatibility” (I should rather say “consistency”) with other brands of stations; - have the ability to push data of WeatherFlow stations to [Met Office WOW](https://wow.metoffice.gov.uk/) and [PWS Weather](https://www.pwsweather.com/). That’s a huge deal for me if this field disappears in the next week, I think. I have written the more “shock proof” code I can from my side, but I don’t know what will be the behavior of the ingestion systems from Met Office and PWS Weather if this field is missing or inconsistent… I will do an impact assessment tomorrow and I will let you know. Will this field be replaced by something equivalent? Thanks. Pierre ---
**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:** [May 26, 2019, 5:52pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/4 "2019-05-26T17:52:52Z")
> [@dsj](#): > > They do not apply to the UDP interface. In the past you added ‘null’ values to the packets to keep the array the same in WS and UDP packets. Will you maintain that with the new changes? If not please do so. This way we can use the same routines to parse WS and UDP packets. ---
**Author:** ![peter](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/peter/32/1365_2.png) [@peter](https://community.tempest.earth/u/peter)\ **Post date:** [May 26, 2019, 6:15pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/5 "2019-05-26T18:15:41Z")
> [@dsj](#): > > Finally, there will also be some changes to the undocumented, unofficial “Summary Object” found in the AIR and SKY observation, but no one should be using those objects, right? Hi @dsj, I’m afraid I use fields from the “Summary Object” as well. In particular, I use ‘strike\_last\_epoch’, ‘strike\_last\_dist’, and ‘strike\_count\_3h’ from the summary provided in the SKY websocket message. I do this because it saves me an API call every minute to get the same details from the Station Observation endpoint. Can you let us know what the changes are going to be so we can plan to make changes to our applications is necessary? ---
**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:** [May 26, 2019, 11:39pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/6 "2019-05-26T23:39:03Z")
Since you are using web socket data why are you not using the strike event packets? ---
**Author:** ![peter](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/peter/32/1365_2.png) [@peter](https://community.tempest.earth/u/peter)\ **Post date:** [May 27, 2019, 7:45am UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/7 "2019-05-27T07:45:31Z")
I actually use both the strike event packets and the summary provided in the SKY websocket message. The reason is that the strike event packet doesn’t tell me about past events, or the number of strikes in the last three hours. So when the console first runs, it takes the ‘strike\_last\_epoch’ and ‘strike\_last\_dist’ of the last recorded strike from the SKY summary. Then for all following strikes, it uses the data in the strike events packet. As for the ‘strike\_count\_3h’, this is only provided by the SKY summary message. ---
**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:** [May 27, 2019, 11:52am UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/8 "2019-05-27T11:52:01Z")
I understand. I have the same issues with UDP data. I want an API where we can query data per time period. I ended up grabbing the Archive data for the last three hours and store it in an array. Then push and pull data. It works but is a lot of extra initial work. ---
**Author:** ![pierre](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/pierre/32/184_2.png) [@pierre](https://community.tempest.earth/u/pierre)\ **Post date:** [May 28, 2019, 10:13pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/9 "2019-05-28T22:13:40Z")
So, I’ve made my impact assessment. From a data sharing point of view, it’s not really annoying: for Met Office WOW and PWS Weather, this value is not mandatory. Even if I think it can modify some graphs for PWS Weather, this is not so catastrophic as what I had envisaged at first. 😉 Finally, what is more annoying, is the disapearing of this value to compare stations directly in Weather Station. Will this value be replaced by something similar? Thanks. ---
**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:** [May 29, 2019, 1:14am UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/10 "2019-05-29T01:14:40Z")
My HomeSeer plug -in does make use of the precip\_accum values but not in a user visible way. However, removing them will require me to update the plugin. Also, I suspect changes to the summary oject will also cause problems ans I am desearializing that using C# classes and the data types need to match or the deserialization fails. I’m currently traveling out of the country with very poor internet access and may not be able to update my programs for a couple of weeks. ---
**Author:** ![veteranweatherman](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/veteranweatherman/32/235_2.png) [@veteranweatherman](https://community.tempest.earth/u/veteranweatherman)\ **Post date:** [May 29, 2019, 2:43am UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/11 "2019-05-29T02:43:00Z")
Hi, yes I’m using both the fields `precip_accum_last_1hr` and `precip_accum_last_24hr` to upload data to Met Office (WOW), Open Weather Map (OWM) and PWS Weather and would like the retention of those fields. Cheers Ian ---
**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:** [May 29, 2019, 8:32pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/12 "2019-05-29T20:32:01Z")
Ok, thanks for the feedback. We’re going to hold off removing anything for at least 30 days. Lightning strike info is not changing. We can probably keep the hourly precip values intact, since those are relatively easy to maintain. The 24hr versions are becoming a little unwieldy to support, however, so we’re going to need to drop them (and a few others - see below). We are going ahead with the adds very soon (see below). @bpaauwe let us know when you’ve updated your plug-in. @veteranweatherman can you work-around not having the 24hr values in there? **Here is the full list of proposed ADDS, which should happen tomorrow (the meaning of these values will be explained at a later date - ignore them for now):** To be ADDED to the `obs[]` array within the SKY `obs_sky{}` object (REST & WS): - index 12: Precipitation Type - index 13: Wind Sample Interval - index 14: Precipitation Accumulation Final - index 15: Local Day Precipitation Accumulation Final - index 16: Precipitation Analysis Type To be ADDED to the station observation response (REST): - `precip_accum_local_yesterday_final` - `precip_analysis_type_yesterday` - `precip_minutes_local_day` - `precip_minutes_local_yesterday` - `precip_minutes_local_yesterday_final` **And here is the full list of proposed REMOVES, which will happen in a couple weeks:** To be REMOVED from the station observation (REST): - `precip_accum_last_24hr` To be REMOVED from the undocumented `summary{}` object in the SKY device observation (REST & WS): - `precip_total_24h` - `precip_high_24h` - `precip_high_epoch_24h` To be REMOVED the undocumented `summary{}` object in the AIR device observation (REST & WS): - `pressure_high_24h` - `pressure_low_24h` ---
**Author:** ![peter](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/peter/32/1365_2.png) [@peter](https://community.tempest.earth/u/peter)\ **Post date:** [May 29, 2019, 9:33pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/13 "2019-05-29T21:33:38Z")
> [@dsj](#): > > Lightning strike info is not changing Thanks for keeping us in the loop. I shouldn’t have to make any changes to the PiConsole. ---
**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:** [May 30, 2019, 3:43pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/14 "2019-05-30T15:43:07Z")
> [@GaryFunk](#): > > In the past you added ‘null’ values to the packets to keep the array the same in WS and UDP packets. Will you maintain that with the new changes? Sorry, I forgot to answer this yesterday, Gary. The answer is yes. ---
**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:** [May 30, 2019, 4:21pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/15 "2019-05-30T16:21:29Z")
> [@dsj](#): > > The answer is yes. Just so everyone, mostly me, is clear, there will be UDP changes in a future firmware so the obs array indexes match. ---
**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:** [May 30, 2019, 5:07pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/16 "2019-05-30T17:07:23Z")
Correct. If we add fields to the `obs[]` array in the UDP obs\_sky message, we will pad it with nulls for these api-level additions in order to keep the two obs\_sky objects compatible. Another way to say it is that the length of the `obs[]` array may differ, depending on where you see it, but the meaning of any particular element of that array will always agree. Clear? ---
**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:** [May 30, 2019, 5:10pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/17 "2019-05-30T17:10:51Z")
What you said is clear but I am more concerned with the length of the obs[[]] being the same so the same code can be used to extract data and not be dependent on where it came from. ---
**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:** [May 30, 2019, 5:33pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/18 "2019-05-30T17:33:00Z")
Eventually the obs arrays will all match but hopefully your code can handle variable length arrays, which can happen for different reasons (old firmware, etc.) ---
**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:** [May 30, 2019, 5:36pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/19 "2019-05-30T17:36:55Z")
Of course it can. But as everything else, I spend more on error checking code than on actual data. 😄 ---
**Author:** ![pierre](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tempest.earth/pierre/32/184_2.png) [@pierre](https://community.tempest.earth/u/pierre)\ **Post date:** [May 30, 2019, 7:56pm UTC](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601/20 "2019-05-30T19:56:58Z")
> [@dsj](#): > > We can probably keep the hourly precip values intact, since those are relatively easy to maintain. That’s great news. Thanks for the clarification @dsj 🙂 Now we look forward, with confidence, to the definition of the new fields 😇 [Next page](https://community.tempest.earth/t/heads-up-forthcoming-changes-to-api-rest-ws/3601.md?page=2)