A new version of LoRa Server (0.20.0), LoRa App Server (0.11.0) and LoRa Gateway Config (0.1.0, initial version) has been released! These releases make it possible to configure the channel-configuration active on your gateways from a central place. The LoRa Gateway Config component (which will run on your gateway) will poll periodically if there is new configuration and if, so updates the packet-forwarder configuration and restarts the packet-forwarder to apply these new changes.
Before upgrading LoRa Server, make sure to configure the --gw-server-jwt-secret / GW_SERVER_JWT_SECRET configuration flag (as mentioned in the change-log). E.g. the value could be the output of ‘openssl rand -base64 32’.
You can read more about the LoRa Gateway Config component at https://docs.loraserver.io/lora-gateway-config/. As each gateway is setup and configured differently, please share the steps you took to install the LoRa Gateway Config component so that we can add this to the documentation! Please share your feedback on this new feature below!
…and restarts the packet-forwarder process in case of any changes.
…command configured by the --pf-restart-command will be executed by LoRa Gateway Config each time there is a configuration update.
I have systemd running the services under separate users (which is the secure way of running services), so how can it restart the packet-forwarder? Even if I run the LoRa Gateway Config under the same user as the packet-forwarder is being run, can it issue the systemctl restart packet-forwarder command? Or should it be run as root?!
I am looking for more information on this,being new to LoRa.
I previously tried to install LoRa Server on a Pine A64, without success (Linux issue???)
I have successfully installed LoRa Server on Ubuntu 16.04 LTS.
I was able to see the Frame Log Data of an ABP End Node. The OTAA End Node did not seem to join or send anything.
Our Gateway is an 8 channel 915 MHz unit (Raspberry Pi 3 B and LoRaGo Port) and we are in Canada, so we are suing the US 915 MHz Hybrid configuration in the STM LoRa Discovery firmware.
I found this Channel Management page in the LoRa Server interface, and defined channels 0, 1, 2, 3, 4, 5, 6, 7 and still no OTAA. After much reading and theorizing, I added channel 64. Now the entry is, 0, 1, 2, 3, 4, 5, 6, 7, 64.
Is this correct?
The OTAA ENd Node seems to have joined the network and we are now seeing Frame Log Data on the LoRa Server web interface.
This will be improved in one of the next releases, but please note that this feature is to keep a group of gateways in sync (channels). I’m not sure if you have setup this component? However I think it might not (yet) be needed. What you do need to configure is (in LoRa Server configuration):
# Enable only a given sub-set of channels
#
# Use this when ony a sub-set of the by default enabled channels are being
# used. For example when only using the first 8 channels of the US band.
#
# Example:
enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]
This makes sure that once the devices is activated on the network, LoRa Server will re-adjust the channel mask of the device accordingly.
Example why this is different from the channel-management feature:
You might have two channel configuration-sets (first 8 channels block, second 8 channels block) which you distribute over your gateways
Then you set the enabled_uplink_channels to 0 - 15 as you want to enable the first 16 channels for your devices
Thank you for the information.
I had configured both and in both had, 0,1, 2, 3, 4, 5, 6, 7, 64.
We are in Canada and the US 902-928 rules apply here also.
