Rest API with time_start and time_end

Sorry slightly confused now! Are you saying start_time and end_time are behaving as they should, or are they still cutting out data that should be included? Perhaps post an example of the API call you are using.

For example:

https://swd.weatherflow.com/swd/rest/observations/device/1110?api_key=20c70eae-e62f-4d3b-b3a4-8586e90f3ac8&time_start=1524022200&time_end=1524033360

Yes, It does seem that the start_time and end_time are working now. They were not this morning… but are now.

I am using the same call you are… just with my key and device id.

1 Like

Ah OK. I need to do some testing myself, but if you are using the exact API call I posted, then it will definitely work (@corrineb posted it to illustrate the bug). I’m pretty sure if you change the start time to anything other than 1524022200 it will revert to the old behaviour where the data doesn’t start at the requested time.

I will double check my code again. But I’m pretty sure that I’m requesting data from now until 60 minutes ago.

It was not working this morning when I originally posted but it seems to be now.

1 Like

Some quick testing here. If I use time_start and time_end to get data between NOW (06/12/2018 @ 10:03am [UTC]) and 3 HOURS past (06/12/2018 @ 7:03am [UTC]):

https://swd.weatherflow.com/swd/rest/observations/device/1110?api_key=20c70eae-e62f-4d3b-b3a4-8586e90f3ac8&time_start=1528787008&time_end=1528797808

I get data starting at 06/12/2018 @ 7:15am [UTC] and ending at 06/12/2018 @ 10:03am [UTC].

Therefore I am still missing data from the start of the request (~12 mins), but it does indeed provide data right up until NOW.

Right now, I am consistently missing the first 9 minutes of data.

At 2 hour, I am missing 9 minutes.
At 1 hour, I am missing 9 minutes.
At 30 minutes, I am missing 9 minutes.
At 15 minutes, I am missing 9 minutes.

Just noticed that is looks like the returned start times are pushed to the next 15 minute marker…

Requested 5:21 returned 5:30.
Requested 5:51 returned 6:00.
Requested 7:21 returned 6:30.
–Sam

1 Like

And a request for 5:31, returns 5:45.

1 Like

That’s a good spot, and I thought you had spotted some repeatable behaviour that would make a work around easier. However, I then ran this API request:

https://swd.weatherflow.com/swd/rest/observations/device/1110?api_key=20c70eae-e62f-4d3b-b3a4-8586e90f3ac8&time_start=1528676460&time_end=1528797808

The specified start time is 2018-06-11 00:21:00 (UTC) and the first data is at 2018-06-11 00:25:00 (UTC). There is only 4 minutes missing and it is not rounded to the nearest 15 mins.

Basically there is some very weird behaviour in the API that needs fixing before this feature (specifying time_start and time_end) will become usable/useful!

1 Like

Seems there is some other threshold which causes the returned times to be using a ‘bucket_step_minutes’ of 5 minutes instead of 1 minute.

Using day_offset returns 1 minute data, while start & stop time return either 1 or 5 minute data… depending on the duration requested…???

Your query returns 5 minute data, which could explain the first time returned to be a on a 5 minute marker.

1 Like

As a Feature Request, I would vote for accurate time period request, with a 3-second gap… if possible.
–Sam

1 Like

Another anomaly, requesting time-framed data from an AIR only returns the latest… but requesting a day-framed data set returns data as expected.

2 Likes

Ultimately I would like the see the API reflect the way the graphs work on the Smart Weather app/website. As you press the " - | + " buttons the temporal resolution changes along with the length of the data archive bins: 1day | 3hour | 30min | 5min | 1min. Whatever temporal cutoffs are used on the graphs to define the appropriate data archive bin, the same cutoffs should be applied to the API when using time_start and time_end. Obviously it would also be nice to have a 3 second archive bin for the API, as that doesn’t exists for the Smart Weather app / website graphs.

I’m sure WF will get round to this, it is just more important for them at the moment to be focusing on shipping rather than enhancing the behaviour of the API! :grinning:

1 Like

Totally agree.

I would like some input from WF on this issue.

I am implementing the Sager forecaster, and need to access historical wx data from WF… and having this fixed would be uber-helpful.
–Sam

2 Likes