Eine Bodenfeuchtemessung im Garten ist hilfreich, wenn man Pflanzen oder Rasen rechtzeitig und ausreichend bewässern möchte. Wenn man einen größeren Garten oder z.B. einen Schrebergarten hat, ist oft kein WLAN an allen Stellen verfügbar. Als Alternative bietet sich dann das Versenden der Sensordaten über LoRaWAN an. Die Vorteile habe ich bereits in meinem Beitrag LoRaWAN mit eigenem Gateway einrichten genannt.

ELV hat hierzu ein interessantes Produkt für einen überschaubaren Preis im Programm. Dazu braucht man das  LoRaWAN-Interfaces ELV-LW-INT1 und den  universellen Bodenfeuchtesensor SoMo1, I²C. Beide zusammen sind bei ELV für ca. 75 Euro zu erhalten.

Ich mit diesen Komponenten in einem größeren Garten die Bodenfeuchte und -temperatur gleichzeitig messen und halbstündlich an einen MQTT-Server übertragen. Ich habe dazu in der Nähe ein LoRaWAN-Gateway im TTN-Netz verfügbar.

Vor der Inbetriebnahme muss das System konfiguriert werden. Da die Konfiguration viele Möglichkeiten anbietet und für den Laien nicht trivial erscheint beschreibe ich, wie man den Sensor für diesen Zweck in Betrieb nehmen kann.

Installation der Hardware

Auch wenn die Platine als „Bausatz“ angeboten wird, sind keine Bestückungs- oder Lötarbeiten erforderlich. Das Interface besitzt neben 2 Mignon-Batterieslots vom Typ LR6 (AA) auch 2 Sensoranschlüsse mit UART- oder I²C-Schnittstelle. Obwohl insgesamt nur eine Spannungsversorgung über die Batterien (Akkus) von 3V zur Verfügung steht, können trotzdem 3,3 bzw. 5V an die Sensoren ausgegeben werden (über Transistoren). Dies ist wichtig, da die meisten Sensoren die etwas höhere Spannung für eine korrekte Messung benötigen. Die Platine besitzt keine externe Spannungsversorgung und kann daher nur durch Bestückung mit den 2 Mignonzellen in Betrieb genommen werden. Zur Befestigung liegen noch 2 Schrauben und eine Stiftleiste bei, über die ein Firmware-Update über einen USB-UART-Konverter UM2102N durchgeführt werden kann. Die richtige Firmware ist bereits installiert.

Der Feuchte- und Temperatursensor ist ebenfalls sofort einsatzbereit, kann Bodenfeuchte und -temperatur messen, besitzt einen AD/DA-Wandler und ist wasserdicht vergossen. Nach dem Einbau in eine Dose kann das Kabel des Sensors über die gekennzeichneten 4 Drähte an die Schnittstelle wie folgt angeschlossen werden:

• (braun) an +UB2
  
• (schwarz) an GND
• (blau) an SDA
• (weiß) an SCL

Weitere Detailinformationen finden sich z.B. in folgendem ELV-Journalartikel.

Wer kein LoRaWAN-Gateway in der nähe hat findet im Artikel LoRaWAN mit eigenem Gateway einrichten weitere Hinweise zum TTN-Netzwerk oder der Gateway-Einrichtung.

Ich empfehle, die Batterien erst wie im nächsten Kapitel beschrieben einzulegen.

Device und Applikation in TTN Netzwerk ergänzen

Nach dem Einloggen in das TTN-Netzwerk geht man auf den Reiter „Applications“. Als erstes erstelle ich eine Application und gebe hier einen aussagekräftigen Namen „Loris-Bodenfeuchte1“ ein.

Anschließend erstelle ich ein neues Device, indem ich auf „New Device“ klicke.

Bei „End device type“ kann man das Device direkt im Repository suchen (Option 1). Dazu wählt man ELV aus und findet dann schon das LoRaWAN Interface 1. Als Frequency Plan wird SF9 gewählt und nach Eingabe der JoinEUI (liegt dem Interface als kleiner Aufkleber bei) kann man auf Confirm tippen. Danach werden noch die DevEUI und der AppKey ergänzt. Die End-Device ID wird automatisch generiert und man kann nun „Register end device“ drücken. (Update Juli 2025: Die End-Device ID wird mittlerweile nicht mehr automatisch generiert. Hier kann man beispielsweise auch die DevEUI in der Notation "eui...." eintragen). 

Nach dem Einlegen der Batterien oder Akkus blinkt das Board kurz rot/gelb und wechselt dann auf grün.

Jetzt kann man unter „Live data“ beobachten, wie das Gerät Kontakt zum Netzwerk aufnimmt und Nutzdaten sendet. Zum Dekodieren der Daten benötigt man einen Payload Parser (ein kleiner Codeblock, der die vom Gerät empfangenen hexadezimalen Bytewerte übersetzt). Wenn man das Gerät wie beschrieben aus dem Repository ausgewählt hat, wird der Payload-Parser automatisch mitgeliefert. Dieser befindet sich unter dem Device im Reiter "Payload Formatter" "Uplink". Hier sollte "Use device Repository formatters" stehen. Den Code von eQ3  kann man sehen (und editieren), wenn man die Device aufruft und im Menü (OBEN!) den Reiter "Payload-formatters" aufruft.

Alternativ kann man diesen Code auch auf der ELV-Seite unter Downloads unter dem Link „ELV-LW-INT1 Payload-Parser“ herunterladen.

Sensor konfigurieren

Wer die Installation bis hierhin erfolgreich durchgeführt hat, wird feststellen, dass nur Statusdaten der Schnittstelle gesendet werden, aber keine Sensorwerte für Bodenfeuchte und Temperatur. Dies liegt daran, dass die Messung und Übertragung der Werte von den Sensoren erst aktiviert werden muss. Das Interface hingegen ist so vorkonfiguriert, dass es alle 30 Minuten eine Statusmeldung sendet.

Grundlagen zur Sensorkonfiguration

Die Befehle und Grundlagen für die Konfiguration der Sensoren und des Interfaces findet man in folgenden Dokumenten:

• Excel-Tabelle auf zum Interface mit allen Details zu Befehlen, Parametern, etc.
• Bau- und Bedienungsanleitung des Interfaces
• ELV-Journal 2/2024 unter Bausätze

Grundsätzlich tauscht man Informationen mit dem Interface und den Sensoren über eine Payload (eine Bytefolge von hexadezimalen Werten) aus. Befehle werden als Payload über einen Downlink-Kanal an ein Gerät gesendet, Daten werden über einen Uplink-Kanal empfangen. Kommandos werden als "frame-type" bezeichnet. In einem "frame-type" werden Daten wie z.B. Kanal und Parameter übertragen.

Für die zu übertragenden Codes (Bytes) müssen Werte berechnet werden, wobei teilweise zwischen dezimalen, hexadezimalen und binären Zahlenformaten gewechselt wird. ELV empfiehlt hierfür den folgenden einfachen Konverter.

In den folgenden Kapiteln werden einzelne Werte auch durch das Setzen von Bits ermittelt. Dabei gilt, dass die Bits in einem Byte von 0 bis 7 gezählt werden und rechts begonnen wird!

Sensoren über Kanäle ansprechen

Um die Sensoren und das Interface eindeutig anzusprechen benötigt man die Angabe einer Kanalnummer. Das Interface besitzt eine eigene Kanalnummer und neben dem gemeinsam verbauten Bodenfeuchte- und Temperatursensor wird auch ein Ultraschall-Disstanzsensor DUS1 unterstützt.

Folgende Kanalnummern stehen zur Verfügung:

Anzeige von Statusdaten

Theoretisch kann jeder Sensor eigene Statusdaten senden. Standardmäßig sendet das Interface jede halbe Stunde eine Statusnachricht und zusätzlich kann ich mir die Statusinformation des Feuchtesensors und des Temperatursensors jeweils in einem eigenen Zeitintervall senden lassen. Ich möchte aber insbesondere die Feuchte- und Temperaturinformationen immer zusammen erhalten und am liebsten noch zusammen mit den Statusinformationen des Interfaces (also insgesamt nur eine Nachricht mit allen Informationen jede halbe Stunde).

Dies kann ich erreichen, indem ich Statusgruppen verwende, in denen ich die Statusinformationen zusammenfasse und diese zusammengefassten Statusinformationen dann in eine Statusmeldung einfüge. In meinem Fall werden die Statusinformationen des Feuchtesensors und des Temperatursensors der Statusgruppe 1 zugeordnet. Ich werde für diese Sensoren nicht separat das Übermitteln von Statusinformationen aktivieren sondern werden das Interface so konfigurieren, dass es bei seiner halbstündlichen Statusinformation einfach die Gruppe 1 inkludieren soll. Damit wird die Statusmeldung auch die Informationen der Sensoren beinhalten.

Befehl zur Konfiguration der Sensoren

Zur Konfiguration verwende ich den "set single parameters" Befehl, dem ich beliebig viele Parameter übergeben kann. Mit diesem Befehl werden alle Parameteränderungen beginnen.

Feuchtesensor konfigurieren

Hierfür gelten folgende Punkte:

• Messungen müssen aktiviert werden, sonst kann der Feuchtesensor keine Daten senden.
• Man kann gleichzeitig auch das Messen der Temperatur aktivieren, so dass beide Werte synchron ermittelt werden!
• Der Bodenfeuchtesensor liefert immer sogenannte Rohwerte im Bereich von 3000 bis 4000 zurück. Diese kann man selber in Prozentwerte umrechnen oder vom Sensor direkt umrechnen lassen. Dazu ist das Ablesen der Sensorwerte im trockenen Zustand sowie in nassem Zustand erforderlich. Die beiden Rohwerte werden dann dem Sensor als Untegrenze für 0% und Obergrenze für 100% mitgeteilt.

Mit folgender Bytefolge konfiguriere ich den Feuchtesensor:

Temperaturmessung konfigurieren

Hierfür gelten folgende Punkte:

• Die Temperaturmessung wurde bereits über die Bodenfeuchtemessung aktiviert, so dass die Messzyklen für die Feuchtemessung automatisch gelten. Weitere Einstellungen zur Messwerterfassung sind bei diesem Ansatz nicht erforderlich.

Mit folgender Bytefolge konfiguriere ich den Temperatursensor:

Interface konfigurieren

Hierfür gelten die folgenden Punkte:

• Standardmäßig sendet das Interface alle 30 Minuten eine Statusmeldung, so dass dies nicht gesondert eingestellt werden muss.
• Zusätzlich zu den eigenen Statusinformation sollen die Statusinformation des Feuchte- und Temperatursensors übermittelt werden.

Mit folgender Bytefolge konfiguriere ich das Interface:

Konfigurationsänderung an das Gerät schicken

Dazu geht man im TTN-Webinterface unter "End devices" auf das SoMo1-INT1 Gert, wählt den Reiter "Messaging" und dort den Reiter "Downlink". Als "FPort" muss nun "10" eingestellt werden. Danach kann man die in den vorherigen Kapiteln erstellten drei Bytefolgen (Payload) jeweils in das Payload-Feld eintragen (bitte  ohne das führende 0x) und anschließend den Button "Schedule downlink" drücken. Das Kommando wird beim nächsten Verbindungsaufbau zum Gerät gesendet (durch kurzes Drücken des Buttons an der Schnittstelle kann die Zeit verkürzt werden).

Unter "Live data" kann man nun die Übertragung der Befehle beobachten. Wenn dort die "decode downlink data message" Meldung „No decoder defined for codec elv-lw-int1-codec“ erscheint, kann man diese ignorieren. Es gibt aktuell keinen Payload-Decoder, der in der Lage ist, die gesendete Bytefolge wieder in Klartext umzuwandeln.

Es kann einige Zeit dauern, bis die Einstellungen vorgenommen sind, da normalerweise die eingestellten Sendeintervalle abgewartet werden müssen (in diesem Beispiel bis zu 1 Stunde).

Um die Daten an einen MQTT-Server zu schicken verweise ich auf die Erläuterungen in folgendem Beitrag Füllstandsmessung mit LoRaWAN.

Wenn dann eine Statusinformation gesendet wird, sollte das Ergebnis wie folgt aussehen:

Die Daten können dann z.B. in Node-Red weiterverarbeitet und zur Steuerung von Bewässerungssensoren verwendet werden.

HINWEIS: Die Bodentemperatur wird als Zeichenkette (String) geliefert und nicht wie der Feuchtewert als Zahl (float-Typ). Vor der Speicherung in einer Datenbank sollte der Wert daher vorher umgewandelt werden, damit man ihn grafisch darstellen kann.

Optionale weitere Befehle

In der folgenden Tabelle sind einige weitere Befehle zur Konfiguration der Sensoren aufgelistet:

Einbrüche und Diebstahl in und aus Gartenhäusern und Wohnmobilen sind ein großes Ärgernis. Die Überwachung mit Bewegungsmeldern wird dann problematisch, wenn eine Übertragungsstandard wie z.B. WLAN aufgrund der Entfernung nicht verfügbar ist. Daher stelle ich auf der Basis von LoRaWAN eine einfache Lösung vor, die kaum Strom braucht und geografisch sehr flexibel ist. Grundinformationen zu LoRaWAN habe ich bereits im Artikel LoRaWAN mit eigenem Gateway einrichten veröffentlicht.

Hardware

Um einen Bewegungsmelder mit LoRaWAN zu realisieren habe ich das von ELV angebotene  ELV-Modulsystem für LoRaWAN verwendet (Loris). Mit diesem System kann man sehr flexibel Komponenten für einen Sensor oder Aktor, der über LoRaWAN kommunizieren soll, zusammenstecken. Dies funktioniert i.d.R. sogar, ohne irgendeinen Lötkolben in die Hand nehmen zu müssen.

Als Basis ist immer eine LoRIS-Base ELV-BM-TRX1 erforderlich, über die die Kommunikation per LoRaWAN erfolgt. Die LoRIS-Base besitzt einen USB-C Anschluss zur Verbindung mit einem PC oder einer externen Spannungsversorgung.

Zusätzlich benötigt man das ELV-PIR1 Modul welches aus einem Bewegungsmelder und eine Helligkeitssensor besteht. Ebenso besitzt das Modul einen Opencollector-Ausgang, über den man mittels eines Relais auch andere Geräte schalten könnte. Ich benutze das in meinem Beispiel allerdings nicht.

Zur Stromversorgung verwende ich zusätzlich noch das ELV Powermodul LR03, in das man eine AAA-Micro Zelle einlegen kann. Bekanntermaßen braucht LoRaWAN zur Kommunikation unglaublich wenig Strom, so dass mit einer Batterie das Gerät bis zu mehrere Jahre laufen kann. Alternativ sind auch andere Module für die Stromversorgung mit mehr Kapazität verfügbar (inkl. Solarmodul, etc.).

Als Gehäuse kann man das ELV-MH0101a verwenden. In meiner Umsetzung habe ich ein eigenes Gehäuse entworfen und mit dem 3D-Drucker passgenau gedruckt.

Softwareinstallation

Die LoRIS-Base wird immer mit einer Standardfirmware ausgeliefert, die die Funktionen des Moduls wie z.B. einfache Schalter unterstützt. Um den Bewegungsmelder zu unterstützen, muss eine andere Firmware aufgespielt werden.

Auf der Produktseite des PIR1-Moduls im ELV-Shop befindet sich die Firmware, die man sich von dort runterlädt. Die Firmwaredatei hat eine .hex-Endung und befindet sich in einem ZIP-Archiv.

https://de.elv.com/elv-pir1-applikationsmodul-pir-bewegungsmelder-elv-am-pir1-158570?fs=185688875

Das Flashen erfolgt über das ELV-Base Flasher Tool. Dieses befindet sich in einem ZIP-Archiv im Downloadbereich der LoRIS-Base unter

https://de.elv.com/elv-lw-base-experimentierplattform-fuer-lorawan-elv-bm-trx1-156514

Vor der Benutzung empfehle ich, die PDF-Anleitung in diesem ZIP-Archiv zu lesen.

Die Installation des Flasher Tools erfolgt als Administrator. Anschließend wird das Tool aufgerufen.

Das eigentlichen Flashen mit dem Tool ist hervorragend in der beiliegenden PDF-Anleitung beschrieben. Als Firmwaredatei wird die soeben für das ELV-PIR1 heruntergeladene .hex-Datei angewählt.

Nachdem mit dem grünen Haken der erfolgreiche Flashvorgang bestätigt wurde kann das Tool beendet werden.

Hardware zusammenstecken.

Nun kann man die Module zusammenstecken.

Unten befindet sich die Loris-Base, darauf wird das Powermodul mit der Batterie gesteckt und oben wird das PIR-Modul aufgesteckt. Alles zusammen schiebe ich anschließend in ein Gehäuse. Hat man das ELV-Gehäuse gekauft, dann muss mit einem Stufenbohrer eine ca. 13mm große Öffnung gebohrt werden, so dass der obere Teil des Sensors aus dem Gehäuse herausragt. Ich habe mit das Gehäuse allerdings passend mit einer Öffnung sowie einer Öse (zum Befestigen mit einer Schraube) passend gedruckt.

Payload decodieren

Der Sensor wird nun als neue Applikation im TTN-Netz eingerichtet. Ich verweise hierzu auf meine Artikel Füllstandsmessung mit LoRaWAN, in dem die Einrichtung erklärt wird.

Anschließend kann man den Payload Parser von der ELV-Seite Seite des PIR Moduls im Downloadbereich kopiereren und im Application Modul unter „Payload Formatters/Uplink“ eingefügen.

Die Daten werden dann korrekt interpretiert. Diese kann man sich über den Menüpunkt Livedata anschauen. Damit man diese versteht gebe ich folgende Hinweise:

Die Payload unterscheidet grundsätzlich zwei Zustände, die in der TX_Reason ausgegeben werden. In Abhängigkeit davon werden auch unterschiedliche Bytezahlen zurückgegeben.

D.h. wenn der Input Event als Active ausgegeben wird, wurde eine Bewegung erkannt und man kann reagiren.

Konfigurationswerte ändern

Der Sensor hat eine Vielzahl von Konfigurationswerten, die in der Anleitung zum Sensor beschrieben sind. Hierzu wird ein Bytefolge aus insgesamt 8 Bytes gebildet, die immer komplett an das Gerät geschickt werden müssen.

Da ich möglichst viel Strom sparen möchte, schalte ich den Lichtsensor aus und lasse mir maximal einmal pro Stunde eine Nachricht schicken (wenn keine Bewegung erkannt wurde). Hierzu verwende ich folgende Bytefolge:

Hieraus ergibt sich die Bytefolge

0C 3C 19 22 10 02 85 85

Wer alles wieder zurücksetzen möchte kann die folgende Bytefolge verwenden:

0C 05 19 22 18 02 85 85

Die Bytefolge gibt man in "Applications /End Device / Messaging / Downlink" ein. Im Feld FPort wird Kanal 10 als Kommunikationskanal eingetragen und in "Payload" die Bytefolge.

Zur Bestätigung kann noch das Confirm-Häkchen gesetzt werden.

WICHTIG: Damit die Befehle vom TRX1 empfangen werden muss auf der Platine (am Rand) unbedingt der "User-Button" kurz gedrückt werden. Erst dann wird die Konfiguration durchgeführt.

Abfragen der Daten in Node-Red

Auch hierzu verweise ich  auf meine Anleitung Füllstandsmessung mit LoRaWAN insbesondere die Kapitel "Daten an MQTT-Server senden" sowie "Daten mit NodeRed verarbeiten". Zu diesem Zweck wird unter "Integrations/MQTT" für die Application ein neuer Nutzer angelegt sowie ein neuer API-Key vergeben. Dies sind die Accountdaten, um nachher in Node-Red die Werte abzufragen.

Mit dem MQTT-Explorer kann man diese Daten vorab auch auf dem MQTT-Server von TTN selber kontrollieren.

ACHTUNG: Wenn man in Node-Red bereits einen LoRaWAN-Sensor eingerichtet hat, dann muss man für diesen Sensor wieder eine neuen Server im MQTT-In Node einrichten, da man ja neue Accountdaten für diesen Sensor angelegt hat.

Unter Node-Red werden die Daten dann über folgende Funktion vom MQTT-Server ausgelesen und weiterverarbeitet.

Die Daten kann man nun für Alarmmeldungen z.B. über Nachrichtendienste verwerten.

Im Artikel Füllstandssensor (Zisterne) für HMIP selber bauen habe ich beschrieben, wie ich mit einem D1 Mini und einem SR04T Distanzsensor eine Füllstandsmessung für eine Zisterne realisiert habe.  Nach  fast einem Jahr stelle ich fest, dass die Lösung für meine Zwecke zu unzuverlässig ist. Hierzu gehört insbesondere, dass eine WLAN-Verbindung im Außenbereich teils nicht funktioniert. Darüber hinaus verträgt auch der Sensor SR04-T die feuchte Luft in der Zisterne nicht gut, obwohl er hierfür gemacht wurde. Ebenso habe ich immer wieder Messunschärfen, da sich im Messbereich des Sensors auch der Zulauf befindet und dieser Abstand manchmal dominiert. Mein Ziel war es, einen Sensor zu finden, der präziser ist, langlebiger und vor allen Dingen ohne WLAN auskommt. Bei der Übertragungstechnik LoRaWAN bin ich fündig geworden.

LoRaWAN Entfernungssensor

Da man mit LoRaWAN auch extrem weite Strecken überbrücken kann war klar, dass es ein LoRaWa Sensor sein soll. Auf dem Markt gibt es für die Messung von Abständen zu Oberflächen ein erstaunlich großes Angebot in diesem Segment, allerdings teilweise auch mit astronomischen Preisen. Ich bin aber fündig geworden und haben den Dragino LDDS 75 entdeckt, den man z.B. bei Reichelt beziehen kann. Wenn man den Sensor kauft sollte dieser für die europäischen 863 -867 MHz Netze ausgelegt sein.

Der Sensor hat mich aus folgenden Gründen überzeugt:

• Er ist IP66 geschützt, d.h. ein starker Wasserstrahl sollte nicht zum Eindringen von Wasser führen (in einer Zisterne ist es maximal Spritzwasser)
• Er hat eine Akku-Laufzeit von bis zu 10 Jahren
• Er ist relativ klein
• Er fokussiert die Messung auf einen kleinen Bereich
• Er kann Distanzen bis zu 4 Metern erkennen
• Er ist nicht teuer (<80 Euro)

Beim Öffnen des Hauptgehäuses ist mir ebenfalls noch aufgefallen, dass der Akku ausgetauscht werden kann. Dies ist ein Vorteil, denn manche LoRaWAN Sensoren werden mit einem vergossenen Gehäuse angeboten, so dass das ganze Gerät beim Ausfall des Akkus getauscht werden muss.

Interessant bleibt die Frage, ob der Sensor in einer geschlossenen Tonne funktioniert, denn hier bildet sich insbesondere im Frühjahr und Herbst Kondenswasser, welches insbesondere Ultraschallsensoren beeinflussen kann. Aber das werde ich jetzt ausprobieren.

Einrichtung des Sensor

Um den Sensor in Betrieb zu nehmen, muss er erst geöffnet werden. Dazu schraubt man die vier Gehäuseschrauben los und öffnet das Gehäuse. Im Gehäuse wird anschließend der gelbe Jumper umgesteckt (siehe Anleitung) und der Sensor meldet sich mit blauem Blinken.

Die Einrichtung eines LoRaWAN Gateways und eines Account im LoRaWAN-Netzwerk habe ich bereits im Artikel LoRaWAN mit eigenem Gateway einrichten beschrieben und beziehe mich in der folgenden Beschreibung darauf.

In der TTN/TTS Oberfläche wird für den Füllstandssensor zuerst eine neue Application erzeugt. Dazu geht man auf den Reiter "Applications" und erstellt über den Button "Create Application" eine neue Applikation mit einer aussagekräftigen Application-ID.

Nachdem man die neue Application erzeugt hat, schaut man in das Menü "End devices" (auf der linken Bildschirmseite) und wählt in diesem den Button "Register End device". Da der Dragino Sensor bereits im Repository steht, kann man zur Einrichtung die Option "Select the device in the LoRaWAN Device Repository" stehen lassen. Alternativ kann man die Einrichtung auch manuell vornehmen (zweite Option)

Folgende Parameter sollten gewählt werden (wenn sie nicht schon automatisch vorgegeben sind):

V1.1.4 (nur notwendig, wenn explizit danach gefragt wird)

Die Anlage einer Device ist unter folgendem Link gut erklärt. Die Firmware Versionen können bei Bedarf von Dropbox heruntergeladen werden.

Nach der Anlage der Device sollte der Server versuchen, eine Verbindung aufzubauen. Dies kann man entweder im Fenster "Device overviwe" oder unter "Live data" beobachten. Wenn ein Connect erfolgreich verläuft, dann sollten hier mindestens folgende Zeilen auftauchen:

Wenn hier irgendetwas nicht funktioniert, dann ist fast immer igrendein Parameter bei der Device Anlage falsch angegeben worden.

Uplink Payload formatieren

Der Hex-Code, der vom Sensor zurückgeliefert wird ist erst einmal nicht lesbar und muss daher aufbereitet werden. Aus diesem Grund wird zu jeder Application (und der dazugehörigen Device) ein Payload Formatter angelegt, der definiert, wie der Hex-Code aufbereitet werden soll. Zusätzlich wird über die Application definiert, an wen die decodierten Nachrichten weiterversendet werden sollen.  Die Payload-Information des sogenannten Uplink-Kanals besteht insgesamt aus 8 Bytes, die sich wie folgt unterscheiden

Für den Payload Decoder zum LDDS75 und andere Sensoren verweist Dragino auf das folgende Verzeichnis

ACHTUNG: Der Code von Dragino ist fehlerhaft, denn dieser geht davon aus, dass nur 6 anstelle von 8 Bytes vom Sensor zurückgeliefert werden. Der korrigierte Code lautet:

Der Code wird nun unter Application / Payload /Formatters / Uplink in das Feld "Formatter Code" kopiert und gespeichert. Als Formatter Type sollte "Custom Javascript formatter" ausgewählt sein.

Nun sollten die Nachrichten dekodiert werden (das kann auch erst beim nächsten Sensorwertempfang sein) und wie folgt erscheinen:

Intervall bis zur Datensendung (Uplink) verändern

Lt. Dragino wird der Sensor alle 20 Minuten aktiv und sendet seine Werte an das TTN Netzwerk. Ich möchte diese Zeitspanne gerne verlängern, denn für mich reicht eine Messung jede Stunde aus. Darüber hinaus sparen längere Messintervalle Batterie, so dass die Laufzeit des Akkus hierdurch verlängert wird.

Dragino verweist auf zwei Möglichkeiten diesen Wert zu verändern

• Mittels AT-Befehlen (das schließe ich aus, denn dazu muss ich mir einen TTL-USB Adapter beschaffen)
• Mittels Downlink Befehl (dies wäre meine präferierte Lösung)

Hierzu verweist Dragino auf folgende FAQ  aus der sich die folgenden Punkte ergeben:

• Zur Steuerung von Devices werden über TTN HEX-Codes verwendet.
• Der Befehl besteht aus 4 Bytes
• Das erste Byte gibt die Funktion zum Ändern der Uplink Intervals an und ist "01"
• Die nächsten 3 Bytes beinhalten die Zeitdauer in Sekunden (im Hex Format) also z.B. für 60 Minuten (3600 Sekunden) "00 0E 10"

Zur Einstellung wähle ich in TTN meine Device aus (Füllstandssensor), gehe dort auf den Reiter "Messaging" und wähle den Reiter "Downlink" aus. Hier füge ich nur den Payload "01 00 0E 10" ein und aktiviere die Checkbox "Confirmed downlink".

Nun wird der Befehl in die Warteschlange aufgenommen und beim nächsten Connect (Uplink-Intervall) an den Füllstandssensor übermittelt.

Der Befehl erst dann ausgeführt, wenn das Device die nächste Uplink-Message schickt.

Sensor montieren

Ich habe den Sensor an einen Winkelverbinder montiert, welchen ich in der Regentonne befestigt habe. Da der Sensor mit zwei Überwurfmuttern zum Festschrauben geliefert wird habe ich einen passenden Halter entworfen und mit einem 3D-Drucker ausgedruckt, so dass ich an diesem den Sensor festschrauben kann. Den Sender mit der Antenne habe ich abschließend mit Kabelbindern an dem Winkelverbinder befestigt.

Daten an MQTT-Server senden

Um die Daten weiterverarbeiten zu können, schicke ich diese an einen MQTT-Server. Hierzu verwende ich den MQTT-Server, der von The Things Stack angeboten wird.

Dazu lege man unter Applications /Integrations / MQTT einfach einen neuen API-Key an, der für eine sichere Authentifizierung der Verbindung sorgt (hat man früher schon einen API-Key angelegt, kann man diesen natürlich auch verwenden). Die Servervorgaben für den MQTT-TTN-Server können übernommen werden, der Username wird ebenfalls vom System vorgegeben und besteht aus @.

Ab sofort sendet der Sensor die Daten über den Application Server an den MQTT-Server.

Daten mit NodeRed verarbeiten

Nun müssen die Daten von dem TTN MQTT Server abgeholt werden. Hierzu verweise ich auf die wirklich gute Anleitung von The Things Stack zu Node-Red, die man unter folgendem Link findet.

Ich frage in Node-Red alle Daten vom MQTT-Server ab und löse dann den payload mit einer Funktion für den Abstand (ich rechne das direkt auf Zentimeter um) sowie einer Funktion für die Batteriespannung auf und schreibe diese Daten dann direkt in eine InfluxDB.

Wie das funktioniert steht in meinen Beiträgen Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 1/2) und  Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 2/2)

Bisher habe ich Sensoren im Außenbereich immer per WLAN angebunden. Dies betraf insbesondere die Tasmota basierten Systeme, die von mir i.d.R. mit einem D1 Mini ausgestattet wurden. Der große Nachteil dieser Übertragungstechnik ist, dass ich zum einen überall Repeater aufstellen muss. Zum anderen ist der Strombedarf zur Verbindungsherstellung und Übertragung von Daten mittels WLAN relativ hoch, so dass akkubetrienbene Systeme schnell leer werden.

Wer darüber hinaus einen Schrebergarten oder andere auf dem Grundstück entfernte Gartenhäuser, Wohnmobile o.ä. überwachen möchte, kommt mit WLAN nicht weiter. Nach einiger Recherche habe ich als Alternative die LoRaWAN Technik entdeckt und schildere gerne anhand von Beispielen, wie man diese einfach nutzen kann.

Ein paar Details zu LoRaWAN

LoRaWAN bedeutet Long Range Wide Area Network. Es ist ein Netzwerkprotokoll und basiert auf der Spezifikation der physikalische LoRa-Schicht, die durch eine sternförmige WAN-Topologie aufgespannt wird. Dabei spielt das Thema Low Power WAN (LPWAN) eine große Rolle, da das ganze Netwerk für die Nutzung von batteriebetriebenen IOT-Devices  und Vermittlung vom kleinen Datenpaketen auch über größere Entfernungen entworfen wurde.  Dazu wird in verschiedenen Frequenzbändern auf der Welt gesendet, in Europa ist dies in der Regeln der Bereich zwischen 863Mhz und 870 Mhz.

Die LoRa-Technik wurde von der Firma Semtech erfunden. Die Firma baut i.d.R. die Chips für das Funkprotokoll. In 2015 wurde die LoRa-Allianz gegründet, zu der das Who is Who der Techbranche zählt (z.B. IBM, Cisco, Mikrochip, etc.). Da diese Technik im industriellen und kommerziellen Umfeld schon seit Jahren genutzt wird, ist das Angebot an IOT-Devices sehr groß. Wer damit anfängt wird plötzlich an allen möglichen Gewässern oder in Industrieanlagen diese autonomen Sensoren (Devices) entdecken.

The Things Network (TTN) bildet das globale Netzwerk (weltweit), welches die Software für das Netzwerk zur Verfügung stellt und die Kommunikation der Gateways und Devices sicherstellet. Damit ist es theoretisch möglich, einen Sensor, der sich in Südamerika befindet hier zu überwachen und Aktionen zu initiieren.

Mittlerweile basiert die Netzsoftware auf der Community Edition von The Things Stack (TTS) und nutzt die sogenannten V3-Server.  The Things Stack stellt die zentralen Server und die Serversoftware für die LoRaWAN Nutzung heute zur Verfügung. Dazu gehören neben der Community Edition weitere Editions z.B. für die Cloud und für Firmen, inbesondere wenn man eine große Zahl von Devices nutzen möchte. The Things Stack wird von dern Firma The Things Industries betrieben und weiterentwickelt und richtet sich mit seinen Angeboten eher an einen kommerziellen Nutzerkreis. Die Firma sitzt in Amsteradm in den Niederlanden.

Früher gab es The Things Stack noch nicht und daher stellte TTN auch die Server bereit (V2-Server).  Mit Übernahme der Server durch TTS werden seit einiger Zeit die alten Server des TTN sukzessive auf die neuen Server migriert.

Weitegehende Infos findet man z.B. unter

https://www.thethingsnetwork.org/docs/

https://www.mokolora.com/de/full-understanding-of-lora-and-lorawan/

Verfügbare Gateways prüfen

Um mit LoRaWAN zu starten, empfehle ich zuerst zu prüfen, ob ein Gateway in der Nähe verfügbar ist, mit dem sich ein Sensor (Device) verbinden kann. Dies macht man am einfachsten über den TTN-Mapper. Dies ist eine Webseite, die anzeigt, wo Gateways verfügbar sind. Hierzu ruft man einfach die Seite des TTN-Mappers https://ttnmapper.org/heatmap/ auf.  Hier kann man nun auf den geografischen Bereich in seiner Gegend zoomen und sieht, welche Gateways dort vorhanden sind (Gateway-Symbole). Ich empfehle die Auswahl der TTS-Geräte beizubehalten, da diese dem aktuellen Standard entsprechen.

Die bunten Kreise geben die Devices und deren Empfangstärke an, die mit einem Gateway verbunden sind oder verbunden waren. Je geringer der dbm-Wert ist, umso besser ist die Verbindung zwischen Device und Gateway (blaue Kreise), je schlechter die Signalstärke ist, umso roter werden die Kreise.

Nun kann man sich ein Gateway aussuchen, darauf klicken und die Heatmap nur für dieses Gateway aufrufen. Anhand der nun angezeigten farbigen Kreise kann man abschäzen, ob eine (gute) Verbindung zu einem bestehenden Gateway bestehen könnte.

Mikrotik wAP LR8 Gateway installieren

Da ich in erreichbarer Nähe (ca. 10 km) keine gut erreichbaren Gateways vorfand, habe ich mich entschlossen, ein eigenes Gateway zu beschaffen und einzurichten. Darüber hinaus kann ich mit einem eigenen Gateway viel besser diagnostizieren, wie die Kommunikation zwischen Device (Sensor) und Gateway verläuft, wenn es mal Probleme geben würde.

Nach einiger Recherche habe ich mich für das wAP LR8 kit der Firma Mikrotik entschieden. Die Kosten liegen aktuell zwischen 180 Euro und 220 Euro, das Gerät war innerhalb von 2 Tagen bei der Firma Reichelt verfügbar. Folgende Kriterien haben mich überzeugt

• PoE-Anschluss
• Erweiterbar auf externe Antenne
• Vorkonfiguriert für die TTN/TTS Nutzung
• IP54 Schutz, d.h. auch für draußen geeignet
• 8-Kanal Gateway (und damit deutlich zuverlässiger bei OTAA-Authentifizierung als Dual oder Single Channel Gateways)

Beim Kauf ist darauf zu achten, dass es für den Frequenzbereich in Europa von 863-870 MHz geeignet ist, da das Gerät für vielen Regionen verfügbar ist.

Interne Antenne anschließen

Wer eine externe Antenne mitbestellt hat, kann diese direkt anschließen. Wer die interne Antenne nutzen möchte muss diese erst durch eine kleine Hardwaremodifkation aktivieren.

Dazu öffnet man das Gehäuse und  sieht anschließend folgenden Aufbau für den Anschluss einer externen Antenne:

Nun löst man die (rot markierte) Steckverbindung des externen Antennenanschlusses und steckt den freiliegenden internen Antennenanschluss auf den freigewordenen kleinen "Knopf". Der Stecker sollte leicht spürbar einrasten. Fertig.

Software konfigurieren

Jetzt kann das Gerät entweder mit dem mitgelieferten Poweradapter und dem LAN-Kabel oder über PoE angeschlossen werden. Im ersten Schritt muss man das Gerät über WLAN konfigurieren und dort den LAN Adapter freischalten, anschließend kann man über LAN weitermachen.

Nach dem Einschalten spannt das Gateway ein eigenes WLAN auf, mit dem man sich verbindet. Über die Adresse http://192.168.88.1 kommt man nun auf das Webinterface. Die Abfrage nach Username und Passwort kann man einfach wegklicken, später empfehle ich, hier einen Account zum Einloggen anzulegen.

Unter dem Menü (linke Seite) "IP" und danach dem Submenü "Firewall" wird nun ein neuer Eintrag angelegt ("Add New").

Folgende Parameter für den Eintrag werden nun geändert:

Nun "Apply" drücken und die Regel erscheint unten in der Liste der Ausnahmen für die Firewall. Damit die Regel für den Webzugriff auf die Oberfläche über Ethernet sofort greift, muss man den letzten Eintrag per gedrückter Maustaste greifen und ganz nach oben ziehen. Alternativ kann man die ganze Firewall deaktivieren, was ich allerdings nicht empfehle.

Jetzt ist der Webzugriff über Ethernet aktiviert. Die IP-Adresse holt sich das Gateway nun über DHCP vom Netzwerkrouter, d.h. man kann dort nachschauen, wie die Adresse lautet und über diese IP-Adresse mit dem port 80 die Weboberfläche aufrufen.

Abschließend sollte man das WLAN des Gateways deaktivieren. Dies geht sehr einfach, indem man im Menü "Interfaces" einfach auf das kleine "D" vor dem WLAN eintrag klickt, so dass ein kleines "E" erscheint. Jetzt ist das WLAN deaktiviert.

Account bei TTN/TTS anlegen

Für alle folgenden Aktivitäten ist die Voraussetzung, dass man eine "The Things ID" (Account) erstellt hat. Dies kann man  über die TTS-Webseite machen. Ich empfehle aber zur Umgehung des ganzen Billing Gedönses den Weg über die folgende  TTN-Seite. Hier legt man nun für die Community-Edition von TTS eine entsprechende ID durch Angabe weniger Parameter an. Wer den Unterschied zwischen den verschiedenen Editions von TTS erfahren möchte, schaut sich auf der folgenden Seite von The Things Stack mal um. Die freie Version wird hier als Discorvery bezeichnet.

Gateway im LoRaWAN registrieren

Man loggt sich als erstes bei TTN oder TTS mit dem bereits erstellten Account ein. Sofern nicht direkt die Menüs für Gateways und Devices angezeigt werden kann man oben rechts unter dem Accountnamen auf den Menüpunkt "Console" klicken, so dass anschließend die Konfigurationsmöglichkeiten für die eigenen Geräte erscheinen.

Hier wählt man am aus dem oberen Menü den Punkt "Gateways" und anschließend "Register gateway" aus.

Nun müssen folgende Parameter angegeben werden:

Nun kann auf den Button "Register Gateway" geklickt werden. Anschließend wird das Gateway in TTN registriert und es erscheint eine Übersichtsseite mit den eben eingegebenen Parametern.

Die Vorgehensweisen sind gut erläutert auch unter folgendem Link zu finden https://www.thethingsindustries.com/docs/devices/adding-devices/

Gateway mit dem Server des TTN-Netzes verbinden

Allerdings wird unter dem Namen des Gateways noch ein roter Punkt zu sehen sein, neben dem Disconnected steht. Denn dem Gateway muss noch mitgeteilt werden, mit welchem Server es sich verbinden soll. Dazu kopiert man einfach die neben dem Bezeichner "Gateway Server adress" angezeigte Serveradresse, i.d.R. "eu1.cloud.thethings.network".

Nun wechselt man zurück in die Mikrotik Console in den Menüpunkt "LoRa". Hier gibt es den Reiter "Server". Sofern hier noch nicht der soeben kopierte Server verfügbar ist, legt man einen neuen Server mit der kopierten Adresse und den Ports 1700/1700 an und speichert diesen unter einem aussagekräftigen Namen ab.

Jetzt geht man auf den Reiter "Device" und klickt dort auf den bereits verfügbaren Gateway-Eintrag für das Mikrotik Gerät. Neben "Network Server" wählt man den Servereintrag aus, der auf den eben gemerkten oder angelegten TTN/TTS Server zeigt und drückt Apply oder OK (Enabled muss aktiviert sein).

Wechselt man nun wieder in die TTN/TTS Console sollte man nach einiger Zeit sehen, dass der Status des Gateways von disconnected auf Connected wechselt und in der LIve data Console sollte die Kommunikation zwischen TTN und dem Gateway sichtbar werden.

Ausblick

Im nächsten Beitrag zeige ich, wie man einen Füllstandssensor in das Netzwerk aufnimmt und die Daten protokolliert.