Skip to main content

Sending/receiving process for payloads using an IoT Flow engine

Device data include a payload and metadata. In the context of ThingPark Enterprise, payloads designate the real messages (temperature measurements, humidity indicators or geographical coordinates) that are transmitted via uplinks/downlinks to ThingPark Enterprise, then to ThingPark X cloud application and the other way around.

Driver metadata designates all information that is required to identify the device (firmware) and the protocol to be used by the device to encode its payload.

Note Generic device profiles (using LoRaWAN® manufacturer) are not associated with any driver metadata, so ThingPark cannot decode the application payloads of devices associated with generic device profiles.

As of ThingPark Enterprise 6.1, a TPE platform contains a ThingPark X IoT Flow engine with drivers, also called payload decoders, that aim at decoding/encoding the payloads received from the devices from a raw format to a readable JSON format. The decoded data are then further transmitted from ThingPark Enterprise to ThingPark X cloud application via uplink messages. Hence, the payloads are more readable in JSON format than in raw format by ThingPark X cloud application.

The driver metadata is used by the devices to select the proper driver for identifying which protocol has been used to encode the payload.

In the reverse process, payloads in JSON format are sent from the ThingPark X cloud application to ThingPark Enterprise and further to the devices via downlink messages.

This is illustrated in the following graphic.

Metadata and drivers

Drivers allow the devices to transmit the decoded payloads in JSON format from the devices to the applications via uplink messages. There is no need for the application to decode the payload in the application any longer. They also allow the applications to send encoded payloads in JSON format via downlink messages. There is no need to encode those in the applications any longer.

Note The decoding is only triggered if the packet contains a payload and driver the device is associated with a valid driver metadata.

In the uplink direction, drivers decode the raw data from a binary format to a JSON format which is more readable by applications. In the downlink direction, drivers encode the payload from a JSON format to a binary format which is more usable by base stations.

The result of the payload decoding can be one of the following:

  • If the payload decoding is successful, two fields are displayed:

    • Driver identifier: the identifier of the driver used to decode the payload

    • Decoded payload: the output of the driver (JSON document)

Sample of decoded payload:

.."temperature": 25,
.."humidity": 80,
.."longitude": 2.3336,
.."latitude": 48.87506
  • If the payload decoding is not successful, only one field is displayed.

    • Payload Decoding Error: the error message (JSON document)

Sample of error message:

.."code": "error-code",
.."data": {
...."driverId": "myprovider:myotherdriver:1"
.."message": "Cannot decode provided downlink"

The decoded payloads are visible in the widgets related to the last packets sent by the device. To learn more, click Viewing the payloads of the devices.