First time post.
I’ve been glancing threw all the topics, if there is a similar topic, please point me to it.
Are there any intentions/desires to make it a dictionary of values rather than a array of values? I’m referencing this endpoint:
https://swd.weatherflow.com/swd/rest/observations/?device_id=[your_device_id]&token=[your_access_token
My question would change the “obs” array: [12345, 15,…] into { “epoch”: 12345, “temp”: 15, … }
Welcome to the community! To be honest I highly doubt this change will be made. It would be a breaking change for all the apps that are already in existence. If you want a dictionary type response, have a look at the “station” endpoint:
Do you use python? If so then it is quite straightforward to deal with the array format in question. If you’d like I can post an example that will, for example parse the shy obs array…?
If you’re using java, it can be done with jackson/lombok… I have an artifact that I created with gradle to do it… I could maybe post it. It’s more tedious than python.
I understand it would be a breaking change but there are ways around breaking the endpoint.
For example there could be a new version of the endpoint that publishes the new format of JSON.
I don’t have the most experience but I’m pretty sure having an array of values is not very common, even if they are documented. I’d be curious to know of any other services that publish data like this.
I can still work with the endpoint the way it is but I was just curious. The ability to integrate like this is awesome, don’t get me wrong, I love it. It’s just something I haven’t seen before.
Wouldn’t a dictionary of values be more data transmitted from the station? That could more than double the amount of data transmitted which wouldn’t be as efficient and would use up more data on metered connections.
Yeah, adding anything increases the size. From my calculations, I could be wrong, this is my findings.
I changed the “obs” payload to this and kept the rest of it the same:
{
“epoch”: 1609028605,
“pressure”: 971.4,
“airTemp”: 19.7,
“humidity”: 26,
“lightningStrikeCount”: 0,
“lightningStrikeAverageDistance”: 0,
“battery”: 2.9,
“reportInterval”: 1
}
This increases the size from 611 bytes per payload to 911 bytes.
If the station reports every second, this translates 1.58 gigs of data (current data from my station for latest observation with one value in the array) to 2.35 gigs in a month (30 days).
So it will increase data consumption by 0.77 gigs a month. This could be the reason why but I doubt it because the new endpoint for the forecast has all dictionaries of key-value pairs.
Specifically I’m referencing “/better_forecast”. I’m just curious if there is any plan for an update to the older endpoints with dictionaries.
Actually, it’s extremely common. What isn’t common is calling a structure of values a dictionary.
My apologies. I guess I should replace “dictionary” with “key/value pairs”.
@GaryFunk Where else have you seen an API return an array of just numbers/floats? I’m not trying to be rude, I simply haven’t seen it before and I’d love to learn/know where this is extremely common.
Like I said, I don’t have the most experience but I’ve used plenty of APIs.
It’s common JSON and used by hundredsbof thousands of websites that use Javascript. I’ve been using it longer than I can remember. Indexed arrays are used in every language I’ve used in the last 20 years.
@GaryFunk Alright well I’m not sure you understand my reason for posting. It sounds like you’ve interpreted my comments as having an array in JSON returned from an API is uncommon. That’s not what I’m saying. Maybe our lines are getting crossed somewhere because you seem irritable.
I’ve only ever been a native mobile dev and never touched a front end or backend of a website/server. Every API I’ve used in my career which is only 7 years, mostly corporate, has always had a key matched with a value in the JSON. It really helps when it comes to having a type safe language to work with. I’ve simply never seen an api like this one that returns an array of values with no keys.
I’m not saying what has been done is wrong but when trying to integrate this JSON into a project that has type safety built into the language, there are workarounds I have to do to get it to work. I was simply asking a question about if a new format has been considered and I don’t appreciate the impatience from you. You’re obviously liked in this community and have helped many people from looking at your profile so please give me the benefit of the doubt.
The array returned IS the value part of the Key/Value pair.
This is not uncommon (20+ yr SE experience speaking). I have seen tons of endpoints that supply an array like this in an effort to save ‘space’ when transmitting the data.
@GaryFunk is not being rude or belligerent… Just saying that some of us have more experience than others, and have seen more things in the SE world.
Ok so the answer is that WF has this format to save data on the network or is this just theory? I’ll accept that as an answer but have yet to have anyone with a definitive answer on the subject.
{edit} PS, I understand the array is the value. If you look at my original post, I clearly define my intentions with an example.
Basically, if I’m understanding you, you are a Python programmer, and you would like the data sent to conform to Python.
The data returned is an array of arrays. There are discussions on this from three years ago but I’m not sure they are public.
As far as being impatient, at times I am. On another point, I’ve been programming for 50 years. I cut my teeth on the IBM 360 and was fortunate to be given time on a Super Crey. Over the years I learned a programmer deals with data as it’s delivered and must be flexible.
But to your post, No. There is no plan to change the packet or add additional from the API. The packet structure is used for UDP, MQTT, web socket and the web API.
I’m happy to continue the conversation as it may benefit others but I doubt you will ever see a change.
If you are using Python, would you mind sharing your code so we can understand the workarounds you are having to use? I have used Python extensively with the API for the WeatherFlow PiConsole (WeatherFlow PiConsole), and have never had to implement any workarounds. I’d be interested to see the challenge you are coming up against.
I use Basic not Python or anything and because the forecast days/hours have integers and start at 0 I can only use the first one because I am unable to “decode” the JSON with these values, it only accepts it if it’s a name and not a numnber, it might even be possible if it didn’t start with a zeru
It might be that the data is actually a string and you need to convert it to a number. Without knowing which index you are referring I cannot give you a definitive answer.
Apologies, I had already overcome the issue I mentioned
The only other one I have is
"current_conditions":{"time":1609340340,"conditions":"Partly Cloudy","icon":"cc-partly-cloudy-day","air_temperature":3.0,"sea_level_pressure":1001.5,"station_pressure":989.4,"pressure_trend":"steady","relative_humidity":94,"wind_avg":1.0,"wind_direction":292,"wind_direction_cardinal":"WNW","wind_direction_icon":"wind-rose-wnw","wind_gust":1.0,"uv":0,"feels_like":3.0,"dew_point":2.0,"wet_bulb_temperature":2.0,"delta_t":0.0,"air_density":1.25,"lightning_strike_count_last_1hr":0,"lightning_strike_count_last_3hr":0,"lightning_strike_last_distance":31,"lightning_strike_last_distance_msg":"30 - 32 km","lightning_strike_last_epoch":1608416353,"precip_accum_local_day":0,"precip_accum_local_yesterday":0,"precip_minutes_local_day":0,"precip_minutes_local_yesterday":0,"is_precip_local_day_rain_check":false,"is_precip_local_yesterday_rain_check":false,"includes_station_data":true}The only way I can “decode” these are by using “word” such as
The problem with this is the number of items is not stable, it varies depending on if there is precipitation or not
At the moment there is 0% and the field containing “feels like” is now number 17 on the list wheres when there is a probability it becomes number 19
That’s not an indexed array. It is a structure of keys and values.
However, the values you are referring to are not integers but floating values.
I guess I’d like to see the data you’re seeing in both cases with/without precipitation.
Regardless, it’s well over two years since the Air/Sky systems reached production status, so it is rather unlikely that WF would agree to a breaking change in any API.
Anybody writing software that will run versus the published API needs to be able to handle what it returns, regardless of whether we’d individually have done ‘our’ API the same or not.
No two people would likely do it the same, unless you work for the other guy, in which case their answer is ‘your’ answer 
But it would be interesting to see two sets of data, one with and one without rain, so we can see what you’re talking about.
(BASIC ? That’s still a thing ? I’m thinking I might need to find my PDP-8 assembly language programming book if it hasn’t turned into a brick somewhere deep in the boxes in the garage. I know I haven’t seen the programs on paper tape in well over 40 years.)
Basic is still very much a thing even though I’m no expert and definitely a beginner, I had brain surgery and everytime I come back to programming I basically have to teach myself again
This is what I have done so far, this was a couple of weeks ago, I’ve since got rid of a few bugs, such as the wind pointer now points in the right direction (where it’s blowing to) and it just looks a bit better now
It’s all done in Basic - 17 inch hdmi monitor
