Nicht erst seit Corona ist die Messung des CO2-Gehaltes in der Raumluft eine Möglichkeit festzustellen, ob genügend Frischluft (oder Sauerstoff) in einem Raum vorhanden ist. Ich war teilweise überrascht, wie teuer manche Sensorlösungen verkauft werden und habe mich daher entschlossen, einen eigenen Sensor zu bauen, der sich auch einfach in mein Smarthome integrieren lässt. Mit einer kleinen LED möchte ich anzeigen, ob ein vorgegebener Grenzwert überschritten wird. Die Daten des Sensors sollen zyklisch an mein Smarthome-System gesendet werden.

Benötigte Hardware

Als Sensor habe ich mich für einen CO2-Infrarotsensor MH-Z 19C entschieden. Der Sensor sendet seine Informationen über eine UART-Schnittstelle (Tx,Rx-Kanal), besitzt zusätzlich einen Temperatursensor und benötigt eine Versorgungsspannung von 5V. Mit diesen Anschlussmöglichkeiten eignet er sich hervorragend für den Anschluss an einen Wemos D1-Mini (8266 Chip), den ich schon in vielen meiner Projekte verwendet habe. Über diese kann ich dann auch alle Daten an einen MQTT-Broker senden und so die Daten einfach in meinem Smarthome-System weiterverarbeiten. Den Sensor gibt es in verschiedenen Ausführungen, wobei ich mich für die Version mit den Stiftleisten entschieden habe, um den Anschluss zu vereinfachen. 

Auf dem D1 Mini verwende ich die Tasmota Version 14.3.0. Um den CO2-Infrarotsensor MH-Z 19C an den D1 Mini anschließen und auslesen zu können, benötige ich die Tasmota Sensor Version (alternativ kann man den MH-Z19C auch einfach in der Standardversion aktivieren und spart dadurch viel Speicherplatz auf dem D1 Mini).

Ich erstelle meine Programme gerne mit der Skriptsprache von Tasmota. Da es diese Funktion in den vorkompilierten Versionen von Tasmota nicht gibt, kompiliere ich mir selbst eine Version und flashe den D1-Mini damit. Dies geht sehr einfach und ist im folgenden Artikel von mir beschrieben:Tasmota Scripting aktivieren

Ich empfehle, in der Konfiguration des D1-Mini neben dem WLAN auch direkt einen MQTT-Server anzugeben.

CO2-Sensor anschließen

Der Anschluss des CO2-Sensors ist recht einfach. Als Ergänzung habe ich noch eine rote LED hinzugefügt, die bei Überschreitung eines definierten Grenzwertes aufleuchten soll. Die gesamte Schaltung ist in der folgenden Abbildung dargestellt:

Nun muss der Sensor in Tasmota konfiguriert werden. Dies geschieht über die serielle Schnittstelle mit TX (Sendekanal) und RX (Empfangskanal).

Unter Configure / Configuration Module wähle ich als Module Type "Generic(18)" (steht meistens ganz unten in der Liste) und speichere das. Erst dann kann ich alle meine GPIOs sehen und konfigurieren.

• GPIO1 (TX) wird auf "MHZ Tx (60)" (Sendekanal) gesetzt.
• GPIO3 (RX) wird auf "MHZ Rx (61)" (Empfangskanal) gesetzt.

(Tipp: In der langen Liste stehen die beiden Werte im unteren Dritttel).

Um die LED einschalten zu können, wird noch ein Relay benötigt, dass wie folgt definiert werden muss:

• GPIO5 (D1) wird auf "Relay 1" gesetzt.

Nach dem Speichern und dem automatischen Neustart sollten Temperatur und CO2 Gehalt wie folgt auf der Tasmota Oberfläche erscheinen:

Hinweis: Aufgrund der Vorheizzeit kann es bis zu einer Minute dauern, bevor der Sensor Werte liefert!

Script für LED-Warnung erstellen

Natürlich möchte ich, dass eine rote Lampe aufleuchtet, wenn ein Grenzwert überschritten wird. Bezüglich möglicher Grenzwerte verweise ich auf den folgenden Artikel. Dazu muss ich den Sensorwert auslesen und in einem kleinen Programm das Relais immer dann einschalten, wenn der Grenzwert überschritten wird. Bei dieser Abfrage prüfe ich, ob die LED schon an ist, damit ich nicht ständig den Einschaltbefehl sende. Natürlich schalte ich die LED wieder aus, wenn der Grenzwert unterschritten wird.

Die Daten können nun vom MQTT-Broker "abgeholt"  und beispielsweise in InfluxDB gespeichert und ausgewertet werden. Wie das geht habe ich in folgenden Artikeln beschrieben

Möglicher Anpassungen

Ich versorge den Sensor über ein USB-Kabel mit Strom. Theoretisch könnte man dies auch mit einer Akkulösung realisieren. Dazu wird dann der Deepsleep-Modus verwendet (siehe hierzu Füllstandssensor (Zisterne) für HMIP selber bauen). Wichtig ist, dass der Sensor eine Vorlaufzeit zur Temperaturanpassung benötigt. Daher sollte der Sensor frühestens nach 1 Minute wieder in den DeepSleep-Modus gehen.

Anstelle einer LED könnte man auch eine mehrfarbige LED verwenden, die den jeweiligen Zustand anzeigt.

Inzwischen habe ich den Sensor auf eine Platine gelötet und mir mit dem Drucker ein passendes Gehäuse gedruckt.

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:

Mit dem kleinen Shelly Plus PM Mini wird eine günstige Möglichkeit geboten, eine Leistungsmessung durchzuführen. Das Gerät ist nur ca. 28 x 32 x 16 mm (HxBxT) groß und passt in viele UP-Dosen z.B. hinter einer Steckdose. Das Gerät unterstützt dabei eine Messung bis zu 16A Leistung (ist leider nicht bei allen Shelly Geräten so), so dass man mit dem Gerät theoretisch die Leistung eines Balkonkraftwerks, von Lichtschaltern oder Steckdosen messen kann.

Im folgenden Beitrag beschreibe ich, wie man das PM Mini auch ohne Shelly-App über WLAN und MQTT einbinden und die Daten in Node-Red weiterverarbeiten kann.

Grundsätzlich erfolgt hier der Hinweise, dass das Arbeiten an Elektroleitungen immer nur von Fachleuten (Elektrikern) durchgeführt werden und immer die fünf Sicherheitsregeln der Elektrotechnik berücksichtigt werden sollten.

Gerät ins Netzwerk einbinden

Ich möchte auf die Shelly Cloud sowie das Einrichten der Shelly App verzichten, sondern nur eine lokale Nutzung mittels WLAN umsetzen. Nach der Stomversorgung spannt das PM Mini ein eigenes Netz auf (Access Point), mit dem man sich verbinden muss. Das WLAN erkennt man an dem Namen, der mit "ShellyPMMini..." beginnt. Um anschließend in den Shelly-WebAdmin-Oberfläche zu kommen, gibt man im Browser die Adresse "192.168.33.1" ein und schon sollte die administrative Weboberfläche  erscheinen. Bitte berücksichtigt, dass auch die Shelly-Geräte nur das 2,4 GHz WLAN unterstützen. Die Optionen und Anzeigen  in der WebAdmin-Oberfläche sind unter diesem Link super erklärt.

Nun geht man auf "Configure Wifi-Setting", wählt "Enable Wifi-network" und gibt die SSID (Name des WLANs) sowie das Passwort für das WLAN an und speichert die Einstellungen. Theoretisch kann man das Gerät nun neu starten und es sollte dann unter einer eigenen IP-Adresse in der Netzwerkliste des Routers erscheinen.

Generelle Einstellungen

Da es bei älteren Shelly-Firmwareversionen zu Problemen mit der korrekten Leistungsmessung kam, sollte unbedingt die aktuelle Firmware für das PM Mini aufgespielt werden.  Dazu geht man auf "Settings" und "Firmware". Shelly prüft nun automatisch, ob eine neue Version verfügbar ist und bietet an, diese online zu installieren.

Nach dem Drücken von "Update" wird die Firmware aufgespielt und das Gerät neu gestartet. Nun sollten folgende Einstellungen vorgenommen werden:

MQTT-Settings

Für das erfolgreiche Senden von Nachrichten an einen MQTT-Broker müssen folgende Einstellungen vorgenommen werden:

Nach dem Speichern der Settings ist das Gerät vollständig konfiguriert und kann über "Settings" "Reboot-Device" neu gestartet werden. Anschließend kann man z.B. mit dem MQTT-Explorer prüfen, welche Informationen an den MQTT-Broker gesendet werden.

Tipp: Bei mir wurden zuerst keine Nachrichten gesendet. Erst als ich in den MQTT-Settings den Punkt „Generic Status update over MQTT“  enabled und dann wieder disabled habe, hat es funktioniert.

Daten in Node-Red weiterverarbeiten

Die Daten können jetzt in Node-Red weiterverarbeitet werden. In meinem Fall speichere ich diese direkt in einer InfluxDB ab.

Im mqtt-in-Node frage ich erst einmal das Topic vom MQTT-Server ab. Dieses findet man unter dem Namen, den man dem Shelly-Gerät  gegeben hat (siehe oben), gefolgt von einem "/pm1:0", also in meinem Fall heißt das Topic "EM-Licht/pm1:0". Als Ausgabe wird "Ein analysiertes (parsed) JSON-Objekt." gewählt.

Im Function-Node wird nun die Leistung aus dem JSON-Objekt extrahiert:

Der Code dazu lautet:

Das bedeutet, dass sich unter "aenergy.total" der benötigte Wert im payload-Objekt befindet.

Zuletzt speichere ich diesen Wert noch mit einem influxdb-out-Node in die Datenbank. Mit dieser Vorgehensweise kann man auch andere Shelly-Geräte ohne Shelly-App abfragen und deren Daten weiterverarbeiten.

Wie man Node-Red, MQTT und InfluxDB installiert und Daten austauscht steht unter anderem 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)

Neulich bin ich wieder auf die die Ulanzi TC001 Pixelclock gestoßen und beschreibe im folgenden Beitrag, wie sich mit dem Display eigene Werte über Node-Red von beliebigen Smart Home Systemen darstellen lassen.

Ich habe die Pixelclock direkt bei Ulanzi bestellt. Innerhalb kurzer Zeit wurde sie geliefert. Sie besitzt ein Matrixdisplay aus 256 LEDs und versprüht damit einen gewissen Retro Charme. Sie ist mit einem Akku ausgestattet und über einen USB-C Anschluss kann man das Gerät aufladen oder auch mit einem Netzteil betreiben. Ich verwende dazu ein Netzteil, welches ich normalerweise für einen Raspberry PI benutze (5V, 1A).

Auf der Oberseite befinden sich neben einem Lichtsensor drei Tasten, die zur Bedienung der internen Einstellungen dienen. Die Pixelclock zeigt bereits fünf eigene Apps an, zu denen ein Kalender oder die Akkuanzeige gehören.

Neue Firmware aufspielen

Um eigene Werte auf der Pixelclock anzeigen zu können, muss eine andere Firmware aufgespielt werden. Diese wird der blueforcer AWTRIX LIGHT Gruppe gepflegt und über diese Webseite mit einem Online-Flasher bereitgstellt. Nach dem Anschluss des Gerätes über das mitgelieferte USB-C-Kabel kann das Gerät über die Webseite geflasht werden.  Während dieses Vorgangs piept das Gerät kontinuierlich.

ACHTUNG: Der Online Flasher funktioniert lt. Hersteller nur mit Google Chrome und Microsoft Edge. Bei mir hat nur Google Chrome unter OSX funktioniert.

Nach erfolgreicher Installation meldet sich die Pixelclock mit einer bunten Anzeige, auf der "AWTRIX sowie die Versionsnummer der Firmware und "AP MODE" angezeigt werden. Dies bedeutet, dass die Pixelclock noch keine Verbindung ins WLAN hat. Da sie in diesem Modus ein eigene WLAN aufspannt kann man sich mit einem beliebigen Gerät mit diesem WLAN verbinden (Name i.d.R. "awtrix....").

Nach Eingabe der SSID und der Passwortes startet das System neu und sollte nun nach dem Versionsschriftzug eine IP-Adresse anzeigen. Unter dieser IP-Adresse ist das AWTRIX-Webinterface ab sofort erreichbar.

TIPP: Wer später eine aktuellere Firmware aufspielen möchte kann diese unter folgendem Link herunterladen und auf dem Webinterface der Pixelclock über den Menüpunkt "Update" installieren.

AWTRIX konfigurieren

Zur Anzeige eigener Werte ist ein MQTT-Broker erforderlich. In meinem Beitrag MQTT-Broker Mosquitto als Docker Image auf einem NAS installieren ist beschrieben, wie man diesen installieren kann.

Ich empfehle, folgende Einstellungen vorzunehmen:

• Unter "MQTT" die IP-Adresse des MQTT-Brokers (der Port kann i.d.R. auf 1883 bleiben, wenn man den nicht geändert hat)
• Unter "Prefix" den Namen, unter dem Daten für das Gerät zu finden sein sollen. In meinem Beispiel verwende ich "awtrix_test"
• (optional) Unter "Auth" einen Usernamen und ein Passwort für den Zugriff auf das Webinterface.

Nach Änderungen ist es sinnvoll, diese zu sichern.  Das kann man über den Menüpunkt "Backup" erledigen und kann somit später Konfigurationen einfach wiederherstellen.

Auf dem Gerät sollte man darüber hinaus alle Applikationen deaktivieren, die man nicht braucht. Bei mir ist nur der Kalender übrig geblieben. Dazu drückt man etwas länger die mittlere Taste und wählt über die links- oder rechts-Taste das Menü "APPS"  aus. Ein erneutes Drücken der mittleren Taste bietet anschließend die Möglichkeit, mit den Pfeiltasten die vorinstallierten Apps anzuwählen. Diese können über die mittlere Taste auf "ON" oder "OFF" gestellt werden.  Das jeweilige Untermenü verlässt man über das längere Drücken der mittleren Taste.

HINWEIS: Man kann auf dem Gerät nur die vorinstallierten Apps aktivieren oder deaktivieren. Eigene Apps werden hier nicht angezeigt, sondern werden nur über die MQTT-Nachrichten gesteuert. 

Icons installieren

Eigene Daten kann man mit vorangestellten Icons anzeigen lassen. Hierzu gibt es bereits eine riesige Auswahl auf der Seite Lametric. Wunderschön sind insbesondere die animierten Icons z.B. für Stromverbrauch oder Stromerzeugung. Wer hier nichts findet, kann sogar selber eigene Icons erstellen. Ich wähle für mein Beispiel das Icon mit der Nummer 21256 aus.

Nach dem Wechsel in das AWRTIX-Webinterface kann man unter dem Menüpunkt "Icons" durch die Angabe der Icon-Nummer von der Lametric-Seite ein oder mehrere Icons auf die Pixelclock laden.

Eigene Werte anzeigen lassen

Ich möchte auf der Pixelclock den aktuellen Stromverbrauch meines Smartmeters anzeigen lassen. Wie man diesen ausliest, habe ich in dem Beitrag SmartMeter mit Tasmota auslesen beschrieben.

In Node-Red baue ich dazu einen Flow, der aus folgenden Komponenten besteht:

Von einer CCU hole ich mir die Variable, in der der aktuelle Stromverbrauch gespeichert ist (das könnte natürlich auch der Wert von einem MQTT-Broker sein). Diesem Wert übermittle ich an einen Change-Node, in der die Nachricht zusammengestellt wird, die an einen MQTT-out-Node weitergegeben wird. Die Nachricht wird als json-String in einer Payload zusammengesetzt und besteht aus folgenden Bestandteilen:

In Node-Red sieht der Change-Node wie folgt aus:

TIPP: Es gibt eine große Zahl von Konfigurationsmöglichkeiten für eine Anzeige. Diese sind in der sehr guten Dokumentation unter folgendem Link zu finden.

Diese Informationen leite ich anschließend an den MQTT-out-Node weiter. Hier ist darauf zu achten, dass das Topic richtig eingetragen wird. Dieses besteht aus dem in AWTRIX festgelegten Topic (hier "awtrix_test"), gefolgt von dem Text "/custom" sowie einer eigenen Applikationsbezeichnung. In meinem Beispiel lautet das topic "awtrix_test/custom/stromverbrauch". Der letzte Name kann frei gewählt werden ist aber wichtig, damit man die verschiedenen Werte, die man an die Uhr übermittelt, eindeutig unterscheiden kann.

Sobald man den Flow in Node-Red deployed hat, sollte nach kurzer Zeit auf der Pixelclock der definierte Wert angezeigt und ständig aktualisiert werden. Es kann am Anfang ein paar Sekunden dauern, bis die Nachrichten vom Broker empfangen wurden.

Senken des Stromverbrauchs

Bei Messungen habe ich festgestellt, dass die Pixelclock bis zu 8 Watt im Betrieb braucht. Das erschien mir ziemlich viel, so dass ich zwei Maßnahmen empfehle, wie der Verbrauch gesenkt werden kann.

Zuerst sollte die Helligkeit des Displays heruntergestellt werden. Dazu wählt man im Menü der Pixelclock (langes Drücken auf die mittlere Taste) den Menüpunkt "BRIGHTNESS". Nach Drücken der mittleren Taste kann man hier einen eigenen Wert einstellen. Bei mir sind aktuell 10% eingestellt, was auch bei Tageslicht vollkommen ausreicht. Dadurch sank mein Stromverbrauch bereits auf weniger als 5 Watt.

Zusätzlich stelle ich ich die Anzeige z.B. nachts aus. Hierzu wird der Pixelclock einfach ein Befehl geschickt, der diese für eine bestimmte Zeit schlafen legt (Deep Sleep Modus des ESP).

Dazu wird in einem Change-Node die Eigenschaft "sleep" auf die Sekundenzahl gesetzt, die das Gerät im Schlafmodus verbringen soll. In meinem Beispiel sind das 12 Stunden oder 43.200 Sekunden:

Diese Information wird anschließend als Push-Nachricht über einen mqtt-out-Node an den MQTT-Server gesendet, wobei das Topic wie folgt lautet "awtrix_test/sleep".

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.

Ergänzung vom Juni 2026 zur Akkulaufzeit:

Etwas mehr als 3 Jahre nach der Installation ist die Batterie ausgefallen bzw. war leer. Da diese nicht wiederaufladbar ist muss sie ersetzt werden, was auch einfach geht. Auch den Batterietyp erhält man ohne große Suche von verschiedenen Händlern. Ob die (kurze) Lebensdauer der Batterie an meinen vielen Tests liegt oder an den klimatischen Bedingungen (der Akku ist halt auch bei Minustemperaturen und bei großer Hitze draußen) bleibt dabei offen.

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)

Da mir mein Raspi neulich den Dienst verweigert hat und daher eine Reihe von Daten nciht mehr erfasst wurden, habe ich einen alternativen "Betreiber" für dem MQTT-Broker Mosquitto gesucht. Dabei bin ich wieder bei Docker gelandet, welcher aals Service auf meinem Synology NAS läuft. Im Folgenden beschreibe ich kurz, welche Einstellungen ich vorgenommen habe, damit Mosquitto fehlerfrei läuft.

Installation

Als Paket wird "eclipse-mosquitto" in der "Latest-Version" heruntergeladen.

Unter dem Verzeichnis Docker wird dann das Verzeichnis "mosquitto" sowie darunter die folgenden Unterverzeichnisse angelegt:

• config
• data
• log

im Verzeichnis config wird nun eine Datei "mosquitto.conf" erstellt, die folgenden Inhalt hat:

Entweder man lädt die erstellte Datei einfach in das Verzeichnis hoch oder nutzt den Texteditor vom Synology DSM, um diese zu erstellen. Insbesondere die vierte Zeile ist wichtig, da sich sonst niemand beim Broker anmelden kann.

Die Pfade für das Docker Image werden dann wie folgt gesetzt:

Nun müssen für den Container nur noch folgende Daten angegeben werden:

• Beliebiger Name für den Container
• Netzwerk: bridge
• Automatischen Neustart aktivieren
• Lokaler Port 1883 und Container Port 1883, TCP
• Lokaler Port 9001 und Container Port 9001, TCP

In den Umgebungsvariabeln setze ich immer zusätzlich die Timezone, da die automatische Übernahme vom Synology DSM schon mal nicht funktioniert hat:

• TZ  Europe/Berlin

Das wars. Nach dem Starten sollte der Broker laufen und ansprechbar sein. Ich überprüfe das beispielsweise mit dem MQTT-Explorer.

Für die Kommunikation von IoT insbesondere auch von SmartHome Sensoren und Aktoren hat sich MQTT (Message Queuing Telemetry Transport) als Standardprotokoll etabliert. Dazu werden Informationen über einen Gerätestatus an einen MQTT Broker gesendet, der diese Daten an sogenannte Abonnenten verteilt. Hierzu werden unter einem Thema (Topic) Statusinformationen an den MQTT Broker geschickt, der diese Themen, den Abonnenten zum Abruf zur Verfügung stellt. Informationen zu den Grundlagen und der Funktionsweise sind massig im Netz zu finden. Für mich stellte sich die Frage, wie ich komplexere MQTT Nachrichten in Openhab3 in Items umwandeln kann.

Anforderung

Ich erfasse die Werte eines Smartmeters mittels eine Infrarotsensors und übermittele diese mit einem WEMOS D1 mini an einen MQTT Broker. Als MQTT Broker ist bei mir eine MOSQUITO Server installiert, den es für jede Plattform kostenfrei gibt. Die Daten möchte ich aber über Openhab3 weiter verarbeiten und insbesondere anschließend in einer Datenbank InfluxDB protokollieren und mit Grafana auswerten.

Mein Sensor schickt folgende Daten an den MQTT-Broker:

tele/Keller_SmartMeter/SENSOR =

Ich möchte aus diesen nun über Openhab3 den Sensorwert Total_in verwenden.

MQTT Binding und MQTT Broker Thing installieren

Als erstes muss das MQTT Binding in Openhab 3 installiert werden.

Geht man in Openhab3 unter Administration / Einstellungen in den Bindings Bereich und das "MQTT Binding aus". Nach dem Klick auf Install wird das Binding installiert. Nun muss als erstes ein Thing für den MQTT Broker erstellt werden,m damit man diesen ansprechen kann.

Dazu erzeugt man unter dem Menü Things manuell ein neues Thing mit dem Binding  "MQTT Binding" und wählt anschließend den Typ "MQTT Broker". Nach und freien Vergabe der "Unique Id", des "Labels" und der "Broker Hostename/IP"  sollte dieses Thing angelegt und sofort als "Online" dargestellt werden. Mein Thing hat den Namen "MQTT Broker" erhalten.

Eine detaillierte Erläuterung des Installationsvorgangs ist auch auf folgender Seite zu finden.

Ich habe nun die Grundlagen für die Kommunikation mit dem Broker geschaffen.

Thing anlegen

Ich muss als nächstes in Openhab ein Thing anlegen, dass meinem Sensor am SmartMeter entspricht. Ebenso erzeuge ich die Kanäle, d.h. die Verbindungen zu den späteren Items, die die Werte des Gerätes zur Verfügung stellen. Über die Items kann ich später auf diese Kanäle zugreifen,.  Das Prinzip der Things, Channels und Items ist ausführlich auf dern Openhab3 Seite erläutert.

Um ein Thing für meinen SmartMeter anzulegen erzeuge ich wiederum ein manuelles Thing für das "MQTT Binding" mit dem Typ "Generic MQTT Thing". Als "Unique ID" und "Label" vergebe ich den Namen "Energiezaehler", als Parent Bridge wähle ich meinen im vorigen Schritt angelegten "MQTT Broker" aus.

Kanäle anlegen und Items verbinden

Bevor ich die Kanäle anlege ist noch eine wichtige Sache zu erledigen. Zuerst benötige ich das Topic, unter dem meine Werte gesendet werden. Da ich per Tasmota die Werte von meinem Sensor übermittele sehe ich genau in der TASMOTA Konsole, wie mein Topic lautet:

tele/Keller_SmartMeter/SENSOR

Wer dies nicht weiß, dem empfehle ich das Programm MQTT Explorer, mit dem man alle Informationen, die ein MQTT-Broker bereitstellt oder empfängt ausführlich transparent machen kann.

Unter dem Topicnamen wird folgende Nachricht bereitgestellt:

Diese Nachricht, ist ein String, in dem sich verschiedene Sensorwerte befinden, die ich benötige. Um diese zu extrahieren gibt es die Java Bibliothek JSONPath, mit der ich das sehr einfach machen kann. Diese muss man in Openhab allerdings separat installieren, damit diese Funktion verwendet werden kann.

Dazu wählt man wieder in Openhab unter Administration / Einstellungen das Icon "Other Add-ons" und sucht hier das JSONPath Transformation Add-On. Nach dessen Installation steht es zur weiteren Verwendung in Openhab ab sofort zur Verfügung.

Nun kann ich in der Liste der Things, den "Energiezaehler" aufrufen. Ich wähle im oberen Bereich des Bildschirms zum "Energiezaehler" den Reiter "Channels und gehe hier auf "Add Channel". Als "Unique_ID" sowie "Label" verwende ich "Stromzaehlerstand" und als "Channel-Type" wähle ich "Number value" aus.

Unter "MQTT State Topic" trage ich meinen Topicnamen ein, unter dem die MQTT Message abgerufen wird: "tele/Keller_SmartMeter/SENSOR"

Jetzt muss ich dem Kanal noch mitteilen, dass er aus dem String oben nur den Wert hinter dem Doppelpunkt von Total_in extrahiert und das Ergebnis immer in diesem Kanal zur Verfügung stellt. Dazu aktiviere ich die Checkbox "Show advanced" und trage unter "Incoming Value Transformations" den Befehl "JSONPATH:$.MT175.Total_in" ein.

Dieser macht im Prinzip folgendes: Er extrahiert aus dem String alles nach dem MT175 Teil und davon auch nur den Teil, der hinter dem Total_in Substring steht. Schön ist in Openhab, dass der Aufruf der Funktion den Wert direkt in den richtigen Datentype (hier numerisch) umwandelt.

Die genaue Erläuterung, wie JASONPath funktioniert findet man hier. Und wer vorher ausprobieren möchte, was aus einem String extrahiert wird, kann das mit dem JASONPath Online Evaluator direkt ausprobieren.

Zum Schluss kann ein Item erzeugt und mit dem Kanal verbunden werden. Dies kann man über die Openhab Oberfläche oder über das Editieren eines .items-Datei z.B. mit Visual Studio Code machen. Anschließend wird dem Item immer der aktuelle Wert des Sensors angezeigt.