The QC flags are set at raw value level.
Table below displays the possible QC flags:
128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
---|---|---|---|---|---|---|---|
X | X | X | Value is an outlier (ML model) | Value repeating | Value > max | Value < min | QC operation executed |
X = bit reserved
The QCS flags are set at raw value level.
Table below displays the possible QCS flags:
32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
X | X | X | X | Value corr. failed (outlier(s)) | Value corr. failed (NaN) | Value corr. failed (expression) | Value corr. failed (eval) | Value corr. failed (unknown) | Outlier detection failed | Value corr. enabled | Outlier detection enabled | Persistence check enabled | Range check (max) enabled | Range check (min) enabled | X |
X = bit reserved
Table below displays the possible QA flags:
128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
---|---|---|---|---|---|---|---|
X | X | X | X | Value accepted | Metadata complete | X | X |
X = bit reserved
Table below displays the possible QAS flags:
32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
X | X | X | X | X | Window not continuous | Window varying positions | Mad zero value | Window too small | X | X | X | Value outlier | Value persistent | Value out of range | X |
X = bit reserved
The pipeline status flags are set at the sensor level.
Table below displays the possible pipeline flag values:
128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
---|---|---|---|---|---|---|---|
X | X | X | QA/QC of raw data failed | QA/QC of raw data executed | Raw data processed with errors | Raw data processed and stored | Raw data processed [NO DATA] |
X = bit reserved
It is possible to bind (or map) a JSON attribute representing a moment in time as a timestamp for measurement when storing the data.
If this JSON attribute is given as number of seconds since 00:00:00 UTC on 1 January 1970 (Unix Epoch), then no timestamp converter is required.
On the other hand, if the attribute is represented as a string of any given custom format (e.g. 'yyyy/MM/dd HH:mm:ss'), then the StringEpochTime converter must be used. This converter converts the string value into Unix Epoch.
In both cases a timestamp field-binder must be used if you want to use that JSON attribute as a timestamp representation. Be aware of that if this attribute binding is omitted, the system time will instead be used, which defaults to the Unix Epoch UTC.
The "binding-path" and "target-path" JSON attributes are used when a converter or a field-binder is used when defining the sensor schema.
When defining a new sensor schema and specifying the components, the binding-path is the absolute JSON path to an attribute (in sensor data packet) that will be "bound" to a component (eg. PM10, NO2, CO).
Similar, when using a converter (if required), the converter takes the target-path as an argument. The converter is using this path when converting an attribute (k) with value (v) located at that JSON path.
Same principle applies when using a field-binder. The field-binder m is an alias for attribute k with value v located at target path p.
These attributes supports JPath syntax.
Below is a table with some examples:
JSON | Binding / Target (JSON) Path | Remarks |
---|---|---|
{ "no2" : 15.232 } |
"no2" | |
{ "no2" : { "value" : 15.232 }} |
"no2.value" | |
{ "gas" : { "components" : [ { "no2" : { "value" : 15.232 } }, .. , { "no2" : { "value" : 15.232 } } ] }} |
"gas.components[0].no2.value" | |
{ "level1" : { "lev.el2" : { "no2" : { "value" : 15.232 } } } } |
"level1.['lev.el2'].no2.value" | The "." character at path level 2 has been escaped |
All API endpoints use a standard error message format for any requests that return an HTTP status indicating an error (any 400 or 500 statuses). For example, a request entity that omits a required field may generate the following response:
HTTPS/1.1 422 Unprocessable Entity Content-Type: application/json { "error-code": 1000, "error-message": "Sensor name must be defined.", "http-status-code": 422 }
Although it is good practice to check the status code, you may safely parse the
response of the API calls and check for the presence of an
error-code
field to detect errors.
Some error codes are used frequently across the entire API and you will probably want to have general purpose code to handle these, whereas most other error codes will need to be handled on a per-request basis.