3  Das LoRaWAN Projekt

Abbildung 3.1: Heltec LoRa V3

(Bild entnommen von https://heltec.org/project/wifi-lora-32-v3)

Ein paar technische Daten:

Schaltplan

Der schwarze Taster ist active low und mit GPIO6 (J3, Pin 17) verbunden. Vom Taster geht ein 10 kOhm Pullup Widerstand nach VCC (3.3V).

Die Anode der roten LED ist über einen 390 Ohm Widerstand mit GPIO7 (J3, Pin 18) verbunden, ist also active high. Die Kathode ist mit Masse verbunden.

Ein blaue Potentiometer ist mit ADC Eingang ADC1_CH0 verbunden (J3, Pin 12, entspricht GPIO1). Der ADC hat eine 12-Bit Auflösung. Die beiden Enden des Poti liegen direkt an GND und 3.3 Volt. Bei der Schaltung mit Heltec V1 hatte ich Vorwiderstände verwendet, um mehr in den linearen Bereich zu kommen. Da müsste man nachsehen, wie sich das Heltec V3 beim ADC Eingang verhält.

Das Programm ist im Repo im Ordner heltec_v3/.

3.1 Aufbauen

  • Pinleisten in Heltec Board einlöten
  • Auf Steckbrett setzen
  • Peripherie anschliessen nach Schaltplan

An dieser Stelle sollte es in etwa so aussehen:

Im Abschnitt Bauteile finden sie ein paar Informationen zu E-Technik und ein paar Bauteilen.

3.2 Testen mit Micropython

  • Micropython flashen (Anleitung)

  • Testprogramm ausführen (heltec-v3/esp32_demo.py)

    Der Zweck dieses Micropython Programms ist es, die Funktion der für den LoRaWAN Versuch bereits angeschlossenen Bauteile (LED, Taster, Poti an Analogeingang) zu überüfen. Für den LoRaWAN Versuch muss das Heltec Board natürlich dann mit der Arduino (Platformio) Anwendung geflasht werden.

LoRaWAN Demo auf das Heltec LoRa ESP32 V3 bringen

  • Die LoRaWAN Demo ist für das Arduino Framework geschrieben. Im Prinzip ist das C++, mit ein paar Vereinfachungen.

  • Die Demo findet man im git repo unter ttn_workshop/heltec_v3. Darin ist die Datei platformio.md in der beschrieben ist wie man das Programm auf der Linux Kommandozeile unter Platformio kompiliert und auf das Heltec Board flasht. Man kann immer nur eine Anwendung auf das Heltec Board flashen, in unserem Fall entweder LoRaWAN oder Micropython.

    Anleitung für Platformio: platformio.md

    Hier ist nochmal der Link auf das Repo: https://gitlab.com/huberthoegl/ttn_workshop

3.3 Einstellungen in der TTN Konsole

Bitte nicht meine Einstellungen nehmen, sondern eigene erzeugen!

Zusammenfassung

  • Applikation anlegen; Application ID vergeben (gleiche ID nur 1x möglich!)

  • Application Name (sollte eher kurz sein; Beschreibungs-Feld gibt es auch)

  • End Device anlegen

    • Daten manuell eingeben (da Selbstbaugerät)
    • Frequency Plan
    • LoRaWAN Spec 1.1.0
    • In den “General Settings” des Device muss bei den “Join Settings” angeklickt sein: “Resets join nonces” [✔]“.
    • JoinEUI auf 00 00 … setzen (war früher AppEUI)
    • DevEUI generieren
    • AppKey generieren
    • Abschliessend die End Device ID auf einen lesbaren Namen setzen, z.B. heltec-v3-demo-dev1

Die DevEUI muss in der Reihenfolge “Little-Endian” übertragen werden, d.h. die in der TTN Konsole gezeigte Reihenfolge der Bytes muss umgedreht werden!

3.4 API Keys

Wenn man aus einem Shell Skript, einem Python Programm oder einem Programm wie z.B. curl auf die Daten des TTN Servers zugreifen will, dann braucht man immer einen API Key. Den Key muss man in der TTN Konsole erzeugen (+ Add API Key). Er erhält einen Namen und einen Wert. Der Name ist in meinem Beispiel “heltec-demo-api-key”, der Wert ist nur direkt bei der Erzeugung sichtbar und muss gesichert werden. Nach Abschluss ist der Wert nicht mehr zugänglich.

Der Key könnte in etwa so aussehen, muss aber natürlich an den eigenen Key angepasst werden:

NNSXS.ABS3TTW5OBMNZRBIW5ZMQDEC74N63JXYPAWAHVQ.GXO3XHNDPBYM2NW5I5ZYAMX6WNF3KRTX2FUW2YTFVXJXPVYFAGUQ

Die Demo-Programme für den Workshop lesen diesen API Key aus der Umgebungsvariable WORKSHOP_API_KEY ein. Diese muss deshalb erst mal gesetzt werden. Das macht man mit dem folgenden Kommando in der Shell:

export WORKSHOP_API_KEY=NNSXS.ABS3TTW5OBMNZRBIW5ZMQDEC74N63JXYPAWAHVQ.GXO3XHNDPBYM2NW5I5ZYAMX6WNF3KRTX2FUW2YTFVXJXPVYFAGUQ

Dadurch bleiben die Skripte (1) unabhängig vom Schlüssel und können (2) auf öffentlichen Git Servern aufbewahrt werden, ohne dass Geheimnisse weitergegeben werden.

Die Key ID ist lediglich ein eindeutiger Bezeichner für den Schlüssel. Auf den Wert des Schlüssels kann nicht mehr zugegriffen werden. Sollte der Wert verloren gehen, muss man einen neuen Schlüssel erzeugen.

Hier sind eine Reihe von Bildschirmkopien die zeigen wie der API Key erzeugt wurde:

1 | 2 | 3 | 4 | 5

3.5 Es läuft

Es läuft zum ersten Mal. Wir sehen dass das Gerät aktiv ist (“Last activity XXX seconds ago”). Die Uplink Daten kommen im Reiter “Live data” in der Konsole an. Man sieht die Payload in Form der einzelnen Byte 00 30 00 00 00 Wenn man auf die Zeile mit den Daten klickt, dann öffnet sich ein Fenster mit einem “riesigen” JSON Objekt, es enthält u.a. frm_payload": "ADAAAAA=", das ist die Payload im Base64 Format.

Mit dem schon erwähnten Programm kann man diese Kodierung in Bytes umwandeln und erhält wie zu erwarten:

python base64tool.py -b ADAAAAA=
0x00  0x30  0x00  0x00  0x00

Über den Reiter “Messaging” kann man die Downlink-Daten in eine Queue einreihen. Ohne Payload Formatierer muss man zunächst direkt den Byte-Wert eingeben (00 = LED aus, 01 = LED ein).

Alternativ kann man hier auch das CLI Programm ttn-lw-cli verwenden (siehe Abschnitt “TTN CLI”:

Rote LED an

ttn-lw-cli end-devices downlink push heltec-v3-demo-1 heltec-v3-demo-dev1 --frm-payload 01 --priority NORMAL --f-port 1

Rote LED aus

ttn-lw-cli end-devices downlink push heltec-v3-demo-1 heltec-v3-demo-dev1 --frm-payload 00 --priority NORMAL --f-port 1

Wenn später die Payload Formatierung in die TTN Konsole eingebaut ist, kann man den Uplink auch im dekodierten Format betrachten z.B. { adc: 1536, button: 0 }. Auch den Downlink kann man dann über ein dekodiertes JSON Objekt steuern, z.B. { "led": "on" }.

In Abschnitt 8 “Integration” sehen wir wie man mit anderen Mitteln Uplinks abgreifen bzw. Downlinks verschicken kann.

  • MQTT Client abonniert Uplink (subscribe)

  • Uplink wird per Webhook nach Ziel-URL übertragen

  • Downlink wird per Webhook an TTN Server gesendet

3.6 Payload Formatierung

Für Heltec V3:

Payload Formatter für die LoRaWAN Demo (auch im git Repo unter ttn_workshop/formatter). Diese Formatter sind bei der angelegten Application einzutragen.

Die Payload Formatierer erlauben es, statt auf der Ebene von einzelnen Bytes Daten zu veschicken, mit strukturierten Daten im JSON Format zu arbeiten. Das funktioniert sowohl für den Uplink als auch für den Downlink. Die Formatierer werden in die TTN Konsole eingeben, es handelt sich um JavaScript Code.

      unstrukturiert (Bytes)              strukturiert (JSON)
      ------------------------------------------------------------
      00 3f                   -->         { adc: 1536, button: 0 }
      01                      -->         { "led": "on" }

Nachdem die Formatierer angelegt wurden (siehe unten) sieht man den Uplink sofort neben den Bytes auch in strukturierter Form. Auch kann man nun beim Downlink auswählen ob man Bytes oder JSON Objekte übertragen möchte.

Uplink

Der Formatierer schreibt die ersten beiden Bytes der Payload in die Variablen button und adc. Diese werden dann in ein JSON Objekt { adc: ..., button: ... } gefüllt. Der ADC Wert wird wieder um 5 Bit nach links geschoben, so dass der ursprüngliche Wertebereich wieder hergestellt wurde (natürlich fehlen nun 5 Bit Genauigkeit, aber darum geht es hier nicht).

// Uplink formatter (decoder.js)

function decodeUplink(input) {
  var adc = 0;
  var button = 0;
  button = input.bytes[0];
  adc = input.bytes[1];
  return {
    data: {
      adc: adc << 5,
      button: button
      // bytes: input.bytes,
    }
    // warnings: [],
    // errors: []
  };
}

Downlink

In der Konsole kann man beim Downlink entweder direkt die Bytes angeben (z.B. 01 (zwei Hex-Ziffern) um die LED einzuschalten), oder man kann ein JSON Objekt definieren. Für den gleichen Zweck könnte man z.B. { "led": "on" } nehmen. Die Aufgabe des Downlink Formatieres encodeDownlink() ist es, das JSON Objekt in die Bytes zu verwandeln.

Der Downlink Formatierer muss auch immer eine Umkehrungsfunktion decodeDownlink() haben, die von Bytes in das JSON Objekt umwandelt.

// Downlink formatter (encoder.js)

// Called when a downlink with decoded payload is scheduled to be sent to
// device. The result is an encoded array of bytes.
// input is either { "led": "on" } or { "led": "off" }

var led_state = ["off", "on"];

function encodeDownlink(input) {
    var b = 0;
    if (input.data.led == "on") {
        b = 1
    }
    return {
        bytes: [b],
        fPort: 1,
        warnings: [],
        errors: []
    };
}

// Decodes the binary payload back to decoded payload.
function decodeDownlink(input) {
    return {
        data: {
            // bytes: input.bytes
            led: led_state[input.bytes[0]]
        },
        warnings: [],
        errors: []
    }
}

Test der Formatierer

Die Endgeräte haben in der Konsole einen Reiter Payload formatters. Dort kann man den Uplink- und Downlink-Formatter mit Testdaten füttern und sieht dann ob er richtig funktioniert.

Test der Formatierer

Test der Formatierer

Übertragen der Formatierer mit ttn-lw-cli

Üblicherweise überträgt man die Formatierer per Copy/Paste in die entsprechenden Eingabefelder der TTN Konsole. Eleganter, da automatisierbar, ist die Übertragung per ttn-lw-cli Werkzeug. Die Formatter liegen dabei als JavaScript Dateien encoder.js und decoder.js auf der Platte.

Das Shell Skript ist in formatter/payload-formatter.sh zu finden, das ist der Inhalt:

# Muss vielleicht angepasst werden
appid=heltec-v3-demo-1

ttn-lw-cli applications link set ${appid} \
--api-key $WORKSHOP_API_KEY \
--default-formatters.down-formatter FORMATTER_JAVASCRIPT \
--default-formatters.down-formatter-parameter-local-file "encoder.js" \
--default-formatters.up-formatter FORMATTER_JAVASCRIPT \
--default-formatters.up-formatter-parameter-local-file "decoder.js"

Payload im Base64 Format

Intern werden die Daten immer im Base64 Format übermittelt, sowohl beim Uplink als auch beim Downlink. Man sieht das auch, wenn man die Payload im JSON Format in der TTN Konsole genauer untersucht. Zum Beispiel wäre die Folge der zwei Bytes 01 3A im Base64 Format ATo=.

Das kann man mit dem Programm base64/base64tool.py zum Konvertieren von Base64 in Bytes und umgekehrt nachvollziehen. Ein paar Beispiele:

python base64tool.py -B 01 3A
ATo=

python base64tool.py -b ATo=
0x01  0x3a

python base64tool.py -B 00
AA==

Die Folge der Hex-Bytes hinter der -B Option kann beliebig lang sein.

3.7 Integration

MQTT
Webhooks
Storage
Node-RED
TTN Mapper

Bisher haben wir nur interaktiv über die TTN Konsole Daten aus Upstream-Richtung betrachtet und in Downstream-Richtung eingegeben. Nun ist es das Ziel, dass man mit Programmen die auf dem eigenen Rechner laufen auf den TheThings Netzwerkserver zugreift, so dass man die TTN Konsole eigentlich nicht mehr braucht. Der Netzwerkserver bietet dafür die “Integrations”. Die zwei wichtigsten grundlegenden Integrationen sind MQTT und Webhooks. Über diese Standards kann man Uplink und Downlink vom eigenen Rechner aus erreichen.

Die Uplink-Daten gehen nach dem Empfang im Netzwerkserver verloren, man sieht sie vielleicht noch in der Konsole, kann aber nicht mehr darauf zugreifen. Die Integration “Storage” speichert die empfangenen Daten eine Weile (24 Stunden) und man kann sie über einen HTTP Endpunkt lesen.

Als nächstes stelle ich kurz Node-RED vor, keine richtige Integration, sondern ein Werkzeug für grafische Programmierung. Es kann mit dem TTN Server über MQTT und Webhooks interagieren.

Zum Schluss zeige ich den TTN Mapper. Das ist eine vorgefertigte Webhook-Integration, mit der man die ungefähre LoRa-Abdeckung in einem Gebiet ermitteln kann.

3.7.1 MQTT

Der TTN Stack stellt einen MQTT Server zur Verfügung, MQTT Version 3.1.1, QoS 0.

https://www.thethingsindustries.com/docs/integrations/other-integrations/mqtt

Die folgenden Werte müssen Sie anpassen an die konkreten Werte die Sie in der TTN Konsole verwendet haben.

User: heltec-v3-demo-1@ttn

Man muss neben dem User auch ein Passwort eingeben. Das ist entweder ein Passwort das man in der TTN Konsole bei der MQTT Integration erstellen kann oder ein API Key mit den passenden Rechten.

Device ID: heltec-v3-demo-dev1

Topic für den Uplink: v3/<user>/devices/<device-id>/up

Server: eu1.cloud.thethings.network, Port 1883 (unsafe), 8883 (safe)

Drei Demo-Clients:

  • Python: mqtt/client.py

    Paho-MQTT muss evtl noch installiert werden mit pip install paho-mqtt.

  • Mosquitto commandline client: mqtt/mosquitto.sh. Aufrufen mit bash mosquitto.sh.

    Installation:

    sudo apt install mosquitto
sudo apt install mosquitto-clients

  • Node-Red (siehe Abschnitt ganz unten)

3.7.2 Webhooks

https://www.thethingsindustries.com/docs/integrations/webhooks

Auf “Webhooks” basieren jede Menge Dienste, die meist von externen kommerziellen Dienstleistern stammen. Wenn man bei der Webhook Integration auf + Add webhook klickt, dann sieht man sofort eine Menge Dienste, hier sind Bildschirmkopien: Webhooks1 | Webhooks2. Fast alle sind externe Dienstleister die meist einen kostenlosen Einstiegstarif anbieten, oft ist dieser aber in irgend einer Form beschränkt.

Der Dienst ganz links oben auf Webhooks1 ist der “Custom Webhook” den man für eigene Zwecke konfigurieren kann.

Die Anwendung heltec-v3-demo-1 hat eine solche Custom Webhook Integration bekommen.

webhook

Nun klickt man auf die Zeile heltec-v3-demo-wh, danach sieht man die Einstellungen die man bei diesem Webhook vornehmen kann:

Webhook Konfiguration

Die Webhook-ID ist heltec-v3-demo-wh. Als einzig wichtigen Parameter muss man die Base URL angeben, diesen habe ich auf https://webhook.site gesetzt. Das ist ein praktischer Dienst, mit dem man untersuchen kann, welche Daten ein Webhook tatsächlich abliefert. Siehe webhooks/README.md.

Wenn der Webhook die Daten nicht abliefern kann, weil z.B. kein Endpunkt zur Verfügung steht, dann deaktiviert sich der Dienst automatisch. Man kann nun auf die Integration klicken und diese wieder reaktivieren.

Im produktiven Einsatz würde man nicht webhook.site verwenden, sondern einen eigenen Webhook Server betreiben, der vom TTN Server die HTTP Webhook-Aufrufe erhält und der die im JSON Format übermittelten Daten abspeichert, auswertet, etc. Eine gut funktionierende Software für diesen Zweck ist der webhookd, siehe https://github.com/ncarlier/webhookd. Im Abschnitt Container finden Sie eine kurze Anleitung wie man den webhookd als Container starten kann.

Die typischen Anwendungsfälle sind:

  • Uplink-Daten vom TTN Server auf einen anderen Rechner übertragen

  • Downlink-Daten von einem anderen Rechner auf den TTN Server übertragen

3.7.3 Storage

https://www.thethingsindustries.com/docs/integrations/storage

Man kann die Storage Integration für die Applikation oder individuell für ein Gerät in der Applikation ein- oder ausschalten. Für heltec-v3-demo-1 ist sie aktuell nicht aktiviert.

Man sollte nicht zu viel erwarten, die Daten kommen nicht in Echtzeit an und werden auch nur eine bestimmte Zeit (24 Stunden) aufgehoben.

Die Daten bekommt man von den Endpunkten:

GET https://eu1.cloud.thethings.network/api/v3/as/applications/heltec-v3-demo-1/packages/storage/{type}
GET https://eu1.cloud.thethings.network/api/v3/as/applications/heltec-v3-demo-1/devices/{device_id}/packages/storage/{type}

Siehe das Verzeichnis storage im Git Repository. Abrufen der gespeicherten Einträge z.B. mit curl, siehe bash get-storage.sh, oder besser formatiert mit bash get-storage.sh | jq . | less.

3.7.4 Node-Red

Siehe auch den Abschnitt in den Zuhörthemen.

https://www.thethingsindustries.com/docs/integrations/other-integrations/node-red

Node-RED (https://nodered.org) ist eine “low code” Programmierumgebung, in der man einfache Datenverarbeitungsabläufe grafisch im Web-Browser zeichnen kann. Man setzt Knoten (Nodes) in ein Zeichenfeld und verbindet die Knoten mit geschwungenen Linien. Für die Anbindung an den TheThings Network Server gibt es z.B. einen MQTT Knoten, den man mit den Verbindungsdaten konfigurieren kann.

Im Abschnitt Container ist eine Anleitung wie man Node-RED als Container starten kann.

Man kommt auf die Node-RED Oberfläche über den Web Browser mit folgendem Link:

http://127.0.0.1:1880

Das Dashboard hat einen separaten Link:

http://127.0.0.1:1880/ui

Mit der Dashboard-Erweiterung bekommt man neue Knoten in der Kategorie “Dashboard”, z.B. Text, Gauge und Chart. Dazu müssen die Pakete node-red-dashboard und node-red-contrib-moment installiert worden sein.

Bildschirmkopie: Dashboard mit Poti

Der dazugehörige Node-RED “Flow” ist im Verzeichnis node-red in der Datei heltec-flow.json enthalten.

3.7.5 TTN Mapper

Der TTN Mapper ist eine Web Anwendung auf https://ttnmapper.org. Man benötigt ein LoRa Endgerät, das über ein GPS Modul verfügt. Die Endgerätesoftware übermittelt periodisch die aktuellen GPS Koordinaten an den TTN Server. Die Applikation (oder das Endgerät) auf dem Server muss mit der vorgefertigten Webhook-Integration “TTN Mapper” verknüpft werden. Dadurch werden die empfangenen Daten inklusive des GPS Standortes auf ttnmapper.org per HTTP Push weitergereicht.

Bildschirmkopien:

  • Webhook Konfiguration

  • Auf ttnmapper.org:

    • Menüpunkt Advanced Maps Die gezeigte Device ID eui-70b3d57ed004c4a0 gehört meinem Mapper Endgerät.

    • Radfahrt am 22.4. Von zu Hause zur Hochschule und wieder zurück.

    • Radfahrt/Spaziergang am 23.4. Von zu Hause, Pfersee, Bahnhof, Innenstadt (Annastrasse), Rathaus, Maxstrasse, Wintergasse, Predigerberg, Bäckergasse, Puppenkiste, Hochschule und zurück. In einem Grossteil der Innenstadt gab es leider keine LoRa Verbindung zu einem Gateway. Erst ab der Gegend der Bäckergasse hat man wieder Empfang durch die Hochschul-Gateways und das “Maiskolben”-Gateway.

Der URL beim TTN Mapper kodiert die Device-ID, Start- und Enddatum.

https://ttnmapper.org/devices/?device=eui-70b3d57ed004c4a0&startdate=2023-04-23&enddate=2023-04-23&gateways=on&lines=on&points=on

3.8 Kommandoreferenz

Platformio
ttn-lw-cli
base64tool.py
MQTT
Webhooks
Node-RED

3.8.1 Platformio

  • Installieren mit

    python3 -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"

    Es gibt danach den Ordner .platformio im Homeverzeichnis.

  • Virtuelle Umgebung aktivieren (der Punkt am Anfang gehört so, das ist das source Kommando!)

    . ~/.platformio/penv/bin/activate

    Nun sollte das Kommando pio gefunden werden, am besten mal which pio eingeben und danach pio --version:

    which pio
/home/hhoegl/.platformio/penv/bin/pio

pio --version
PlatformIO Core, version 6.1.6

  • Nun in das heltec Verzeichnis mit dem Beispielprogramm gehen. Dann aufrufen:

    project init --board heltec_wifi_lora_32

    Danach gibt es im heltec Verzeichnis einen versteckten Ordner .pio. In diesem befindet sich z.B. die benötigte LoRa Bibliothek. Ausserdem wurde der Ordner .platformio im Homeverzeichnis viel grösser (1,6G), da nun der Compiler und das Arduino-Framework für das Heltec Board (ESP32) darin installiert wurden.

  • Code kompilieren mit

    pio run

  • Code auf das Heltec Board übertragen mit

    pio run -t upload

    Das angesteckte Heltec Board ist über ein USB Kabel mit dem PC verbunden. Das USB Kabel dient der Stromversorgung und zur Übertragung der seriellen Schnittstelle. Oft kommt man nur als Administrator (root) auf diese Schnittstelle. Deswegen erst noch dem gewöhnlichen Anwender ($USER) den Zugriff erlauben mit

    sudo usermod -a -G dialout $USER

    Danach ausloggen/einloggen oder komplett das Linux neu starten. Das Kommando pio run -t upload sollte automatisch das richtige serielle Gerät finden.

  • Wenn man pio nicht mehr braucht deaktiviert man die virtuelle Umgebung mit

    deactivate

3.8.2 ttn-lw-cli

Es gibt das Kommandozeilenprogramm ttn-lw-cli, das alle Funkionen der TTN Konsole auch über die Kommandozeile erledigen kann. Es ist Teil des The Things Stack und somit auch Open-Source Software.

https://www.thethingsindustries.com/docs/the-things-stack/interact/cli

Reference: https://www.thethingsindustries.com/docs/reference/cli

Download: https://github.com/TheThingsNetwork/lorawan-stack/releases

Anmelden

Version abfragen

ttn-lw-cli version

The Things Network Command-line Interface: ttn-lw-cli
Version:             3.25.1
Build date:          2023-04-18T08:13:17Z
Git commit:          bcfbbc610
Go version:          go1.20.3
OS/Arch:             linux/amd64
ttn-lw-cli use eu1.cloud.thethings.network

Lokal wird eine Datei .ttn-lw-cli.yml angelegt.

ttn-lw-cli login

Nun öffnet sich der Browser und zeigt den Auth-Code an. Diesen Code mit Copy/Paste in das Kommandozeilenfenster übertragen.

Danach sollte jedes Kommando funktionieren, z.B.:

ttn-lw-cli applications list
ttn-lw-cli end-devices list heltec-v3-demo-1
ttn-lw-cli gateways list

Zum Schluss

ttn-lw-cli logout

Downlink

https://www.thethingsindustries.com/docs/hardware/devices/configuring-devices/downlink-queue-ops

Downlink an Heltec Board schicken (1 Byte Nutzdaten)

Rote LED an

ttn-lw-cli end-devices downlink push heltec-v3-demo-1 eui-70b3d57ed005c674 --frm-payload 01 --priority NORMAL --f-port 1

Rote LED aus

ttn-lw-cli end-devices downlink push heltec-v3-demo-1 eui-70b3d57ed005c674 --frm-payload 00 --priority NORMAL --f-port 1

DevNonce zurücksetzen

Bei LoRaWAN Geräten mit OTAA Anmeldung läuft auf dem Device und auf dem TTN Stack ein Zähler hoch, der bei jeder Übertragung inkrementiert wird. Ein Problem entsteht, wenn das Device ausgeschaltet wird und der Zähler wieder von Null an loszählt. Dann verweigert der TTN Stack die Abnahme der Datenpakete.

Das kann man beheben wenn man in der Konsole beim end device auf Settings geht. Dort geht man ganz nach unten zu den Join Settings. Hier findet man dann den Knopf Reset used DevNonces, auf den man drückt. Danach sollte der TTN Stack die Daten des Gerätes wieder abnehmen.

Diesen Job kann man auch über das CLI Tool erledigen:

ttn-lw-cli end-devices reset heltec-v3-demo-1 eui-70b3d57ed005c674  --resets-join-nonces

3.8.3 base64tool.py

Siehe Ordner base64.

python base64tool.py -B 01 3A
ATo=

python base64tool.py -b ATo=
0x01  0x3a

python base64tool.py -B 00
AA==

3.8.4 MQTT

sudo apt install mosquitto
sudo apt install mosquitto-clients
pip install paho-mqtt

Im Abschnitt Container ist eine Anleitung wie man Mosquitto als Container starten kann.

MQTTK

sudo apt install python3-tk
pip install mqttk

3.8.5 Webhooks

# led-on.sh
curl --location \
     --header 'Authorization: Bearer '$WORKSHOP_API_KEY \
     --header 'Content-Type: application/json' \
     --header 'User-Agent: my-integration/my-integration-version' \
     --request POST \
     --data '{"downlinks":[{ "frm_payload": "AQ==", "f_port": 10, "priority":"NORMAL" }] }' \
     https://eu1.cloud.thethings.network/api/v3/as/applications/${appid}/webhooks/${webhookid}/devices/${devid}/down/replace
# led-off.sh
curl --location \
     --header 'Authorization: Bearer '$WORKSHOP_API_KEY \
     --header 'Content-Type: application/json' \
     --header 'User-Agent: my-integration/my-integration-version' \
     --request POST \
     --data '{"downlinks":[{ "frm_payload": "AA==", "f_port": 10, "priority":"NORMAL" }] }' \
     https://eu1.cloud.thethings.network/api/v3/as/applications/${appid}/webhooks/${webhookid}/devices/${devid}/down/replace

Wer mit einem eigenen Webhook Daemon experimentieren möchte dem empfehle ich den webhookd, siehe Zuhörthemen und Container.

3.8.6 Node-RED