Does this mean that CUPS support (for remote gateway configuration) is also on the way in a future release?
I’m not sure to be honest This is targeting the LNS protocol implementation. Potentially it could make sense that each gateway vendor takes care of a CUPS implementation for their gateway models, I’m not sure… What do you think?
But please know that this already uses the gateway-profile to configure the Basic Station channel-plan (thus the gateway-profile is mandatory for Basic Station powered gateways, I still need to document this).
I know that I have a TTN Indoor Gateway from conference that I can’t reconfigure to talk to LoRaServer because I’m not running a CUPS server…
Vendor interaction on this would be awesome (as would seeing Lora-gateway-os on the devices as we discussed at the Laird stand in Amsterdam!), but I do wonder if they’re going to claim it’s “not our problem, we just make the gateways, it’s up to you to configure them…”
Whatever you do, please don’t make CUPS a required dependency for anything.
Totally agree here, it’s a “nice to have”, not a “you must use”!
I can give it a spin. Any chance you could build either a Docker image (perhaps this is already available as latest
?) or a package for either the Tektelic KONA Micro or MultiTech Conduit (AP)?
I’ve prepared this Compose setup for testing (make sure you are using the v3-test
branch):
As the MQTT topics have changed and I realise it will be impossible to update all gateways at the same time, I propose a loraserver sub-command which will subscribe to the old gateway to NS topics and will re-publish these on the new topics.
In the opposite direction, it will subscribe to the new NS to gateway topics and will re-publish these message on the old topic.
This will be fully optional to run, but should help the migration
Example:
~/W/P/L/R/loraserver (master|✚1…1) $ ./build/loraserver mqtt2to3 -c loraserver-eu.toml
INFO[0000] mqtt2to3: connecting to mqtt broker broker="tcp://localhost:1883"
INFO[0000] mqtt2to3: connected to mqtt broker
INFO[0004] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/rx topic_to=gateway/00800000a00016b6/event/up
INFO[0004] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/command/down topic_to=gateway/00800000a00016b6/tx
INFO[0004] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/ack topic_to=gateway/00800000a00016b6/event/ack
INFO[0028] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/stats topic_to=gateway/00800000a00016b6/event/stats
INFO[0029] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/rx topic_to=gateway/00800000a00016b6/event/up
INFO[0029] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/command/down topic_to=gateway/00800000a00016b6/tx
INFO[0029] mqtt2to3: message forwarded topic_from=gateway/00800000a00016b6/ack topic_to=gateway/00800000a00016b6/event/ack
I have just released a new LoRa Gateway Bridge test-version:
LoRa Gateway Bridge v3.0.0-test.2
Features
Basic Station packet-forwarder support
The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.
Updated payload formats
The uplink payload contains a context
field, used to store gateway specific context data (like the internal counter).
The downlink frame contains a timing
field which can be either IMMEDIATELY
, DELAY
or GPS_EPOCH
. Based on the timing
value, an additional object must be given with the additional timing information. Refer to Commands for more details.
Fake RX time
In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)
Custom gateway meta-data
This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …
Upgrading
LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:
MQTT topics
The MQTT topic configuration has been updated from:
uplink_topic_template="gateway/{{ .MAC }}/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/{{ .MAC }}/stats"
ack_topic_template="gateway/{{ .MAC }}/ack"
config_topic_template="gateway/{{ .MAC }}/config"
To:
event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
command_topic_template="gateway/{{ .GatewayID }}/command/#"
Event types are: up
, stats
and ack
. Commands are: down
and config
.
Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+, but you will need to update the MQTT topics in your loraserver.toml
file. Example snippet:
uplink_topic_template="gateway/+/event/up"
stats_topic_template="gateway/+/event/stats"
ack_topic_template="gateway/+/event/ack"
downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"
Backends
With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...]
section. This has changed and the [backend...]
section is now used for selecting and configuring the packet-forwarder backends.
Integrations
The MQTT integration configuration has moved to the new [integration...]
section. This allows for adding new integrations in the future besides MQTT.
Hi Orne,
V3 of the Gateway Bridge code is really great achievement. The new features in both Basic Station and the Gateway Bridge look exciting. Is there any documentation available on the custom Meta Data?
Regards, Tony
Hi Orne,
Do I need to copy my previous lora-gateway-bridge.toml file as its not included in the .deb or the tar files I downloaded. I downloaded the arm7 version from https://artifacts.loraserver.io/downloads/lora-gateway-bridge/ and neither include the toml file.
Regards
Tony
The .deb
file does not overwrite an old config file, however on a clean install it should generate one. Else lora-gateway-bridge -c old-config.toml configfile > new-config.toml
thanks, most appreciated
Regards
Tony
Hi Orne,
Is there any documentation currently available on sending Custom Gateway meta data?
There isn’t more documentation yet than the configuration template. Stay tuned as this is still a test release
No worries. Thanks for the update.
LoRa Gateway Bridge v3.0.0-test.3
Features
Basic Station packet-forwarder support
The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.
Updated payload formats
The uplink payload contains a context
field, used to store gateway specific context data (like the internal counter).https://www.loraserver.io/lora-gateway-bridge/gateway/multitech/
The downlink frame contains a timing
field which can be either IMMEDIATELY
, DELAY
or GPS_EPOCH
. Based on the timing
value, an additional object must be given with the additional timing information. Refer to Commands
for more details.
Fhttps://www.loraserver.io/lora-gateway-bridge/gateway/multitech/ake RX time
In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)
Custom gateway meta-data
This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …
Upgrading
LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:
MQTT topics
The MQTT topic configuration has been updated from:
uplink_topic_template="gateway/{{ .MAC }}/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/{{ .MAC }}/stats"
ack_topic_template="gateway/{{ .MAC }}/ack"
config_topic_template="gateway/{{ .MAC }}/config"
To:
event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
command_topic_template="gateway/{{ .GatewayID }}/command/#"
Event types are: up
, stats
and ack
.
Commands are: down
and config
.
Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+,
but you will need to update the MQTT topics in your loraserver.toml
file.
Example snippet:
uplink_topic_template="gateway/+/event/up"
stats_topic_template="gateway/+/event/stats"
ack_topic_template="gateway/+/event/ack"
downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"
Backends
With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...]
section. This has changed and the [backend...]
section is now used for selecting and configuring the packet-forwarder backends.
Integrations
The MQTT integration configuration has moved to the new [integration...]
section. This allows for adding new integrations in the future besides MQTT.
Prometheus metrics
The Prometheus metrics have been updated / cleaned up.
I’ve also added vendor specific gateway .ipk
packages to https://artifacts.loraserver.io/vendor/ for testing
LoRa Gateway Bridge v3.0.0-test.4
Features
Basic Station packet-forwarder support
The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.
Updated payload formats
The uplink payload contains a context
field, used to store gateway specific context data (like the internal counter).
The downlink frame contains a timing
field which can be either IMMEDIATELY
, DELAY
or GPS_EPOCH
. Based on the timing
value, an additional object must be given with the additional timing information. Refer to Commands for more details.
Azure IoT Hub integration
LoRa Gateway Bridge now has support to connect the Azure IoT Hub MQTT interface. Like with the Google Cloud Platform IoT Core integration this
makes it easier to scale up and manage gateway credentials using the IoT Hub console (or API).
Fake RX time
In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)
Custom gateway meta-data
This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …
Upgrading
LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:
MQTT topics
The MQTT topic configuration has been updated from:
{{}}
uplink_topic_template=“gateway/{{ .MAC }}/rx”
downlink_topic_template=“gateway/{{ .MAC }}/tx”
stats_topic_template=“gateway/{{ .MAC }}/stats”
ack_topic_template=“gateway/{{ .MAC }}/ack”
config_topic_template=“gateway/{{ .MAC }}/config”
{{}}
To:
{{}}
event_topic_template=“gateway/{{ .GatewayID }}/event/{{ .EventType }}”
command_topic_template=“gateway/{{ .GatewayID }}/command/#”
{{}}
Event types are: up
, stats
and ack
.
Commands are: down
and config
.
Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+, but you will need to update the MQTT topics in your loraserver.toml
file. Example snippet:
{{}}
uplink_topic_template=“gateway/+/event/up”
stats_topic_template=“gateway/+/event/stats”
ack_topic_template=“gateway/+/event/ack”
downlink_topic_template=“gateway/{{ .MAC }}/command/down”
config_topic_template=“gateway/{{ .MAC }}/command/config”
{{}}
Backends
With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...]
section. This has changed and the [backend...]
section is now used for selecting and configuring the packet-forwarder backends.
Integrations
The MQTT integration configuration has moved to the new [integration...]
section. This allows for adding new integrations in the future besides MQTT.
Prometheus metrics
The Prometheus metrics have been updated / cleaned up.
Is there a particular branch that we should be using from Github in order to build/test this if we are running with additional Yocto layers for our devices?
Thanks
Please note that there is a stable release already. I will update the Yocto recipes, until then you can change the URL in the recipe to the latest v3 release.