Hello,
Our research group found some bugs in the Aircare API, in particular in the /getmeasure part:
1) When trying to retrieve CO2 data on the web page (using the Try It Out button), that fails because of a buggy curl request: CO2 is wrongly written with a number Zero (C02), while it should be with the letter O. Lowercase letters also work (i.e., co2 works, but not with the number Zero, c02 is also incorrect). When we used either CO2 or co2 in the curl request, that worked (could not test that on the web page but curl commands now work in Windows 10, in the Command Prompt).
2) Due to the limit of max 1024 data points per parameter per device downloaded each time, we developed a MatLab script and functions to download all data for all parameters from all our devices (3 per test group member). That initially worked, but then, despite asking for the "max" temporal resolution each time and despite pausing for 1 second between two downloads, the API started making a huge time (and data) gap between the last two points. For example, if time stamp #1023 is 23-Jan-2023 01:40:01 +0000 (Unix UTC Time is converted to datetime format), the next time stamp #1024 is 24-Jan-2023 23:03:51 +0000. That's almost 2 days of data being skipped. The issue is NOT solved if I set a lower limit for one download, e.g., 1000 data points at a time. The data, however, is there on the server because we have downloaded them OK in our earlier attempts. So far, I don't get that issue on all parameters and for all sensors. For example, so far, my Temperature, Relative Humidity, and Pressure data are downloaded completely with ~5-min resolution, for all 3 devices. But recently, I get gaps in the CO2 and Noise data for two sensors.
Please see attached screenshots.
Buggy Aircare API
Buggy Aircare API
- Attachments
-
- Strange NetAtmo API Behavior.png (117.09 KiB) Viewed 1301 times
-
- CO2 and not C02.jpg (180.74 KiB) Viewed 1301 times
-
- CO2 and not C02_.jpg (487.19 KiB) Viewed 1301 times
Re: Buggy Aircare API
Hello,
Thanks for the feedback
For the 1st point, it's just a typo error in our documentation. I opened an internal ticket for the correction
For the 2nd point, we didn't manage to reproduce it. If you still face it, I advise you to try to improve your calls by asking for less than 1024 measures by putting precise begin/end dates
You could also try to do a call on 24h (with a precise begin/end date) and a "max" scale to see if there is a problem
Have a good day,
Leslie - Community Manager
Thanks for the feedback
For the 1st point, it's just a typo error in our documentation. I opened an internal ticket for the correction
For the 2nd point, we didn't manage to reproduce it. If you still face it, I advise you to try to improve your calls by asking for less than 1024 measures by putting precise begin/end dates
You could also try to do a call on 24h (with a precise begin/end date) and a "max" scale to see if there is a problem
Have a good day,
Leslie - Community Manager
Re: Buggy Aircare API
Hello Leslie,
Thank you for response. I tried asking for less than 1024 points at once (e.g. 1000, 500, 100) in my MatLab script but the result was the same: there was a huge leap in time between the N-1-th and N-th data point.
Requesting data between two specific (Unix) datetimes is programmatically demanding but I will give it a try and will let you know the result by writing again in this forum thread.
Best regards,
Georgi
Thank you for response. I tried asking for less than 1024 points at once (e.g. 1000, 500, 100) in my MatLab script but the result was the same: there was a huge leap in time between the N-1-th and N-th data point.
Requesting data between two specific (Unix) datetimes is programmatically demanding but I will give it a try and will let you know the result by writing again in this forum thread.
Best regards,
Georgi
Re: Buggy Aircare API
Hello again Leslie,
My MatLab scripts give again the full record for each parameter from each of my 3 devices, after I started specifying not only 'date_begin' but also 'date_end' in the cURL request. Now, I request 24 h of data at a time at 'max' temporal resolution ('scale'), that is ca. 288 meas. points per parameter per day.
This is a bit complicating, as one must specify the exact starting datetime stamp (Unix UTC time in seconds) for each device, in case they installed those more than 24 h apart. (I am lucky to have started all 3 within just 1-2 hours on the same day.)
Plots of my complete data so far are attached below.
Have a nice WE,
Georgi
My MatLab scripts give again the full record for each parameter from each of my 3 devices, after I started specifying not only 'date_begin' but also 'date_end' in the cURL request. Now, I request 24 h of data at a time at 'max' temporal resolution ('scale'), that is ca. 288 meas. points per parameter per day.
This is a bit complicating, as one must specify the exact starting datetime stamp (Unix UTC time in seconds) for each device, in case they installed those more than 24 h apart. (I am lucky to have started all 3 within just 1-2 hours on the same day.)
Plots of my complete data so far are attached below.
Have a nice WE,
Georgi
- Attachments
-
- Georgi dB by 15-10PM UTC on 03 Feb 2023.png (427.49 KiB) Viewed 1068 times
-
- Georgi T by 15-10PM UTC on 03 Feb 2023.png (502.79 KiB) Viewed 1068 times
-
- Georgi CO2 by 15-10PM UTC on 03 Feb 2023.png (572.43 KiB) Viewed 1068 times
Reproducing the Bug in Aircare /getmeasure
Hello again,
I was able to reproduce the bug in /getmeaure (that appears only for some of my devices, and only for some parameters of those, for example T, RH, and pressure always work well for all devices, but CO2 and Noise fail on some devices). This is how: for my device in the Kitchen, MAC address 70:ee:50:7c:a2:b8, request Noise data with 'max' temporal resolution/scale, with neither Start nor End datetime, no limit (defaults to 1024 meas. points), real_time on.
See screenshots below (note the huge time leap between the last-but-one and the last meas. point).
I was able to reproduce the bug in /getmeaure (that appears only for some of my devices, and only for some parameters of those, for example T, RH, and pressure always work well for all devices, but CO2 and Noise fail on some devices). This is how: for my device in the Kitchen, MAC address 70:ee:50:7c:a2:b8, request Noise data with 'max' temporal resolution/scale, with neither Start nor End datetime, no limit (defaults to 1024 meas. points), real_time on.
See screenshots below (note the huge time leap between the last-but-one and the last meas. point).
- Attachments
-
- Bug in getmeasure - Noise - Netatmo__.png (191.09 KiB) Viewed 1066 times
-
- Bug in getmeasure - Noise - Netatmo_.png (203.09 KiB) Viewed 1066 times
-
- Bug in getmeasure - Noise - Netatmo.png (152.62 KiB) Viewed 1066 times