Sensor Data Platform

Interpretation of quality control (QC) flags ¶

The QC flags are set at raw value level.

Table below displays the possible QC flags:

X = bit reserved

Interpretation of specific quality control (QCS) flags ¶

The QCS flags are set at raw value level.

Table below displays the possible QCS flags:

X = bit reserved

Interpretation of quality assurance (QA) flags ¶

Table below displays the possible QA flags:

X = bit reserved

Interpretation of specific quality assurance (QAS) flags ¶

Table below displays the possible QAS flags:

X = bit reserved

Interpretation of the pipeline status flags ¶

The pipeline status flags are set at the sensor level.

Table below displays the possible pipeline flag values:

X = bit reserved

Timestamps ¶

It is possible to map a JSON attribute representing a moment in time as a timestamp when storing 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 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 the Timestamp Mapper must be used in order to tell the system that you want to use the JSON attribute as a timestamp. If this attribute mapping is omitted, the system time will instead be used.

Binding Path / Target Path ¶

The "binding-path" and "target-path" JSON attributes are used when a converter or a field mapper 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. PM₁₀, NO₂, CO).

Similar, when using a converter (if required) for one of the components defined using the binding-path, the converter takes the target-path as an argument. The converter requires this path in order to be able to convert an attribute (k) with value (v) located at the given JSON path.

Same principle applies when using a field mapper. The field mapper 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:

{ "no2" : 15.232 }

{ "no2" : { "value" : 15.232 }}

{ "gas" : { "components" : [ { "no2" : { "value" : 15.232 } }, .. , { "no2" : { "value" : 15.232 } } ] }}

{ "level1" : { "lev.el2" : { "no2" : { "value" : 15.232 } } } }

Errors ¶

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.