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.
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"
}
]
}
]
}
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
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:
- Edit the
gateware.json
configuration file and add the following setting: "gateware_log_level": "debug"
- Browse to your Conduit UI https://192.168.2.1/administration/debug
- 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