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:
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)
[…] 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 […]
Vielen Dank für die tolle Beschreibung. Ich habe einen ähnlichen Anwendungsfall und bin zunächst auch über den ESP (mit Ultraschall) auf Deine LoRaWan Lösung gestoßen.
Nun läuft das bei mir seit 2 Wochen recht stabil, obwohl ich gespannt bin wie lange der Sensor bei gefühlt 200% Luftfeuchtigkeit überleben wird.
Obwohl bei mir Gateways in der Nähe sein sollten, musste ich mir letztlich doch ein Lokales zulegen. Habe da die preisgünstigere Lösung mit dem Indoor Gateway gewählt. Zumal das mit ~3 W Stromverbrauch erträglich bleibt.
Die Daten schreibe ich per MQTT und NodeRed in den IOBroker zurück. Von dort wirds weiter mit Influx/Grafana /VIS visualisiert. Ein EMail alerting soll noch folgen, weil mir nach einem Pumpenausfall kürzlich der Wasserpegel zu hoch geworden ist.
Das war übrigens der eigentliche Auslöser für meine Suche nach einer smarten „Homeitems“ Lösung ;-).
Viele Grüße
Das Ganze läuft jetzt bei mir seit mehr als 6 Monaten ohne Probleme, trotz des umfangreichen Kondenswassers. Es bietet sich tatsächlich an, diese Lösung auch zur Überwachung eines Pumpensumpfs oder von Drainageschächten zu verwenden.
Gruß
Dieter
Eine kurze Ergänzung: ich habe gestern noch einen Temperatursensor in den LDDS75 geschraubt und war beruhigt, daß innen kein Kondenswasser sichtbar war. Bei der Wassermenge von außen hatte ich doch ein paar Befürchtungen.
Jedenfalls liefert der Sensor jetzt auch die Temperatur unter der Erde:
„decoded_payload“: {
„Bat“: 3.275,
„Distance“: „1168 mm“,
„Interrupt_flag“: 0,
„Sensor_flag“: 1,
„TempC_DS18B20“: „10.40“
Grüße
Welchen Temperaturfühler hast Du dafür verwendet?
Einen DS18B20 mit Metallghäuse und Kabel. Hatte ich noch übrig von einer alten Bestellung:
https://www.amazon.de/dp/B01MZG48OE/ref=twister_B07ZQNTTX4?_encoding=UTF8&th=1
Mit Heißkleber senkrecht in einer Ecke fixiert und dann nur rot, gelb, schwarz an der Steckerleiste anschrauben wie im Handbuch beschrieben:
https://cdn-reichelt.de/documents/datenblatt/E910/DRA_LDDS75-8_MAN-EN.pdf:
2.3.4 DS18B20 Temperature sensor
This is optional, user can connect external DS18B20 sensor to the +3.3v, 1-wire and GND pin .
and this field will report temperature.
Konfigurieren mußte man nichts. Der Temperaturwert wurde sofort mit übertragen.
Und Standby Strom verbraucht der auch nicht. Nur, wenn er abgefragt wird.
Grüße
[…] Um die Daten an einen MQTT-Server zu schicken verweise ich auf die Erläuterungen in folgendem Beitrag Füllstandsmessung mit LoRaWAN. […]