DPPv1 example

An example of a DPP that performs data filtering and aggregation

DPPv1 Descriptor

When you are done with this example, you can continue to the full specification of the DPP Descriptor


This example represents a DPP that is used to aggregate and filter the data produced by a set of Service Objects. In particular the scenario is composed of 3 BLE¹ detectors that periodically publish the list of BLE devices detected in its visibility range. For each device detected, it generates a Sensor Update composed of two channels: “beacon“, which is the MAC address of the device that has been detected; and “rssi” which is the signal strength (in dBm units) of the detected device.

The DPP is subscribed to the group of devices that act as data sources, and generates an output stream (‘aggregate‘) that emits all the information produced by the BLE detectors. Therefore, someone subscribed to the ‘aggregate‘ stream of the DPP would receive all the Sensor Updates generated by the three BLE detectors.

The DPP generates a second stream of data, called “filtered“, that takes as input the Sensor Updates generated by the BLE detectors, and for each Sensor Update, looks for the “rssi” channel (that is, the signal strength) and emits the same Sensor Update if and only if the value of the “rssi” is greater than -70.

¹BLE: Bluetooth Low Energy

Descriptors of the Service Objects associated to the BLE detectors

The following documents are examples of three Service Objects associated to the three BLE detectors presented in this example. They are the data sources for the DPP.

Service Object 1

Descriptor of the first BLE device.
Registered with SOID

Service Object 2

Descriptor of the second BLE device.
Registered with SOID

Service Object 3

Descriptor of the third BLE device.
Registered with SOID

DPPv1 Descriptor

Registered with SOID

The DPP takes as input the stream “detected” of three Service Objects (identified as an array of SOIDs, which is the group of sources with name “Allphones“). It emits two streams: “aggregate” and “filtered“. Each stream is composed of two channels: “beacon” and “rssi“.

Every output channel is expressed as a single javascript statement of either an input stream or a defined group (notice that a group is already associated to a particular stream). In this case, the input stream is the stream associated to the group “Allphones” which is “detected” as generated by the BLE detectors.

Notice that the Sensor Updates that will be emitted by each channel is the value that results of evaluating the javascript statement  associated to that channel. In the example, the pre-filter property is used to decide if a Sensor Update should be emitted. If the pre-filter statement evaluates true, then the Sensor Update can be processed and emitted. Otherwise, the input Sensor Update is discarded.

The code associated to the javascript statement of a channel can use JSON Path expressions to navigate the data structure of a Sensor Update in order to obtain the data needed to perform the calculations to emit an output Sensor Update.

Retrieving data from the DPP streams

Retrieving data from a DPP stream is not different to retrieving data from a simple Service Object. All is needed is the user API TOKEN and the SOID to perform a REST API call to retrieve the data associated to one of the streams of the DPP. The following examples show how to retrieve data from both streams of the DPP presented in this example.

DPP Aggregate stream

Retrieving data from the aggregate stream

DPP Filtered stream

Retrieving data from the filtered stream