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.
tip

To know the version of your ThingPark Enterprise All-in-one server, hover your mouse on the logo at the top left of the user interface.

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, they may be set as inputs/outputs for uplink/downlink properties respectively:

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

The BACnet client may subscribe to server's notification for any of the BACnet properties, through the Change of Value (CoV) feature. Analog type of properties are associated with a COV increment attribute allowing the client to determine the notification threshold for each property.

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 the BACnet dataflow:

  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.

Besides uplink properties (that is to say, properties measured by the sensor and reported in uplink payloads), the BACnet flow will automatically expose output properties representing the downlink commands supported by the LoRaWAN device, such as setting the target temperature of a thermostatic valve, etc.

note

In TAO v2.4.0, sending downlink commands through BACnet is natively supported for the following device models:

  • All Thermokon models, such as NOVOS-3, MCS, SAB07...
  • MClimate Vicki (thermostatic valve)

Native support of other device manufacturers will be progressively added in future releases.

Downlink commands use the LoRaWAN confirmed mode to ensure reliable delivery to end-devices, they are automatically retransmitted by TAO in case of transmission/reception failure. Up to 5 commands may be concatenated into the same LoRaWAN downlink packet.

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 properties 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 refers to the property name as extracted from the LoRaWAN uplink. See below to learn more about setting an attribute for each measured property.
  • 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.

How to set attributes?

Each property - that you need to map to a Modbus object - must be associated with a relevant attribute in your csv mapping file.

To do this, you first need to discover the different properties reported by your LoRaWAN devices in the uplink payloads.

tip

You may use an MQTT client, such as MQTTX or mosquitto_sub, to retrieve the uplink packets reported by your devices and discover which properties are included in their payloads.

Let's take the following example of a device reporting the following uplink packet:

{
  "DevEUI_uplink": {
    "Time": "2024-09-24T13:51:10.920+00:00",
    "DevEUI": "20635F0106000244",
    "FPort": 17,
    "FCntUp": 101,
    "LrrSNR": 5.5,
    ...
    "LrrRSSI": -30.6,
    ...
    "payload": {
      "messageType": "HEARTBEAT",
      "trackingMode": "PERMANENT_TRACKING",
      "batteryVoltage": 4.05,
      "levels": {
        "power": 3,
        "state": "on"
      }
    },
    "points": {
      "temperature": {
        "unitId": "Cel",
        "record": 28.3
      },
      ...
    }
  }
}

-> We have received a DevEUI_uplink with:

  • LrrSNR = 5.5 dB
  • LrrRSSI = -30.6 dBm
  • batteryVoltage = 4.05 V
  • power = 3
  • temperature = 28.3°C

If you want to export the LoRaWAN metadata, such as uplink frame counter (FCntUp), uplink RSSI or SNR, the corresponding attribute shall use exactly the same name as the LoRaWAN metadata, that is to say FCntUp, LrrSNR, LrrRSSI...

Under payload and/or points, the attribute corresponding to each property shall use the property's name. For instance, trackingMode, batteryVoltage... Use underscore _ to represent sub-levels: for instance, levels_power, 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).
Last updated on