LoRaWAN Testnetz in zwei Stunden

Bedingt durch Neugier und unser Engagement in der Arbeitsgruppe Smart City unseres Branchenverbandes Hannover IT war unser Ziel, schnell ein LoRaWAN Testnetz aufzubauen um Erfahrung bezüglich der konkreten Reichweite unter realen Bedingungen zu sammeln sowie The Things Network als Plattform besser zu verstehen.

Dafür haben wir uns mit fertigen und für den Produktiveinsatz geeigneten Komponenten ausgestattet.

• LORIX One Gateway von Wifx
• adeunis Field Test Device (ARF8123AA)

LORIX One Gateway Unboxing

Alle LORIX-One-Komponenten auf einen Blick

LORIX One mit Strom versorgt, bootet zum ersten Mal

Vorläufige Position des Gateways

Erste Verbindung mit dem FTD zum Gateway

Installation des Gateways

Das LORIX One ist ein in sich geschlossenes System, welches lediglich Anschluss an ein Netzwerk und eine Stromversorgung benötigt. Nachdem wir das Gateway über den mitgelieferten PoE Injektor mit unserem Netzwerk verbunden haben, geben wir dem Gerät ein paar Minuten Zeit um zu booten.

Achtung: das Gateway verwendet 24V passives PoE, sodass ein normaler PoE-Switch (802.3af, 802.3at) nicht als Stromversorgung taugt.

Bei Auslieferung ist eine statische IP Adresse im Lorix ONE gesetzt: 192.168.1.50. Wir konfigurieren diese also kurz statisch auf dem PC der zum Einrichten genutzt wird.
ip address add 192.168.1.1/24 dev enp0s31f6
Wobei enp0s31f6 der Name des verbundenen Netzwerk Interface ist. Ein kurzer ping-Test zeigt uns die Erreichbarkeit des Gateways.

ping 192.168.1.50

Jetzt loggen wir uns per SSH direkt auf dem LORIX System ein und bestätigen die Abfrage nach dem korrekten Host Key mit „yes“. Der vorgegebene Benutzername ist “admin”. Das Passwort ist “lorix4u”.

ssh 192.168.1.50 -l admin

Zunächst ändern wir das Passwort und kopieren unseren SSH Key, um uns in Zukunft ohne Passwort einloggen zu können.

sama5d4-lorix-one-512:~$ passwd
[...]
logout
ssh-copy-id admin@192.168.1.50
[...]
ssh 192.168.1.50 -l admin

Und wir ändern das default root Passwort.

sudo passwd

In unserem Netzwerk werden Adressen per DHCP vergeben. Also passen wir die Konfiguration entsprechend an, wie es im Abschnitt 7.5.2 der Anleitung vorgegeben ist. Konfigurationsdateien müssen dabei mit root-Rechten, also mit vorangestelltem sudo-Befehl bearbeitet werden.

sama5d4-lorix-one-512:~$ sudo vi /etc/network/interfaces

## Neuer Inhalt der Konfigurationsdatei
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
auto lo
iface lo inet loopback
# Main wired interface
auto eth0
iface eth0 inet dhcp

sama5d4-lorix-one-512:~$ sudo /etc/init.d/networking restart

Die Verbindung per SSH wird nach den vorangehenden Zeilen getrennt, da das Gerät jetzt versucht, eine neue IP Adresse per DHCP zu beziehen.
Mit der auf dem Gerät aufgedruckten MAC Adresse lässt sich das DHCP Lease leicht finden. Auf unserer PFSense Firewall z.B. im Bereich Status > DHCP Leases.
Die aktive SSH Session kann mittels Shift+~ gefolgt von einem . beendet werden. Danach verbinden wir uns erneut zum LORIX und bestätigen den Host-Key für die neue Adresse mittels yes.

➜  ~ ssh admin@192.168.2.62

Wir korrigieren noch schnell die Zeitzone

ls -la /etc/localtime
lrwxrwxrwx 1 root root 29 Oct 27 15:37 /etc/localtime -> /usr/share/zoneinfo/Universal

sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

date
Mon Apr 15 17:24:43 CEST 2019

Das angezeigte Datum ist nicht korrekt. Ein ps aux | grep ntp verrät uns, dass keine Synchronisation mit einem NTP Server stattfindet. Das holen wir nach.

sudo /etc/init.d/ntpd start

date
Tue Jul  2 16:47:16 CEST 2019

Das sieht schon besser aus. Also richten wir ntpd als automatisch gestarteten Dienst ein.

sudo update-rc.d ntpd defaults
System startup links for /etc/init.d/ntpd already exist.

Einen Reboot später läuft der ntp Daemon:

sudo reboot; logout

ps aux | grep ntp
ntp        945  0.1  1.4   5412  1724 ?        Ssl  16:48   0:00 /usr/sbin/ntpd -u ntp:ntp -p /var/run/ntpd.pid -g

Jetzt ist es Zeit, das Gateway an eine Community anzubinden.

Einbinden in The Things Network

Wir möchten unsere Hannover Community im The Things Network erweitern:

Das LORIX One ist bereits für diverse Communities vorbereitet. Die Details kann man im Wiki des Hestellers nachlesen. In Kürze: es wird das Script clouds-manager.sh bereitgestellt, mit dem die verschiedenen Packet-Forwarder gesteuert werden.

sama5d4-lorix-one-512:~$ sudo /etc/init.d/clouds-manager.sh status
Password:
Cloud loriot status:
/opt/lorix/clouds/loriot/loriot-gw (pid 894) is running…

Das loriot Gateway läuft also gerade. Wir stoppen zunächst das Gateway.

sudo /etc/init.d/clouds-manager.sh stop

Und konfigurieren das Cloud Manager Script:

/etc/init.d/clouds-manager.sh configure

==========================================
| LORIX One clouds manager configuration |
==========================================

Actual configuration:
  autostart=true
      cloud=loriot

Do you want to enable autostart at boot time?
[Yes|No]
 > Yes

Which cloud app. do you want to use ?
[loriot|packet-forwarder|ttn|manual]
 > ttn

New configuration:
  autostart=true
      cloud=ttn

Wir nutzten eine Outdoor Antenne, genauer die L-com HyperLink HG908U-PRO. Mit einer Indoor Antenne müsste die Konfiguration wie folgt angepasst werden.

cd /opt/lorix/clouds/ttn/
sudo cp EU_global_conf_2dBi_indoor.json global_conf.json

Jetzt passen wir die allgemeine Konfiguration an, nachdem wir ein Backup des Original erstellt haben:

sudo cp local_conf.json local_conf.json.orig
sudo vi local_conf.json

{
/* Put there parameters that are different for each gateway (eg. pointing one gateway to a test server while the others stay in production) */
/* Settings defined in global_conf will be overwritten by those in local_conf */
    "gateway_conf": {
        "gateway_ID": "0001fcc23d0b63e4",

        "servers": [
            {
                "server_address": "router.eu.thethings.network",
                "serv_port_up": 1700,
                "serv_port_down": 1700,
                "serv_enabled": true
            }
        ],
        "fake_gps": false,
        "ref_latitude": 10,
        "ref_longitude": 20,
        "ref_altitude": -1,
        "contact_email": "info@atmina.de",
        "description": "Hannover City-Center Gateway at ATMINA Solutions"
    }
}

Wir setzen gateway_ID auf eine Kombination aus Zähler (0001) und MAC Adresse des Gateways und ändern die contact_email und description. Die GPS Position setzen wir manuell im TTN Backend. Wir sichern die Konfigurationsdatei, da sie bei einem Update der Softwarepakete überschrieben wird, und starten dann den Forwarder.

sudo cp local_conf.json local_conf.json.atmina
/etc/init.d/clouds-manager.sh start

In der TTN Console legen wir ein neues Gateway an, setzen die gateway_ID auf obigen Wert und legen mit Hilfe der Satellitenkarte die Position fest.

Wenige Minuten später können wir unser Gateway mit dem Status „online“ in der Konsole finden. Im Tab „Traffic“ kann live mitverfolgt werden, welche Pakete das Gateway an die TTN Infrastruktur weiterleitet und umgekehrt (uplink, downlink).

Was kommt als nächstes

Insgesamt haben wir in weniger als zwei Stunden ein LoRaWAN Outdoor-Gateway aufgebaut. Wir werden mit der Position der Antenne experimentieren und Reichweiten-Tests mit TTNMapper durchführen. Danach sollen eigene Sensorknoten und eine eigene TTN Application folgen. Wir freuen uns auf regen Austausch auf dem Hannover LoRaWAN Day am 1. November.

Links

• Hannover LoRaWAN Meetup
• TheThingsNetwork Community Hannover
• Status unseres Gateway (JSON)
• Wir haben uns bei den Artikeln von Charles-Henri Hallard und Mario Zwiers inspirieren lassen. Sie haben ein ähnliches Setup verwendet.