I have installed lora-gateway-bridge on the same server as loraserver and lora-app-server.
Jul 05 17:38:15 wiriots00 lora-gateway-bridge[13952]: time=“2019-07-05T17:38:15-04:00” level=error msg=“apply gateway-configuration error” error=“gateway does not exist”
My lora-gateway-bridge.toml file is,
[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:20000"
# 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
# Manage<Â]à d 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 merge<Â]èW d 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 c<Â]ó” ertificate.
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 th<Â]ýÑ is 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 certi<Â] ficate 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.
#
# Ex<Â] ample 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<Â]L 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"