Füllstandsmessung mit LoRaWAN

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):

Parameter Wert
Frequency Plan Europe 863-870 MHz (SF12 for RX2)
LoRaWAN Version LoRaWAN Sepcification 1.0.3
Regional Parameter Version RP001 Regional Parameter 1.0.3. revision A (wird in der Regel durch LoWaWAN Version schon gesetzt)
Join EUI (DEV EUI) Die auf dem Gerät oder Karton aufgedruckte Nummer
APP EUI Die auf dem Gerät oder Karton aufgedruckte Nummer
APP KEY Die auf dem Gerät oder Karton aufgedruckte Nummer
Firmware Version 
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

BYTES INHALT
1 & 2 
Batterie Ladestand in mV
3 & 4 Distanz in mm
5 Digital Interrupt (kann optional angeben, warum ein Interrupt ausgelöst wurde)
6 & 7 Temperatur (nur verfügbar, falls optionaler Temperatursensor vorhanden ist)
8 Sensor Flag (gibt an, ob Sensor gefunden oder nicht gefunden wurde (z.B. wenn Sensor zu nahe an der Seitenwand angebracht wurde und keine Messung stattfinden konnte)

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:

Copy to Clipboard

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 {application id}@{tenant id}.

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)