Skip to main content
Version: TAO v2.x

Step 5 - setting up your dataflows

ThingPark Enterprise All-in-One supports the leading IoT protocols needed to fulfill your deployment use cases:

To optimize its integration with external application servers, ThingPark Enterprise All-in-One embeds a Node-RED component to seamlessly manage dataflows.

This topic describes the dataflow management tasks as of ThingPark version 2.2.0:

  • In this version, the basic management tasks can be executed from the TAO GUI without needing to access Node-RED's user interface.
  • For earlier versions, all the dataflow management tasks are entirely managed via Node-RED's user interface. To learn more, see Using Node-RED.

Checking the status of your dataflows​

  1. From the left panel of the user interface, go to Dataflows.

  2. Under the STATUS widget:

    • The Node-RED status determines whether Node-RED is properly running on your server or not. If the status is not ACTIVE, click RESTART NODE-RED to try to fix the issue.

    • The MQTT broker status determines whether the local MQTT broker embedded in the ThingPark server is properly running or not. You may restart it if needed.

    • Uplink/Downlink flow is the default dataflow. It uses the MQTT protocol and constitutes the unique interface with the LoRaWAN Network Server.
      For proper operation of your dataflows, the status of this Uplink/Downlink flow must always remain "Started". Contact your support team if this flow has been accidentally stopped.

      caution

      Never delete the Uplink/Downlink flow from Node-RED, even if you do not need MQTT protocol to interface with your Application Servers.

  3. Under the ACTIVATION widget:

    • Check the activation status of your BACnet and Modbus dataflows.
    • These dataflows are not activated by default, use the corresponding switches to activate one or both dataflows as needed.

Setting up the BACnet dataflow​

The BACnet dataflow allows you to automatically expose the data of your LoRaWAN devices as BACnet objects inside a built-in BACnet server. By default, this server uses the standard UDP multicast port 47808 (BAC0), but you may change the port by connecting to Node-RED, as described in BACnet server configuration.

This dataflow supports three BACnet object types:

  • Analog Value (noted 'AV') for numeric data
  • Binary Value (noted 'BV') for boolean data
  • Character String Value (noted 'SV') for string data.

The mapping of LoRaWAN sensor data into BACnet objects is fully automated, without any manual action from the user. To learn more about this auto-mapping, see Automatic mapping process.

Nevertheless, if you want to customize this automatic mapping to better fit your deployment constraints, follow the steps described in Mapping customization.

The following steps describe how to setup BACnet dataflow to serve uplink path. If you want to use BACnet protocol to send downlink packets to your LoRaWAN devices, you use to use the Node-RED editor, as described in Downlink packets.

  1. From the left panel of the user interface, go to Dataflows.

  2. In the ACTIVATION widget, activate the BACnet flow if it is not already the case.

  3. In the BACNET widget, you may control the mapping settings of your LoRaWAN devices into BACnet objects:

    • Object name: Each extracted data from LoRaWAN sensors is exposed as a BACnet object whose identifier is constructed using the device's DevEUI (default setting), followed by colon : then the property name. You may change the definition of the object identifier to use the sensor's friendly name (which is the device name set in TAO) rather than the DevEUI.

    • LoRaWAN metadata: You may freely define which LoRaWAN metadata are exposed as BACnet objects.

      • RSSI is the Received Signal Strength Indicator of each LoRaWAN uplink packet. RSSI measures the overall signal strength within the radio channel's bandwidth, summing up the useful signal, the interference and the background noise. RSSI is expressed in dBm.
      • SNR is the Signal to Noise Ratio of each LoRaWAN uplink packet. It provides a reliable estimation of the quality of the uplink reception. SNR is expressed in dB.
      • FCntUp is the frame counter of each LoRaWAN uplink packet.
      • SpFact is the Spreading Factor of each LoRaWAN uplink packet. SF7 corresponds to the fastest data rate while SF12 corresponds to the slowest data rate.

    • Payload ontology: Ontology processing is supported by specific payload drivers. It provides a uniform standardization of measured properties. When ontology is activated and supported by the device's payload driver, an associated unit is provided and a transformation is applied to the value to ensure it fits the specified unit.

      Example All devices that expose a temperature measurement with drivers supporting ontology will provide the temperature in the same way (same unit, same property name). For more information about device drivers, see Supported drivers/ontologies.

Mapping customization​

As mentioned above, the LoRaWAN to BACnet mapping is fully automated by default. You may change this default mapping in order to fix the instance number of a property and ensure that this property is always exposed at a fix instance number.

To do so, follow the steps below:

  1. Export you current object list to a csv file, by clicking the EXPORT button.

  2. Modify the instance number association of the csv file, and save it to your custom list. The following recommendations should be respected:

    • Start the instance numbering from 0 for each type (AV,BV,SV).
    • Do not leave holes in the numbering scheme.
    • Do not change the type for a specific property.
    • Create new entries for future devices properties that are not yet exposed.
    • Leave the header line as is, do not add columns.

  3. Import this custom csv file to the server, by clicking the IMPORT button.

    The import file format is the same as the export file format (value and unit are not taken into account during import). The import status is displayed on the screen, in case of errors, the screen displays the list of points to fix, as illustrated by the following example:

    -> Once the import is successful, your new mapping will then be available instantaneously.

Setting up the Modbus dataflow​

The Modbus dataflow allows you to automatically expose the data of your LoRaWAN devices inside an built-in slave Modbus server.

By default, this server is available on the standard TCP port 10502. If needed, you may change the port in Node-RED, as described in Modbus server customization.

To map your LoRaWAN properties into Modbus objects, you must manually define a mapping table that specifies, for each LoRaWAN sensor, which property should be extracted, what encoding algorithm must be applied and at which location it must be written on the modbus holding register array.

note

Only uplink via Modbus is currently supported, downlinks via Modbus is not currently implemented. For downlink path, you may rely on MQTT or HTTP protocols.

  1. From the left panel of the user interface, go to Dataflows.

  2. In the ACTIVATION widget, activate the Modbus flow if it is not already the case.

  3. Prepare the csv file containing your object mapping rules. To learn more, see Object mapping.

  4. In the MODBUS widget, import the csv mapping file that you prepared in the previous step.

    -> Once the import is successful, your new mapping will then be available instantaneously.

Object mapping​

For each property that you want to extract from the uplink message, you have to provide an object composed of the following fields:

  • DevEUI: is the LoRaWAN sensor's DevEUI.
  • Attribute: the attribute name property extracted from the LoRaWAN uplink. See below to learn more about the Attribute property conventions.
  • DataType: the Modbus operation to apply. See below to learn more about the supported types.
  • address: modbus register number location.

You may download the sample file from the user interface to learn the expected format of the file to import.

Attribute property conventions

The first level properties under DevEUI_uplink are available as is:

  • DevEUI_uplink.LrrRSSI -> LrrRSSI

The property includes the path below payload, points, each part is added using the dot . separator.

The attributes in DevEUIuplink.payload are accessible in first level, sub paths are recreated using underscore (''):

  • DevEUI_uplink.payload.batteryVoltage -> batteryVoltage
  • DevEUI_uplink.payload.levels.power -> levels_power

The attributes in DevEUIuplink.points are accessible in first level, sub paths are recreated using underscore (''):

  • DevEUI_uplink.points.temperature.record -> temperature_record.

Supported DataTypes

  • float: modbus operation is FC 16, write 2 registers : 4 bytes.
  • int: modbus operation is FC 16, write 1 register : 2 bytes.
  • uint or uint32: modbus operation is FC 16, write 2 registers : 4 bytes.
  • hex: modbus operation is FC 16, write n registers : n*2 bytes, (for "0A0B0C", it will consume 2 registers, first one containing 0A0B, second one containing 000C).