Configuration

The lora-gateway-bridge has the following command-line flags:

LoRa Gateway Bridge abstracts the packet_forwarder protocol into JSON over MQTT
        > documentation & support: https://docs.loraserver.io/lora-gateway-bridge
        > source & copyright information: https://github.com/brocaar/lora-gateway-bridge

Usage:
  lora-gateway-bridge [flags]
  lora-gateway-bridge [command]

Available Commands:
  configfile  Print the LoRa Gateway configuration file
  help        Help about any command
  version     Print the LoRa Gateway Bridge version

Flags:
  -c, --config string   path to configuration file (optional)
  -h, --help            help for lora-gateway-bridge
      --log-level int   debug=5, info=4, error=2, fatal=1, panic=0 (default 4)

Use "lora-gateway-bridge [command] --help" for more information about a command.

Configuration file

By default lora-gateway-bridge will look in the following order for a configuration at the following paths when --config / -c is not set:

  • lora-gateway-bridge.toml (current working directory)
  • $HOME/.config/lora-gateway-bridge/lora-gateway-bridge.toml
  • /etc/lora-gateway-bridge/lora-gateway-bridge.toml

To load configuration from a different location, use the --config flag.

To generate a new configuration file lora-gateway-bridge.toml, execute the following command:

lora-gateway-bridge configfile > lora-gateway-bridge.toml

Note that this configuration file will be pre-filled with the current configuration (either loaded from the paths mentioned above, or by using the --config flag). This makes it possible when new fields get added to upgrade your configuration file while preserving your old configuration. Example:

lora-gateway-bridge configfile --config lora-gateway-bridge-old.toml > lora-gateway-bridge-new.toml

Example configuration file:

[general]
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level = 4


# Gateway backend configuration.
[backend]

# Backend type.
#
# Valid options are:
#   * semtech_udp
#   * basic_station
type="semtech_udp"


  # Semtech UDP packet-forwarder backend.
  [backend.semtech_udp]

  # ip:port to bind the UDP listener to
  #
  # Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
  # This is the listeren to which the packet-forwarder forwards its data
  # so make sure the 'serv_port_up' and 'serv_port_down' from your
  # packet-forwarder matches this port.
  udp_bind = "0.0.0.0:1700"

  # Skip the CRC status-check of received packets
  #
  # This is only has effect when the packet-forwarder is configured to forward
  # LoRa frames with CRC errors.
  skip_crc_check = false

  # Fake RX timestamp.
  #
  # Fake the RX time when the gateway does not have GPS, in which case
  # the time would otherwise be unset.
  fake_rx_time=false

    # Managed packet-forwarder configuration.
    #
    # By configuring one or multiple managed packet-forwarder sections, the
    # LoRa Gateway Bridge updates the configuration when the backend receives
    # a configuration change, after which it will restart the packet-forwarder.
    #
    # Example (this configuration can be repeated):
    #
    # [[backend.semtech_udp.configuration]]
    # # Gateway ID.
    # #
    # # The LoRa Gateway Bridge will only apply the configuration updates for this
    # # gateway ID.
    # gateway_id="0102030405060708"

    # # Base configuration file.
    # #
    # # This file will be used as base-configuration and will not be overwritten on
    # # a configuration update. This file needs to exist and contains the base
    # # configuration and vendor specific
    # base_file="/etc/lora-packet-forwarder/global_conf.json"

    # # Output configuration file.
    # #
    # # This will be the final configuration for the packet-forwarder, containing
    # # a merged version of the base configuration + the requested configuration
    # # update.
    # # Warning: this file will be overwritten on a configuration update!
    # output_file="/etc/lora-packet-forwarder/local_conf.json"

    # # Restart command.
    # #
    # # This command is issued by the LoRa Gateway Bridge on a configuration
    # # change. Make sure the LoRa Gateway Bridge process has sufficient
    # # permissions to execute this command.
    # restart_command="/etc/init.d/lora-packet-forwarder restart"


  # Basic Station backend.
  [backend.basic_station]

  # ip:port to bind the Websocket listener to.
  bind=":3001"

  # TLS certificate and key files.
  #
  # When set, the websocket listener will use TLS to secure the connections
  # between the gateways and LoRa Gateway Bridge (optional).
  tls_cert=""
  tls_key=""

  # TLS CA certificate.
  #
  # When configured, LoRa Gateway Bridge will validate that the client
  # certificate of the gateway has been signed by this CA certificate.
  ca_cert=""

  # Ping interval.
  ping_interval="1m0s"

  # Read timeout.
  #
  # This interval must be greater than the configured ping interval.
  read_timeout="1m5s"

  # Write timeout.
  write_timeout="1s"

  # Region.
  #
  # Please refer to the LoRaWAN Regional Parameters specification
  # for the complete list of common region names.
  region="EU868"

  # Minimal frequency (Hz).
  frequency_min=863000000

  # Maximum frequency (Hz).
  frequency_max=870000000

    # Filters.
    [backend.basic_station.filters]

    # NetIDs to filter on when receiving uplinks.
    net_ids=[
      "000000",
    ]

    # JoinEUIs to filter on when receiving join-requests.
    join_euis=[
      ["0000000000000000", "ffffffffffffffff"],
    ]


# Integration configuration.
[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf:  Protobuf encoding (this will become the LoRa Gateway Bridge v3 default)
# * json:      JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="protobuf"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="gateway/{{ .GatewayID }}/command/#"


  # MQTT authentication.
  [integration.mqtt.auth]
  # Type defines the MQTT authentication type to use.
  #
  # Set this to the name of one of the sections below.
  type="generic"

    # Generic MQTT authentication.
    [integration.mqtt.auth.generic]
    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    server="tcp://127.0.0.1:1883"

    # Connect with the given username (optional)
    username=""

    # Connect with the given password (optional)
    password=""

    # Quality of service level
    #
    # 0: at most once
    # 1: at least once
    # 2: exactly once
    #
    # Note: an increase of this value will decrease the performance.
    # For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
    qos=0

    # Clean session
    #
    # Set the "clean session" flag in the connect message when this client
    # connects to an MQTT broker. By setting this flag you are indicating
    # that no messages saved by the broker for this client should be delivered.
    clean_session=true

    # Client ID
    #
    # Set the client id to be used by this client when connecting to the MQTT
    # broker. A client id must be no longer than 23 characters. When left blank,
    # a random id will be generated. This requires clean_session=true.
    client_id=""

    # CA certificate file (optional)
    #
    # Use this when setting up a secure connection (when server uses ssl://...)
    # but the certificate used by the server is not trusted by any CA certificate
    # on the server (e.g. when self generated).
    ca_cert=""

    # mqtt TLS certificate file (optional)
    tls_cert=""

    # mqtt TLS key file (optional)
    tls_key=""

    # Maximum interval that will be waited between reconnection attempts when connection is lost.
    # Valid units are 'ms', 's', 'm', 'h'. Note that these values can be combined, e.g. '24h30m15s'.
    max_reconnect_interval="10m0s"


    # Google Cloud Platform Cloud IoT Core authentication.
    #
    # Please note that when using this authentication type, the MQTT topics
    # will be automatically set to match the MQTT topics as expected by
    # Cloud IoT Core.
    [integration.mqtt.auth.gcp_cloud_iot_core]
    # MQTT server.
    server="ssl://mqtt.googleapis.com:8883"

    # Google Cloud IoT Core Device id.
    device_id=""

    # Google Cloud project id.
    project_id=""

    # Google Cloud region.
    cloud_region=""

    # Google Cloud IoT registry id.
    registry_id=""

    # JWT token expiration time.
    jwt_expiration="24h0m0s"

    # JWT token key-file.
    #
    # Example command to generate a key-pair:
    #  $ ssh-keygen -t rsa -b 4096 -f private-key.pem
    #  $ openssl rsa -in private-key.pem -pubout -outform PEM -out public-key.pem
    #
    # Then point the setting below to the private-key.pem and associate the
    # public-key.pem with this device / gateway in Google Cloud IoT Core.
    jwt_key_file=""


    # Azure IoT Hub
    #
    # This setting will preset uplink and downlink topics that will only
    # work with Azure IoT Hub service.
    [integration.mqtt.auth.azure_iot_hub]

    # Device connection string.
    #
    # This connection string can be retrieved from the Azure IoT Hub device
    # details.
    device_connection_string=""

    # Token expiration.
    #
    # LoRa Gateway Bridge will generate a SAS token with the given expiration.
    # After the token has expired, it will generate a new one and trigger a
    # re-connect.
    sas_token_expiration="24h0m0s"


# Metrics configuration.
[metrics]

  # Metrics stored in Prometheus.
  #
  # These metrics expose information about the state of the LoRa Gateway Bridge
  # instance like number of messages processed, number of function calls, etc.
  [metrics.prometheus]
  # Expose Prometheus metrics endpoint.
  endpoint_enabled=false

  # The ip:port to bind the Prometheus metrics server to for serving the
  # metrics endpoint.
  bind=""


# Gateway meta-data.
#
# The meta-data will be added to every stats message sent by the LoRa Gateway
# Bridge.
[meta_data]

  # Static.
  #
  # Static key (string) / value (string) meta-data.
  [meta_data.static]
  # Example:
  # serial_number="A1B21234"



  # Dynamic meta-data.
  #
  # Dynamic meta-data is retrieved by executing external commands.
  # This makes it possible to for example execute an external command to
  # read the gateway temperature.
  [meta_data.dynamic]

  # Execution interval of the commands.
  execution_interval="1m0s"

  # Max. execution duration.
  max_execution_duration="1s"

  # Commands to execute.
  #
  # The value of the stdout will be used as the key value (string).
  # In case the command failed, it is ignored. In case the same key is defined
  # both as static and dynamic, the dynamic value has priority (as long as the)
  # command does not fail.
  [meta_data.dynamic.commands]
  # Example:
  # temperature="/opt/gateway-temperature/gateway-temperature.sh"

Environment variables

Although using the configuration file is recommended, it is also possible to use environment variables to set configuration variables.

Example:

[backend.semtech_udp]
udp_bind="0.0.0.0:1700"

Can be set using the environment variable:

BACKEND.SEMTECH_UDP.UDP_BIND="0.0.0.0:1700"