[release] LoRa (App) Server v2 with LoRaWAN 1.1 support + new UI

brocaar · July 30, 2018, 11:46am

Changelogs

LoRa App Server v2.0.0

Upgrade notes

Before upgrading to v2, first make sure you have the latest v1 installed and running
(including LoRa App Server). As always, it is recommended to make a backup
first

Features

LoRaWAN 1.1 support

This release adds support for LoRaWAN 1.1 devices (meaning that both LoRaWAN 1.0
and LoRaWAN 1.1 devices are supported). Please note that the LoRaWAN 1.0 AppKey
is now called NwkKey and LoRaWAN 1.1 adds a new key called AppKey.

(Encrypted) key signaling

The LoRa App Server join-server API supports using Key Encryption Keys (KEK)
for encrypting the session-keys on a (re)join-request, requested by LoRa Server.
It will also send the (encrypted) AppSKey in this response to LoRa Server.

When LoRa Server receives the first uplink from the device (in case of a rejoin-request,
this will be the first uplink using the new security context), it will send this
(encrypted) AppSKey together with the application payload to LoRa App Server.
This will also be the moment when LoRa App Server will sent the join notification!

New UI

The LoRa App Server web-interface has been re-designed with a focus on better
navigation. All main components are now accessible from a sidebar.

Changes

Device-status

The device-status has been removed from the uplink payload and is sent over
a separate MQTT topic (or HTTP integration). This to make sure that the
the device-status is only published when an update is available.
See also Sending and receiving data.

API changes

The API has been cleaned up to improve consistency and usability. This update
affects most of the endpoints! Most of these changes can be summarized by
the following example (where device is a separate object which now can be
re-used for create / get and update methods).

Old API

POST /api/devices

{
  "name": "test-device",
  "devEUI": "0102030405060708",
  "applicationID": "123"
  ...
}

New API

POST /api/devices

{
  "device": {
    "name": "test-device",
    "devEUI": "0102030405060708",
    "applicationID": "123"
    ...
  }
}

InfluxDB changes

The device_uplink measurement spreading_factor, bandwidth, modulation
and bitrate tags are now replaced by a single dr tag.

Uplink message payload

The uplink message payload (used for MQTT and HTTP integrations) has been
modified slightly:

It now contains a dr field indicating the used uplink data-rate.
Location related fields of each rxInfo element has been moved inside a location object.
MAC has been renamed to gatewayID for each rxInfo element.
The adr field has been moved out of txInfo and moved into the root object.

Downlink queue changes

The reference field has been removed to simplify the downlink queue handling.
When using the REST or gRPC API interface, the response to an enqueue action
contains the frame-counter mapped with the downlink queue item. This
frame-counter then can be used to map the acknowledgement in case of a confirmed
downlink payload.

LoRa Server v2.0.0

Upgrade nodes

Before upgrading to v2, first make sure you have the latest v1 installed and running
(including LoRa App Server). As always, it is recommended to make a backup
first

Features

LoRaWAN 1.1 support!
Support for signaling received (encrypted) AppSKey from join-server to
application-server on security context change.
Support for Key Encryption Keys, used for handling encrypted keys from the
join-server.

Changes

LoRa Server calls the SetDeviceStatus API method of LoRa App Server
when it receives a DevStatusAns mac-command.
Device-sessions are stored using Protobuf encoding in Redis
(more compact storage).
Cleanup of gRPC API methods and arguments to follow the Protobuf style-guide
and to make message re-usable. When you’re integrating directly with the
LoRa Server gRPC API, then you must update your API client as these changes are
backwards incompatible!
Config option added to globally disable ADR.
Config option added to override default downlink tx power.

How to upgrade

Debian / Ubuntu

Change to the 2.x stable repository:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00

sudo echo "deb https://artifacts.loraserver.io/packages/2.x/deb stable main" | sudo tee /etc/apt/sources.list.d/loraserver.list

sudo apt-get update && sudo apt-get upgrade

Docker

Use 2 as tag when pulling the LoRa Server images (e.g. loraserver:2, lora-app-server:2 or lora-gateway-bridge:2).

Anucha_Promwungkwa · August 3, 2018, 8:03am

I have upgraded the LoraServer from v0.26.1 to v2.0 last night.
The old devices can uplink messages to the server without problem. But, a new device could not be activated.

Please help.

brocaar · August 3, 2018, 8:12am

What exactly do you mean with (some more context would be helpful):

But, a new device could not be activated.

Anucha_Promwungkwa · August 3, 2018, 8:29am

Dear Brocaar,

A new device, that is newly added to an Application, does not response to a message sent from the end node.

brocaar · August 3, 2018, 8:39am

I understand, but it does matter how you activate the device. E.g. ABP, OTAA. Is it a LoRaWAN 1.0.x device or a LoRaWAN 1.1 device. How did you setup the device-profile, what errors do you see in the LoRa Server logs, …

Unfortunately I don’t have a crystal ball

Anucha_Promwungkwa · August 3, 2018, 9:06am

Dear Brocaar,

Please remove the issue. It’s my fault. The LoRaWAN MAC version in Device-Profile should be 1.0.2, not 1.1. All my devices are 1.0.2.

Regards,
Anucha

brocaar · August 3, 2018, 10:09am

No worries, glad the issue has been solved

gustavobsch · August 3, 2018, 5:28pm

Hi Brocaar,

The rxInfo element is indeed gone but there’s no new ‘location’ object present in the payload…

I’m also not seeing references of this ‘location’ object in the documentation MQTT - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server

I do have the ‘Add gateway meta-data’ enabled, before the upgrade I had rxInfo present is only after upgrading that it’s gone.

Anyway I can get RSSI of the end device from somewhere else? this parameter is critical.

Thanks,
Gustavo

gustavobsch · August 3, 2018, 5:32pm

This was my payload before upgrade

application/3/node/fffffffffffffffffffff/rx {“applicationID”:“3”,“applicationName”:“gps-tracker”,“deviceName”:“fffffff”,“devEUI”:“fffffffffffffffffffff”,“rxInfo”:[{“mac”:“fffffffffffffffffffff”,“time”:“2018-08-03T16:04:32.699574Z”,“rssi”:-48,“loRaSNR”:11.8,“name”:“fffffffffffffffffffff”,“latitude”:-fff,“longitude”:-fff,“altitude”:fff}],“txInfo”:{“frequency”:904700000,“dataRate”:{“modulation”:“LORA”,“bandwidth”:125,“spreadFactor”:7},“adr”:true,“codeRate”:“4/5”},“fCnt”:28,“fPort”:1,“data”:“AAAAAAQGbX8PqZyfif1AEKb7”,“object”:{PAYLOAD HERE}}

And after, no ‘location’ element unfortunately.

application/3/node/fffffffffffffffffffff/rx {“applicationID”:“3”,“applicationName”:“gps-tracker”,“deviceName”:“fffffff”,“devEUI”:“fffffffffffffffffffff”,“txInfo”:{“frequency”:904700000,“dr”:3},“adr”:true,“fCnt”:4,“fPort”:1,“data”:“AAAAAAQHz3gPp+Cfif3oD6b7”,“object”:{PAYLOAD HERE}}

brocaar · August 5, 2018, 3:28pm

Did you enable the exposure of gateway meta-data in your service-profile?

gustavobsch · August 6, 2018, 2:45pm

Yes, it’s been enabled all along. Can you please paste a sample MQTT message to see what it looks like now? are you sure the location element is not being published to a different topic?

brocaar · August 8, 2018, 3:33am

Please see the documentation. The location is under rxInfo, this is documented under the .../rx topic. See below an example from my setup:

application/1/device/70b3d5499704b351/rx {
    "applicationID": "1",
    "applicationName": "lopy-pysense-demo",
    "deviceName": "lopy-pysense-1",
    "devEUI": "70b3d5499704b351",
    "rxInfo": [
        {
            "gatewayID": "00800000a0001b22",
            "name": "conduit-us915",
            "rssi": -72,
            "loRaSNR": 7.8,
            "location": {
                "latitude": 39.6076051,
                "longitude": -105.95329749999999,
                "altitude": 3000
            }
        }
    ],
    "txInfo": {
        "frequency": 903500000,
        "dr": 3
    },
    "adr": false,
    "fCnt": 1,
    "fPort": 2,
    "data": "AXH/4wAHA+EBhgCh/9IAAAFlAAUCZQAGAWhfAWcBDwFzHHwBiAAAAAAAAAQbLAJnAQI=",
    "object": {
        "illuminanceSensor": {
            "1": 5,
            "2": 6
        },
        "temperatureSensor": {
            "1": 27.1,
            "2": 25.8
        },
        "humiditySensor": {
            "1": 47.5
        },
        "accelerometer": {
            "1": {
                "x": -0.029,
                "y": 0.007,
                "z": 0.993
            }
        },
        "barometer": {
            "1": 729.2
        },
        "gyrometer": {
            "1": {
                "x": 1.61,
                "y": -0.46,
                "z": 0
            }
        },
        "gpsLocation": {
            "1": {
                "latitude": 0,
                "longitude": 0,
                "altitude": 2691
            }
        }
    }
}

gustavobsch · August 8, 2018, 1:21pm

Interestingly, after disabling gateway meta-data and enabling it back I can see the rxInfo element again. Thanks again.

lcer93 · August 10, 2018, 8:26am

Hi, I have a problem with the new release for Windows since I get a “rx packet error” from LoRa server even if with the same node and the same configuration of LoRa App Server on Linux it works well.

To use the new version on Windows I simply downloaded the new release and launched loraserver.exe and lora-app-server.exe from the command line. Did I miss something?

Thanks

brocaar · August 11, 2018, 12:06am

Thanks, this hint helped me to track down the issue. It is related to a cache change in v2. I’ll fix this (expect a bugfix release somewhere next week).

Edit: this has been resolved in LoRa Server v2.0.1.