Mir fiel die Tage auf, dass es wenige verstaendliche Anleitungen fuer LoRaWAN-Spielereien auf Deutsch gibt – was schade ist, weil a) die Technik zu Spielereien geradezu einlaedt und b) wir in Ulm ein recht enges Netz an Gateways haben.
Deswegen hier die kurze Dokumentation, wie wir ueber LoRaWAN Lichter an- und ausgeschaltet haben. Der verwendete Code ist vollstaendig auf github und ist zu ueberwiegenden Teilen von @Nitek geschrieben worden.
Teil 1: Der Empfaenger
Das wirkt jetzt etwas unintuitiv, aber weil das der einfachere und guenstigere Part ist, fangen wir mal mit dem Empfaenger an 😉
Verwendete Teile waren:
- NodeMCU (oder WeMos D1 oder sonst irgendetwas ESP8266-basiertes)
- WS2801-basierte RBG-LED-Lichterkette
- Jumperkabel zum Verbinden der letzteren beiden Teile
Der Code basiert zu groessten Teilen auf dem Basic MQTT ESP8266 Example, und arg viel mehr ist es auch nicht. Der WiFiManager erspart uns, die WLAN-Credentials hart einzuprogrammieren, und am Ende geht es nur mehr darum, den passenden TTN-MQTT-Server einzutragen:
- MQTT_USERNAME: Der Name der Application in der TTN-Console
- MQTT_SERVER: Der URI des Handlers – laesst sich ueber die Application Settings in der TTN-Console ueber Settings → General → Handler herausfinden (z.B. eu.thethings.network)
- MQTT_PASSWORT: Ein Access Key, am besten einer, der nur die Messages lesen und ansonsten nichts einstellen/konfigurieren kann. Den Key kannst du ueber „Settings/Access Keys“ in der TTN-Console anlegen, anschliessend taucht er im Console-Overviews auf und kann durch Klick auf das Augen-Symbol angezeigt werden (siehe Abbildungen unten, z.B. „
ttn-account-v2.2[…]
“)
Im Sketch selber (ja, da gehoert’s eigentlich nicht hin) sind noch PLACEID
und MQTT_DEVICE
zu definieren. PLACEID
legt fest, auf welche Integer in der MQTT-Payload die Node reagiert. Steht hier z.b. ‚1‘ und in der Payload wird die 1 mitgeschickt, schaltet die Node ihr Licht ein. MQTT_DEVICE
muss fuer jede Node eindeutig anders sein – d.h. selbst wenn mehrere Nodes auf dieselbe Payload reagieren sollen, brauchen sie unterschiedliche Device-Namen. Sonst kegeln sie sich bei der Registrierung im Endlosloop gegenseitig aus dem MQTT-Server.
Alles andere im Code ist lediglich Standard-Registrierung am Server und eine etwas laengliche Definition der LED-Lichterkette, die sich einschalten und beim Abschalten kurz rot leuchten soll. Das war’s auch schon.
Teil 2: Der Sender
Der Sender ist etwas komplizierter – erstens, weil ja ein „User Interface“ (sorry :D) dazugehoert, und weil das LoRa-Shield angesteuert werden muss. Notwendige Teile sind:
- Stinknormaler Arduino Uno (oder Klon)
- Dragino LoRa Shield (868 MHz) mit Rubberduck-Antenne
- TM1638 LED and Key Module (unter dem Namen leicht in den einschlaegigen Shops zu finden)
- DuPont-Verbindungskabel fuer Key/LED-Modul und Arduino
Der Arduino-Sketch ist auch relativ schnell gegessen: NWKSKEY[16]
und APPSKEY[16]
sind jeweils der Network Session Key und der App Session Key aus der TTN Console (ueber die Application → Devices → Dein registriertes Device). Wenn in der TTN Console DEADBEEF…
steht, wird das im Sketch als { 0xDE, 0xAD, 0xBE, 0xEF, …}
gespeichert. DEVADDR
ist analog die Device Address aus der TTN Console.
Abhaengig vom abgefangenen Knopf auf der UI-Platine wird der Payload nun ein Integer uebergeben – und das wird in doSend()
abgeschickt. Mehr gehoert nicht dazu 🙂
Und wozu das Ganze?
Das eigentliche Ziel war, an einem Aussichtspunkt ueber der Stadt ein Knopfbrettl mit spannenden Landmarken in der Stadt anzubringen, das mit LoRaWAN in die Stadt funkt. Und wer dort beispielsweise auf „Schwoerhaus“ drueckt, laesst eine auf den Punkt gerichtete Lampe blinken 😀
So weit sind wir noch nicht, aber Ende Mai war die Wirtschaftsministerin in Ulm an der TFU, und wir haben die Technik (mit den Lichterketten und den nodeMCUs) quasi gehighjackt, um die Ministerin reihum ihre Gespraechspartner*innen zu „erleuchten“. Hat geklappt 😉