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.

Um die CCU3 in openHAB einzubinden installiert man dazu das "Homatic Binding" von Gerhard Riegler. Über dieses Binding werden anschließend alle verfügbaren Geräte als Things erzeugt. Aus denen kann dann entweder per Paper UI oder durch eine .items-Datei die Items (Eigenschaften) erzeugt werden, die weiter genutzt werden sollen.

Aufgabenstellung

Ich steuere das Rauf- und Runterfahren von Rolladen morgens und abends über ein kleines openhab-Programm (rules). Unerwartet fuhren ohne Veränderungen des Gesamtsystems manchmal einige Rolladen nicht mehr rauf oder runter.

Das Ganze erzeugte dann in openHAB-Logfile einen Fehlereintrag in der folgenden Art:

"Error during the execution of startup rule 'Automatische Verschattung der Jalousien': Could not cast NULL to java.lang.Number; line 15, column 28, length 30".

In einem anderen Fall fuhren die Rollläden plötzlich zur Mittagszeit am hellen Tag im Winter herrunter. Hier konnte ich über das Logfile nur feststellen, dass der zugrundeliegende Helligkeitswert für das Runterfahren auf dem Zahelnwert Null stand.

Durch Neustart von openHAB auf einem RASPI konnten die beschriebenen Probleme behoben werden tauchte aber in unregelmäßigen Abständen immer mal wieder auf.

Ursachenforschung

Das fehlerhafte Rauf- und Runterfahren morgens oder abends konnte ich wie folgt eingrenzen:

Bei den Rollandenaktoren ergab eine kurze Prüfung, dass bei der Abfrage des Levels in openHAB (i.d.R. auf Kanal 4 des Rolladenaktors) der Wert NULL in dem betroffenen Rolladen-Item gespeichert war.

Wenn ich manuell den Rolladen anschließend hoch- oder runterfuhr wurde dies in dem betroffenen Item nicht aktualisiert.In der CCU3 wurden alle Rolladenstellungen hingegen korrekt angezeigt. Die Vermutung eines Synchronisierungsfehlers zwischen openHAB und der CCU3 über das Homeatic Binding war geboren.

Das plötzliche Herunterfahren der Rolläden zur Mittageszeit konnte ich auch identifizieren. Ich nutze für die Prüfung, ob die Helligkeit draußen schon so niedrig ist, dass die Rolläden runtergefahren werden sollen eine Mittelwertfunktion aus dem RRD4J-Binding über die letzten 10 Minuten. Dieses greift auf die für dieses Items gespeicherten Daten in der RRD4J-Datenbank zurück. Dort waren allerdings in den letzten 10 Minuten die Werte Null gespeichert worden, da scheinbar keine korrekten Werte mehr von der CCU3 empfangen werden konnten.

Dieses Sachverhalt konnte ich über einen Chart auf dem Habpanel für diese Helligkeitswerte sehen:

Hierbei stellte sich heraus, dass nicht nur Null-Werte vorhanden sondern Werte scheinbar eingefroren waren, d.h. nicht mehr aktualisiert wurden. Dies stärkte die Vermutung, dass es sich um Synchronisationsprobleme zwischen openHAB und der CCU3 handelt.

Lösung

Wer sich das homematic-Binding anschaut wird feststellen, dass hier ein wichtiges Objekt erzeugt wird, welches für den Zugriff auf Systemvariablen, Systemprogramm aber auch die Synchronisation genutzt wwerden kann: GATEWAY-EXTRAS. Nach Erzeugung des Things gibt es ein Item, über dass sich eine manuelle Snchronisation zwischen beiden Systemen starten lässt: RELOAD_ALL_FROM_GATEWAY. Dieses Item kann den Wert ON oder OFF erhalten. Sobald es auf ON steht, werden alle möglichen Items und deren Inhalte mit der CCU3 neu synchronisiert. Dies führt z.B. auch dazu, dass eine auf der CCU3 neu angelegte Systemvariable sofort in openHAB erscheint. Denselben Effekt kann man erzwingen, indem das GATEWAY-EXTRAS-Thing gelöscht und nach Erscheinen in der Inbox von openHAB wieder erzeugt wird.

Warum dieser Dienst zwischendurch ins Stocken gerät, habe ich nicht auflösen können. Stattdessen habe ich ein kleines Programm auf anderen Webseiten gefunden, welches alls paar Minuten (bei mir alle 10 Minutn) zwangsweise die Synchronisation startet.

Hierzu muss zuerst ein Item wie folgt angelegt werden:

Nun kann durch eine kleine Rule in openHAB ein Script zur Synchronisation z.B. alle 5 Minuten gestartet werden.