AirGradient Forum

API payload fields

For the payload that is sent to the Dashboard from the device, I see a few things I don’t understand.

We’ve always had pm01, pm02 etc, but now there is

    "pm01Standard": 1,
    "pm02Standard": 1.33,
    "pm10Standard": 1.33,

What are these standard entries used for? Currently they are matching my pm payload fields without standard in the name

I’m also pretty sure that the firmware field in the past was what we typically see, such as 3.3.7, but with my device running 3.3.7 what I’m sending is:
"firmware": "PMS5003x-151",

Is that intentional?

"resetReason": 1,
Is there a table of what these reason codes are? What does 1 mean vs a different number?

The plantower provides a 2nd value with some kind of internal calibration. We are sending it to the backend to understand better when it deviates from the other value. The value we use since long time is called “atmospheric” the other ”standard”. This is why we call it this way.

For the firmware we read out the value from the PM module to get a better understanding when plantower changes their fw version.

Wouldn’t the firmware of the Plantower be its own field such as ‘plantowner_firmware’?

How does the dashboard know what AirGradient firmware a device is running if that isn’t one of the fields being posted back? I thought that was send as part of the payload and then the dashboard could show if a device was out of date. Doesn’t a user need the send the firmware version with “-snap” at the end so it wouldn’t auto upgrade a users custom firmware?

@Samuel_AirGradient Can you please answer this?

Hi @MallocArray ,

From the beginning, we already using firmware as the field of PMS firmware version. AirGradient dashboard know all monitor firmware version from the request url when attempt to do OTA firmware update (http://hw.airgradient.com/sensors/airgradient:aabbccddeeff/generic/os/firmware.bin?current_firmware=3.1.21. And the current_firmware query value is shown as the current firmware version of the monitor. Note that it only apply for the official airgradient binary, not if you compile the code yourself since it will add a tag snap/dirty.

And for resetReason, is a value from this function esp_reset_reason() from espressif to get ESP last reset reason. You can see the list of possible values here esp_reset_reason_t.

Thanks @Samuel_AirGradient

The API page is far out of date in that case as I’ve been mentioning here: Dashboard API Documentation - #4 by MallocArray

https://api.airgradient.com/public/docs/api/v1/
This page shows in Measures a property called firmwareVersion that is what I was expecting, but doesn’t seem to be used anymore, and firmware isn’t clear what it is. Something like pms5003_firmware would be more clear.