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 Adrian,
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.
Thanks!
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?
1 Like
Hi Adrian. The preview api page appears to no longer display properly on any browser so I cannot really review it any more as I have in the past. I was going to check to see if there have been any added fields in the history data. Also, how much warning can we expect to have that the june2022 url will go away? Will there be a switch over period where both urls work or is it an event happening all at once on one day?
Thank you,
Kevin
1 Like
FYI… I also lost some time trying to use the ISO date (without time, I just thought start date would get the whole day). So it appears not all ISO formats are valid. Now I’m just using the timestamp (number) representing date and time and that works reliably so I’m no longer using ISO date time format.
1 Like
In the email you just sent announcing the update it sounds like you’re saying that all sensor data will no longer be available via api.thingspeak.com. Is that true? If so, a little more time and/or a clearer hard stop date would be helpful to ensure that developers using ThingSpeak can migrate without downtime.
I see the answer to my question in this thread.
Nevertheless, if you could be more precise about when ThingSpeak goes away that would be helpful.
Thank you,
Kevin
Would it be possible to have sensor index/memberID included in the output for requesting sensor history? As it stands, the rows of data that I retrieve have no unique identifier attached to them. If I was to simply combine two outputs from two different sensors, I would not know which sensor the data came from. That has thus far made it very challenging to compile the data into a useful format.
For example, my current R script is able to pull the most recent two weeks of hourly data for all of the sensors we have deployed. I’ve needed to save that data as separate csv outputs with the name of the sensor as the file name. If each row of data was attributed to one sensor index, I could instead bind all outputs into one file and manipulate that as needed. My ideal situation would be to have one single file with the headers sensor_index, pm2.5_cf_1_a , pm2.5_cf_1_b, temperature, humidity, etc, with the sensor data fields as hourly averages.
1 Like
Were you able to figure out a way to get sensor history for multiple sensors with a single API call? Or are you having to do them separately, and if so, are you not getting rate limited?
What I’m doing is making the API calls individually, but running them on a loop with a 2 minute pause between calls, so it’s only a few lines of code. That’s not (yet) resulted in me being rate limited.
1 Like
I like the idea of including the sensor_index or member_id in the csv.
We are not sure of when ThingSpeak will stop working. It depends on when the credits run out on the account.
1 Like
In GetSensorHistory, the CSV will now include the sensor_index in a column, and in the case of GetMemberHistory, the group_id and member_id in columns in the CSV.
2 Likes
The historical API is going to be released on July 18, 2022. This means that the URL will switch to api.purpleair.com from june2022.api.purpleair.com. More information is available at the following post: New Version of the PurpleAir API on July 18th.
Another request for getting history of multiple sensors in a single call!
Good Morning,
I need help regarding downloading the purple air sensors data by the new path. Please, I need access to the data to download.
I need to download some application, to have access, since ThingSpeak is no longer working. Do I need to email contact@purpleair.com to get API keys? I’m lost… There’s an orientation of getting the historical data accessible through our new API at https://api.purpleair.com, but I can’t.
Thank you very much!
Hi, Yes, if you email them, they will provide a Read key to obtain historical PurpleAir data.
Otherwise for current data you can download from the individual sensors using the PurpleAir map.