This has now been fixed.
I’ve been running a small daily job against the new
history/csv endpoint where I request the previous day’s 10-minute averages for 6 outdoor sensors. Today I noticed the CSV files had all doubled in size - turns out they all contain 2 rows for each distinct timestamp.
Thanks again for all the help!
Hi @r1yk, thank you for making us aware of this issue. It should now be fixed.
Would it be possible to include an example of how an ISO 8601 datetime string should look in the request? I’ve had no issue using UNIX timestamps, but I’ve not had success with the ISO format (e.g. 2022-06-27T15:46:23 or 2022-06-29T16:04:59Z or 20220629T154620Z). The API only returns an invalid timestamp errors.
Your example of “2022-06-29T16:04:59Z” does work, the others do not. Can you share your whole request (minus your API key)?
Thanks Adrian - I retried with that specific format and did get the response I was expecting.
Currently ThingSpeak stores sensor data in four channels (Primary / Secondary A&B). The Sensor data download tool from the PurpleAir map also provides the sensor data in four csv files. Since the new API will provide all sensor data in one row, will the sensor download tool eventually provide all data in a single file? Currently my downstream processing software assumes four files and I prefer for it to work the same regardless of if the data is obtained from the sensor download tool or from my application. Your reply will help me decide how to modify my software.
The new API Get Sensor History endpoint indicated that “10 minute average history maximum time span is three (3) days”. Will this limitation exist in the final API? This is a limit of 432 records per call. For one month of two minute data this would mean 50 requests per sensor. By comparison ThingSpeak limits rows per call to around 8000.
Will there be published API rate limits?