Buggy Aircare API

The Netatmo API is a set of webservices allowing developers and third parties to access Netatmo device's data.
Post Reply
petaflops
Posts: 4
Joined: 27 Jan 2023, 18:05

Buggy Aircare API

Post by petaflops »

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.
Attachments
Strange NetAtmo API Behavior.png
Strange NetAtmo API Behavior.png (117.09 KiB) Viewed 1286 times
CO2 and not C02.jpg
CO2 and not C02.jpg (180.74 KiB) Viewed 1286 times
CO2 and not C02_.jpg
CO2 and not C02_.jpg (487.19 KiB) Viewed 1286 times
Leslie
Posts: 111
Joined: 12 Feb 2020, 11:07

Re: Buggy Aircare API

Post by Leslie »

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
petaflops
Posts: 4
Joined: 27 Jan 2023, 18:05

Re: Buggy Aircare API

Post by petaflops »

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
petaflops
Posts: 4
Joined: 27 Jan 2023, 18:05

Re: Buggy Aircare API

Post by petaflops »

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
Attachments
Georgi dB by 15-10PM UTC on 03 Feb 2023.png
Georgi dB by 15-10PM UTC on 03 Feb 2023.png (427.49 KiB) Viewed 1053 times
Georgi T by 15-10PM UTC on 03 Feb 2023.png
Georgi T by 15-10PM UTC on 03 Feb 2023.png (502.79 KiB) Viewed 1053 times
Georgi CO2 by 15-10PM UTC on 03 Feb 2023.png
Georgi CO2 by 15-10PM UTC on 03 Feb 2023.png (572.43 KiB) Viewed 1053 times
petaflops
Posts: 4
Joined: 27 Jan 2023, 18:05

Reproducing the Bug in Aircare /getmeasure

Post by petaflops »

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).
Attachments
Bug in getmeasure - Noise - Netatmo__.png
Bug in getmeasure - Noise - Netatmo__.png (191.09 KiB) Viewed 1051 times
Bug in getmeasure - Noise - Netatmo_.png
Bug in getmeasure - Noise - Netatmo_.png (203.09 KiB) Viewed 1051 times
Bug in getmeasure - Noise - Netatmo.png
Bug in getmeasure - Noise - Netatmo.png (152.62 KiB) Viewed 1051 times
Post Reply

Return to “Netatmo API”