Chapter 2

Configuration

Set up in minutes, fine tune as you wish

GATE-Ware is configured via a single JSON file. Most installations can be completed using just a few configuration lines. You’ll also have the option to further adjust the installation via a complete set of options.

All configuration styles, from the hyper-simple to the power-user playground will be discussed in the following sections.

Attributes

Full list of attributes, with some powerful options

The sections below expose the complete set of GATE-Ware configuration options. Please take note of the (required) vs (optional) markers, as most options exist to extend basic functionality.

It is worth noting that basic functionality is all that most users of the application will ever need to implement in their configuration files. However, Optional values extend the application in some powerful ways.

GATE-Ware Core

Option Values default value Purpose
backend (optional, string) mqtt “Backend” is where we are pushing data from sensors to, acceptable values: mqtt, aws, azureiot, azure
gateware_backend_watchdog_max_interval (optional, int) 120 In seconds, interval we want the backend watchdog waiting before restarting GATE-Ware
gateware_external_command_timeout (optional, int) 60 In seconds, timeout for running system commands for things like app-manager
gateware_license_key (required, string) no license GATE-Ware license key
gateware_log_destination (optional, string) syslog Logging destination, supports: syslog, file, stdout
gateware_log_filename (optional, string) /var/log/gateware.log If log destination is set to file this is where logs go
gateware_log_level (optional, string) info Logging level minimum, supported: trace, debug, warn, error
gateware_uplink_transforms (optional, array of transforms) See: Transforms

Backend: Azure IoT

Option Values default value Purpose
backend_azure_ca (optional, string) DiGiCert Global Root G2 Certificate used for configuring MQTT w/ TLS for connection with Azure, described. here and here. If not specified the DigiCert Global Root G2 certificate is used, per Microsoft recommendation.
backend_azure_dps_group_enrollment_registration (optional, boolean) false This will enable group enrollment via Azure DPS. Individual enrollment is the default
backend_azure_dps_registration_id (optional, string) If backend_azure_dps_registration_id_from_serial is disabled, this string is used for the MQTT client ID
backend_azure_dps_registration_id_from_serial (optional, boolean) true Client ID for MQTT sessions will be derived from the conduit serial
backend_azure_dps_scope_id (required, string) This is unique per DPS configuration
backend_azure_iot_hub_heartbeat_enabled (optional, boolean) true IoT Hub heartbeat publishes an empty message to the device’s topic in an attempt to keep the TCP connection alive
backend_azure_iot_hub_heartbeat_interval (optional, int) 900 In seconds, how often do we send the heartbeat
backend_azure_sas_primary_key (required, string) Primary symmetric key
backend_azure_sas_secondary_key (required, string) Secondary symmetric key

Backend: MQTT / AWS

Option Values default value Purpose
backend_mqtt_ca (optional, string) Certificate used for configuring MQTT w/ TLS for connection
backend_mqtt_client_certificate (optional, string) Client certificate for MQTT
backend_mqtt_endpoint_host (required, string) MQTT broker hostname
backend_mqtt_endpoint_keepalive (optional, int) 60 In seconds, MQTT keep alive via Paho
backend_mqtt_endpoint_port (optional, int) 1883 MQTT port
backend_mqtt_endpoint_qos (optional, int) 1 QoS
backend_mqtt_max_publish_attempts (optional, int) 150 How many times do we attempt to publish a message when failures occur. 0 is infinite
backend_mqtt_password (optional, string) Password for authentication
backend_mqtt_private_key (optional, string) Private key for client certificate
backend_mqtt_use_tls (optional, boolean) false Whether or not to use TLS during connection
backend_mqtt_username (optional, string) Username for authentication

Transforms

Matching Order

GATE-Ware compares the incoming message’s AppEUI and LoRa Port with transforms defined in the configuration, selecting the most specific match. An exact match will always win over a wildcard match.

Wildcards

AppEUI wildcards are defined using the "appeui":"ANY" parameter.

LoRa Port wildcards are defined using the "port":-1 parameter.

Built-In Transform(s) Configuration

A number of Built-In transforms are available to perform common operations on data.

> Click to see general information on Built-In Transforms.

Forward

GATE-Ware can be configured to forward messages in the original form received from edge devices to the backend.

For example, to forward all messages which do not have a more specific transform configured, add the following to your gateware.json:

{
  "gateware_uplink_transforms": [
    {
      "appeui": "ANY",
      "lora_ports": [
        {
          "port": -1,
          "action": "forward"
        }
      ]
    }
  ]
}

Discard

GATE-Ware can be configured to discard messages received from edge devices. This is useful for conserving Internet bandwidth (for example, if you are using a cellular connection).

For example, to discard any messages which do not have a more specific transform configured, add the following to your gateware.json:

{
  "gateware_uplink_transforms": [
    {
      "appeui": "ANY",
      "lora_ports": [
        {
          "port": -1,
          "action": "discard"
        }
      ]
    }
  ]
}

Text

GATE-Ware can be configured convert the LoRa uplink payload to ASCII text.

For example, to convert messages which do not have a more specific transform configured, add the following to your gateware.json:

{
  "gateware_uplink_transforms": [
    {
      "appeui": "ANY",
      "lora_ports": [
        {
          "port": -1,
          "action": "text"
        }
      ]
    }
  ]
}

Custom Transform(s) Configuration

GATE-Ware can be configured to run custom transforms. This is useful for performing edge processing on LoRa uplink payload from your devices.

> Click to see general info on Custom Transforms

Custom Transform Example

For example, to run the transforms/bash_examples/insert_uuid.sh custom transform on any messages to AppEUI 2b-7e-15-16-28-ae-d2-a5 on LoRa Port 5, add the following to your gateware.json:

{
  "gateware_uplink_transforms": [
    {
      "appeui": "2b-7e-15-16-28-ae-d2-a5",
      "lora_ports": [
        {
          "port": 5,
          "action": "external_handler",
          "external_handler": "transforms/bash_examples/insert_uuid.sh",
          "external_handler_timeout_seconds": 1
        }
      ]
    }
  ]
}

Troubleshooting

Configuring Logging

The gateware_log_level configuration option controls the verbosity of GATE-Ware log messages. The default value is info which means that only informational messages are logged.

When troubleshooting, it can be helpful to increase the verbosity of GATE-Ware by changing the gateware_log_level to debug. This will log more information about the internal operations of GATE-Ware.

Steps to Configure Logging:

  1. Edit the gateware.json configuration file and add the following setting: "gateware_log_level": "debug"
  2. Browse to your Conduit UI https://192.168.2.1/administration/debug
  3. Set the Debug Log Level field to DEBUG

Important Notes:

  • It is recommended to use the debug & trace log levels only when troubleshooting and never in production environments.
  • The debug & trace log levels are very verbose and can cause performance issues.
  • The debug & trace log levels may cause GATE-Ware to log sensitive information, such as passwords.

Accessing Logs

Downloading Logs

The GATE-Ware logs can be downloaded from the Conduit management UI page:

https://192.168.2.1/status/statistics/system (replacing 192.168.2.1 with the IP address of your Conduit).

Viewing Logs over SSH

The GATE-Ware logs can be viewed over SSH by running the following command:

tail -F /var/log/messages