Skip to main content
Version: TAO v2.x

Step 6 - 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.

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 notifications for any BACnet property, 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. 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 BACnet tab, activate the BACnet flow if it is not already the case, by clicking ACTIVATE BACNET.

  3. In the OBJECT MAPPING 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 : 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.

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

    • LoRaWAN metadata: You may freely define which LoRaWAN metadata are exposed as BACnet objects, by activating the related switch in the user interface:

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

  4. In the OBJECT DEFINITION widget, choose which device models should expose their measurement properties (also called points) as BACnet objects. For more details, see Updating object definition.

Updating Object definition​

You must define which devices should expose their measurements over BACnet protocol. If you have not added any object definition, TAO will not expose any BACnet objects for your LoRaWAN sensors.

To simplify the user experience, this definition is not made specifically for each LoRaWAN device: you just need to set it up for each device model of interest, this definition then applies to all the LoRaWAN devices associated with this model.

There are two modes of object definition, depending on the device model:

  1. Advanced definition

    • As of TAO v2.5.0, this mode applies to the following device models:

      • Enless (all models)
      • Watteco (all models)
      • Thermokon: MCS, NOVOS-3 and SAB07
      • MClimate Vicki

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

    • In this mode, users must choose which points are exposed on BACnet.

      note

      You should define at least one point per selected device model. If a device model is selected without any points, TAO will not expose any BACnet objects for the devices associated with this model.

    • This mode allows sending downlink commands over BACnet protocol. Downlink points use one of the following types: analog values, binary values or string values. To learn more about using BACnet for downlink, see Sending downlink commands with BACnet.

  2. Basic definition

    • This mode applies to all the LoRaWAN models having a valid payload driver in TAO, but they do not yet support the advanced definition mode.

    • In this mode, users cannot choose which points are exposed on BACnet: all the available measurement points are automatically exposed as BACnet objects. Available points are retrieved from uplink payloads reported by each device. Hence, BACnet objects are created on the fly, when the device starts sending uplink packets.

    • Sending downlink commands over BACnet protocol is not supported in this mode. You may use MQTT for downlink transmission.

  1. To add definition for a new device model, click ADD OBJECT DEFINITION.

  2. Choose a Device model, from the list of models currently used by the devices you already added.

  3. If the model supports the advanced definition mode, you will be asked to select the measurement points that you want to expose as BACnet objects.

    Tips
    • Start typing in the search area to easily find a point.
    • Click Select All if you want to add all the points supported by this model. Then, you may select those that do not want to keep and remove them by clicking .

    Each point is preceded by its type:

    • [AI] for analog inputs. For this type, you may set a COV increment threshold, if applicable.
    • [AV] for analog values, this type is used for actuated properties having numeric values, settable by sending downlink commands.
    • [BI] for binary inputs. COV does not apply to this type.
    • [BV] for binary values, this type is used for actuated properties having binary values, settable by sending downlink commands.
    • [SV] for string values. This type applies to both uplink and downlink properties. COV does not apply to this type.

  4. To add more points, click at the bottom-right of the table.

  5. When you are done, click SAVE.

  6. At any time, you may update your mapping by clicking EDIT.

Sending downlink commands through BACnet is natively supported for all the device models that support the advanced definition mode. See the full list in the previous section.

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.

For devices supporting the LoRaWAN class C mode, when a downlink actuation command is sent to the device, other commands cannot be sent until the first command is completely processed, either with a positive acknowledgment by the device or when the processing is eventually aborted after 5 transmission attempts without any acknowledgment.

Mapping customization​

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. Go to the OBJECT LIST widget, at the bottom of the BACnet tab.

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

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

  4. 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 be immediately available.

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 Modbus tab, activate the Modbus flow if it is not already the case, by clicking ACTIVATE MODBUS.

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

  4. Import the csv mapping file that you prepared in the previous step, by clicking IMPORT.

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

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 determines the data type. See below to learn more about the supported types.
  • address determines the Modbus register number and 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).

Troubleshooting your dataflows​

If your dataflows do not behave as expected, you need to check the status of the related backend services, as described below:

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

  2. Go to the Advanced settings tab, the Status widget shows the following information:

    • 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. To access the Node-RED user interface, go to the NODE-RED widget then click OPEN. -> The Node-RED editor opens in a new window.

    caution

    Doing changes in Node-RED requires expert knowledge about how it integrates with TAO. If you do not have this expertise, do not make any changes in Node-RED.

Last updated on