CSV Importer¶

Importing devices from a CSV file can be done using an easy to use wizard.

Starting the wizard¶

1. Click on the folder in the device-treeview on the left you want to import the devices in.
2. In the dashboard of the folder you will find a button labeled "IMPORT".
3. Click that button and a wizard will open.

Hint: The devices will be imported in the selected folder.

Closing the wizard can be done using the "X" or "CLOSE" at the top.

Using the wizard¶

The wizard will lead you through the process auf importing a CSV file containing devices and driver configuration.

First step is to select a supported driver. Not all drivers support importing files at the moment.

Second step is to select the .csv file you want to import. The file will be parsed in you browser and the found data will be displayed in a table. Consider the format of the CSV file.

Third step is to select a parser that will be assigned to the devices while importing. If there is no parser selected, no parser will be assigned. See parser documentation for more information about parsers.

If a device could not be parsed successfully, the validation errors will be shown. A device that passed validation will have a "IMPORT" button. Pressing that button will import that single device and display if the action was successful.

There is also a "IMPORT ALL" button, that will import all importable devices in sequence.

CSV Format¶

The CSV file needs to have the file extension .csv, .txt or any other text based file. Using a .xls, .xslx or .ods directly is not possible.

We try to detect the used delimiter, but its recommended to use ; or ,. Quoting and newlines will be detected too.

Start the CSV file directly with a header, followed by the payload in the next line, like in this example:

Name;Activation;Class;...
Useful-Sensor;OTAA;C;...

Empty lines in the payload will be omitted.

Profile data¶

The import CSV can contain rows with data for profiles. The profiles need to exist and the format rules from the fields will be checked.

If there is a profile with the technical name adresse and a field with the technical name strasse, the CSV column needs to be named like profile:adresse.strasse.

Location data¶

The import CSV can contain rows for the GPS location of the device.

The latitude and longitude need to be in columns named GPS-Lat and GPS-Lon. The format of the values is 53.555034 and 9.995450.

Driver specific formats¶

Devices in drivers may need specific fields and values, so they have their own formats.

ELEMENT LNS Format¶

The ELEMENT LNS will need a name for the device and the LoRaWAN details. A CSV template for LoRaWAN 1.0 can be found here. The following table will give you an overview for the available headers:

If there is no activation (OTAA or ABP) given, it will be detected using this rules:

• If there is a Device-EUI and Application-Key set, activation will be OTAA
• If there is a Device-Address, Network-Session-Key and Application-Session-Key set, activation will be ABP.

If there is no class set, the default A will be used.

There is no need to provide always all columns. OTAA devices only require the needed subset. ABP devices require their subset.

ELEMENT GMS Format¶

The ELEMENT Gateway-Management-System driver will need a Gateway-ID, a name and secret for probe if installed.

An example csv template is available here, which contains a gateway using probe and one without probe. The following table will give you an overview for the available headers:

WMBus Bridge Format¶

The WMBus Bridge will need a name for the device and the WMBus details. At least a Server-ID is needed. The AES-Key is optional.

A CSV template for LoRaWAN 1.0 can be found here. The following table will give you an overview for the available headers:

Actility ThingPark Format¶

Actility ThingPark requires the Device Profile Id for the device. Below the Table you'll find a list of approved device_profile_id's, only put in the corresponding id to the device's Type into the csv. Like the example shows. source_ports, may be either empty, *, a number or a list of numbers. A list is just numbers, separated by a semicolon. An example template for Actility is available here, which also contains some false examples.

The following table will give you an overview for the available headers:

If there is no activation (OTAA or ABP) given, it will be detected using this rules:

• If there is a Device-EUI and Application-Key set, activation will be OTAA
• If there is a Device-Address, Network-Session-Key and Application-Session-Key set, activation will be ABP.

There is no need to provide always all columns. OTAA devices only require the needed subset. ABP devices require their subset.

OTAA = {device_eui, join_eui, device_key}
ABP ={app_session_key, device_network_address, network_session_key, source_ports}

The following list is approved by Element Iot, to be compatible with actility thingpark:

  name: "LoRaWAN 1.0 - class C - ETSI - Rx2_SF12 | eu868",
  id: "LORA/GenericC.1_ETSI_Rx2-SF12"

  name: "LoRaMote EU fw4 - class A | eu868",
  id: "SMTC/LoRaMoteA.1_EU"

  name: "LoRaWAN 1.0 - class A - Rx2_SF12 | us915",
  id: "LORA/GenericA.1_FCC_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revB - class A - Rx2_SF12 | eu868",
  id: "LORA/GenericA.1.0.2b_ETSI_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revA - class A - Rx2_SF12 | us915",
  id: "LORA/GenericA.1.0.2a_FCC_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revA - class B - Rx2_SF12 | eu868",
  id: "LORA/GenericB.1.0.2a_ETSI_Rx2-SF12"

  name: "LoRaWAN 1.0 - class A - Rx2_SF12 | eu868",
  id: "LORA/GenericA.1_ETSI_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revB - class C - Rx2_SF12 | eu868",
  id: "LORA/GenericC.1.0.2b_ETSI_Rx2-SF12"

  name: "LoRaMote EU fw4 - class C | eu868",
  id: "SMTC/LoRaMoteC.1_EU"

  name: "LoRaWAN 1.0 - class A - Rx2_SF9 | us915",
  id: "LORA/GenericA.1_FCC_Rx2-SF9"

  name: "LoRaWAN 1.0.2 revA - class C - Rx2_SF12 | au915",
  id: "LORA/GenericC.1.0.2a_FCC_Rx2-SF12"

  name: "LoRaWAN 1.0 - class A - Rx2_SF9 | eu868",
  id: "LORA/GenericA.1_ETSI_Rx2-SF9"

  name: "LoRaWAN 1.0 - class C - Rx2_SF9 | us915",
  id: "LORA/GenericC.1_FCC_Rx2-SF9"

  name: "LoRaWAN 1.0 - class C - ETSI - Rx2_SF9 | eu868",
  id: "LORA/GenericC.1_ETSI_Rx2-SF9"

  name: "LoRaWAN 1.0 - class C - Rx2_SF12 | us915",
  id: "LORA/GenericC.1_FCC_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revA - class A - Rx2_SF12 | eu868",
  id: "LORA/GenericA.1.0.2a_ETSI_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revB - class B - Rx2_SF12 |eu868",
  id: "LORA/GenericB.1.0.2b_ETSI_Rx2-SF12"

  name: "LoRaWAN 1.0.2 revA - class C - Rx2_SF12 | eu868",
  id: "LORA/GenericC.1.0.2a_ETSI_Rx2-SF12"

Chirpstack LNS Format¶

The Chirpstack driver requires applications and device-profiles defined in the target Chirpstack server. Create these before devices can be created.

Creating a Chirpstack interface in ELEMENT IoT will result in creating a device on the Chirpstack server. Deleting the interface will delete the device on the Chirpstack server.

The Chirpstack LNS will need a name for the device and the LoRaWAN details. More LoRaWAN related settings are defined in the device-profile, like LoRaWAN Class A or B.

A CSV template for LoRaWAN 1.0 and 1.1 can be found here.

The following table will give you an overview of the available headers.

There is no need to provide always all columns. The required fields depend on the used Chirpstack application and device-profile.