[release] LoRa Server v2.8

brocaar · April 25, 2019, 9:47am

LoRa Server v2.8.0

Features

Add `mqtt2to3` sub-command

This sub-command translates MQTT messages from the old topics to the new topics (gw > ns) and backwards (ns > gw) and should help when migrating from v2 to v3 MQTT topics (see below).

This sub-command can be started as (when using the Debian / Ubuntu package):

/etc/init.d/loraserver-mqtt2to3 start
systemctl start loraserver-mqtt2to3

From the CLI, this can be started as:

loraserver mqtt2to3

As soon as all LoRa Gateway Bridge instances are upgraded to v3, this is no longer needed.

Azure integration

Using the Azure integration, it is possible to connect gateways using the Azure IoT Hub service. This feature is still experimental and might (slightly) change.

Upgrading

As a preparation to upgrade to LoRa Server v3, it is recommended to update the MQTT topic configuration to:

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"

Together with the mqtt2to3 sub-command (see above), this stays compatible with LoRa Gateway Bridge v2, but also provides compatibility with LoRa Gateway Bridge v3. Once LoRa Server v3 is released, it is recommended to first upgrade all LoRa Gateway Bridge instances to v3 and then upgrade LoRa Server to v3.

brocaar · May 1, 2019, 2:14pm

LoRa Server v2.8.1

Improvement

Validate DevAddr on enqueue

A DevAddr field has been added to the MulticastQueueItem API field. When this field is set, LoRa Server will validate that the current active security-context has the same DevAddr and if not, the API returns an error.

This prevents enqueue calls after the device (re)joins but before the new AppSKey has been signalled to LoRa App Server.

bconway · May 1, 2019, 3:08pm

Thanks! I see an app-server 2.6.1 tag on Docker Hub, I will look forward to loraserver 2.8.1 there as time allows.

sagarpatel · May 7, 2019, 8:42am

Hii @brocaar

after upgrading loraserver v2.8.1 we have started 2 nodes of MAC v1.1.x but 1 nodes was not joining (problem with JoinAccept ack to node or rx2timeout issue)
it will working automatically after 2-3 min but another node was not working (STATUS: BUSY)

###### ===== MLME-Confirm ==== ######
STATUS      : Rx 2 timeout

in previous version of loraserver it will work
only 1 node was working at a time

ISM Band: EU433
Enabled_uplink_channel:[0,1,2]

can you please help me…!
Thank you

brocaar · May 7, 2019, 9:44am

I’m not sure how this could be related to the v2.8.1 changes. If you think this is a bug, could you provide instructions (as specific as possible) how I can reproduce this?

sagarpatel · May 7, 2019, 10:07am

Thanks @brocaar

In older version we have tested LoRaWAN v1.1.x 3 devices were working perfectly at a same time.
When we upgraded to latest version of LoRaServer & Lora App Server and tried to test all v1.1.x 3 devices running same time, We have seen strange behavior. See below

When we are starting 3 devices, our first device is working fine but other 2 devices are not getting JoinAccept ACK or rx2timeout so they are sending JoinRequest again
after some time 2nd or 3rd device successed and able to work normally, however then our 1st devices loose its connectivity and it doesn’t get ACK so it moves to BUSY state.
So we observed that at the given time, only one device is able to work successfully

brocaar · May 7, 2019, 12:19pm

I have double-checked, but I can not reproduce this issue. Have you checked your logs on errors?

sagarpatel · May 7, 2019, 12:28pm

@brocaar

we cannot get any errors in log, we are getting only warning.

time="2019-05-07T17:50:23+05:30" level=warning msg="link_adr request not acknowledged" channel_mask_ack=true data_rate_ack=false dev_eui=xxxxxxxxxxxxxx18 power_ack=true

time="2019-05-07T17:50:30+05:30" level=warning msg="link_adr request not acknowledged" channel_mask_ack=true data_rate_ack=false dev_eui=xxxxxxxxxxxxxx94 power_ack=true

Can you please help us…?
Thank you

brocaar · May 8, 2019, 9:33am

Please look into the live LoRaWAN frame logs to see what LoRa Server is requesting in the LinkADRReq and if this (data-rate) is valid for your device region. If it is a valid data-rate, you need to find out why your device is rejecting it.

sagarpatel · May 8, 2019, 9:37am

@brocaar
Our LoRaWAN frame logs

ISM Band: EU433

brocaar · May 8, 2019, 11:32am

The data-rate is valid according to the LoRaWAN Regional Parameter specifications, but your device does not accept it (for whatever reason):

This is not an issue related to your LoRa Server update to 2.8.1. You could update your service-profile to for example Max DR: 5 and see if your devices accept that data-rate.

sagarpatel · May 8, 2019, 1:19pm

Thank you @brocaar

Max DR: 5 in service-profile works successfully.

mluis1 · May 8, 2019, 2:35pm

The end-device is refusing DR6 because the region default channels don’t support the given datarate.

In regional parameters specification the EU433 default channels are defined as shown below:

As you can observe the maximum datarate that can be used on default channels is DR5.

Please also note that the specification doesn’t allow the modification of default channels parameters.

This means that the network server should not attempt to set a datarate bigger than DR5 when only the default channels are enabled.

If one wants to use higher datarates than DR5 then he must define new channels, on the network server and on the gateway, using the full datarate range. [DR0…DR7]

sagarpatel · May 9, 2019, 4:19am

Thanks @mluis1

if i want to use higher data rate then DR5 must be define new channel in

loraserver.toml

# Extra channel configuration.
Example:
  # [[network_server.network_settings.extra_channels]]
  # frequency=867100000
  # min_dr=0
  # max_dr=5

OR

Add extra channel configuration in gateway-profile.

if we use higher datarates then DR5 so it will impact on range?
if we use more than 5 devices same time on 1 gateway so it will work?

brocaar · May 9, 2019, 7:25am

You must define them in loraserver.toml.

sil · May 16, 2019, 2:12pm

Hey @all

after upgrading from loraserver 2.5.0 to 2.8.1 i have problems with the spreading-factor. while in version 2.5.0 i have SF 7 from my testdevice, i have now SF 12.

i tried the following so far:

same config file for version 2.5.0 in 2.8.1.
create a new config file out of the binary and changed all my config stuff (redis, mqtt, postgres).

i can reproduce this error by creating a new instance in version 2.5.0 and use 2.8.1 then.

questions are:

does anybody has a idea how to fix this?
do i have to use the different steps (maybe 2.5.0 to 2.6.0, to 2.7.0 and so on

any help would be nice,
thx and regards,

sil

brocaar · May 16, 2019, 2:17pm

How is your service-profile configured with regards to min / max DR?

sil · May 16, 2019, 2:22pm

as i am not really understand this, i added 1 on min and 100 on max. i do more researches on this.

brocaar · May 16, 2019, 2:25pm

Please refer to the LoRaWAN Regional Parameters to find the min / max allowed data-rates for your region.

sil · May 16, 2019, 2:41pm

first of all, thx for your help. i found this on the LoRaWAN Regional Parameters for EU:

so i set the values to min 0, max 6, and i tried with 0 and 7, but the issue is the same