In meiner Blogserie zu openHAB (Teil 1, Teil 2, Teil 3) bin ich auf MQTT und das Nutzen verschiedener Geräte und Messdaten eingegangen. Um die Daten zu sehen oder Geräte zu steuern, brauchte es immer die Bedienoberfläche von openHAB. In meinem Fall wollte ich nicht immer das Handy oder Tablet nutzen, um z.B. eine Steckdose oder Licht einzuschalten. Nach einem kurzen Brainstorming kam mir die Idee, das AZ-Touch Mod als vereinfachtes Bedienelement zu verwenden. Die Entwicklung ist noch am Laufen, grundlegende Steuerung und Anzeige funktionieren aber ohne Probleme.

Was das AZ-Touch Mod genau machen soll und wie es konfiguriert wird, erkläre ich Ihnen in diesem Beitrag.

Hardware für diesen Blog

Für diesen Blog ist das AZ-Touch MOD Wandgehäuseset ein Muss, siehe Tabelle 1.

Pos	Anzahl	Bauteil	Link
1	1	AZ-Touch MOD Wandgehäuseset	https://az-delivery.de
2	1	Optional ESP32 NodeMCU Module WLAN WiFi Development Board	https://az-delivery.de
3	1	Spannungsversorgung 12 V

Tabelle 1: Hardware für diesen Blog

Zudem ist zwingend meine Modifikation am AZ-Touch nötig, da wir einen Zugriff auf den SD-Kartenslot des Touchdisplays benötigen und ggf. der Reset-Button an der Außenseite helfen könnte.

Die Idee hinter dem Projekt

Nachdem ich mit openHAB angefangen hatte, wollte ich in meinen vier Wänden nicht immer nur über Tablet oder Smartphone auf die entsprechende Basisseite zugreifen. Gerade mit Kindern und deren Kuschelecke wollte ich ein einfaches Interface schaffen, worüber Sie z.B. einfach die Lichterkette ein- bzw. ausschalten können, oder aber andere Funktionen einfach bedienen können. Gerade für Kinder muss das entsprechende Device und die Bedienung so einfach wie möglich sein und ein einfaches Feedback zurückgeben, das die Kinder auch verstehen. Natürlich darf das Ganze nicht so verspielt sein, dass man als Erwachsener das Gefühl hat, ein Kinderspielzeug zu bedienen. Nach einer längeren Suche im Internet und das daraus resultierende Brainstorming, kam die Idee auf, das AZ-Touch Mod Wandgehäuse mit einem ESP32 zu verwenden. Im Internet bin ich durch Zufall auf einen älteren Artikel gestoßen, der mittels openHAB-API alles modelliert hatte, jedoch wurde dieses Projekt nicht weiter gepflegt und war nicht mehr lauffähig.

Noch vor dem Projekt kam dann aber die zweite Idee dazu, das AZ-Touch Mod Wandgehäuse so zu programmieren, dass keine APIs verwendet werden müssen, sondern auf generelles MQTT zurückgegriffen wird. Grund dieser Idee ist, dass auch ein Betrieb ohne Heimautomationsserver möglich sein soll, was über MQTT leicht realisierbar ist. Ein einfacher MQTT-Broker und IoT-Geräte, welche meist MQTT beherrschen, würden damit vollkommen ausreichen. Man könnte an der Stelle auch von einer Low-Budget-Heimautomationslösung reden.

Ein nicht zu unterschätzender Punkt war am Ende die Konfiguration der einzelnen Elemente auf dem Display. Schnell gibt es ein neues Gerät im Haushalt, das angesteuert werden soll und muss ich dafür wieder den ganzen Quellcode anfassen? Das wollte ich direkt vermeiden, weswegen zusätzlich zur Montage des AZ-Touch Mod Wandgehäuses noch eine Modifikation nötig ist, um auf den SD-Kartenslot zuzugreifen. Hier kann, mittels eines entsprechendem SD-Kartenadapters eine MicroSD-Karte verwendet werden, auf der die komplette Grund- und MQTT-Konfiguration gesichert ist. Wird also ein neues Element auf dem Display benötigt, muss nur die MQTT-Konfiguration erweitert werden. Ein Nachteil, den ggf. einige hier sehen könnten ist, dass natürlich die Zugangsdaten fürs WLAN auf der SD-Karte im Klartext einsehbar sind. Dazu muss man aber wissen, dass eine SD in dem AZ Wandmod verbaut ist.

Wie Sie sehen, steckt hinter dem anfänglichen Grundgedanken ein langer Findungsprozess. Gleichzeitig ist die Featureliste noch während der eigentlichen Arbeit stetig gewachsen, weswegen die Konfigurationsdatei schon Einträge hat, die es noch nicht in den aktuellen Release des Projektes geschafft haben.

Die Oberfläche des AZ-Touch und die Features

Wenn ich Sie nun neugierig auf das Projekt gemacht habe, dann will ich zunächst ein bisschen auf die Oberfläche eingehen, siehe Abbildung 1.

Abbildung 1: Bedienoberfläche des AZ-Touch

Fangen wir mit dem oberen Rahmen an. Zunächst kann man eine Uhr einblenden, um sich die aktuelle Zeit anzeigen zu lassen. Wird diese nicht gewünscht, so wird der NTP-Server nicht eingerichtet und abgefragt, was sich auf die Funktionalität nicht auswirkt. Um ggf. schnell das Gerät zu finden, gibt es die Möglichkeit, dem Device einen Namen zu geben. In der rechten Ecke wird die Signalqualität des WiFi angezeigt. Somit hat man erst einmal die wesentlichen Informationen am oberen Rand.

Herzstück sind die sechs Buttons, die nicht zu übersehen sind. Diese dienen entweder für die reine Informationsanzeige, in meinem Fall 28 Grad bei 40% Luftfeuchtigkeit und einem Button, mit dem MQTT-Stecker ein- bzw. ausgeschaltet werden. Elemente, wie z.B. dem Schalter-Button, geben ein optisches Feedback, ob der Schalter ein- oder ausgeschaltet sein sollte. Hier wird das Feedback von MQTT genutzt, sprich der übermittelte Status des Devices via MQTT.

Weitere Button-Modi sind geplant, bisher sind nur die Modi Info, Measurement, Light und Switch wirklich nutzbar, dazu aber später mehr.

Wie vllt. zu erkennen, sind aktuell nur diese sechs Button möglich, was sich aber mit kommenden Projektständen ändern soll. Hier ist geplant, dass über den Button unten rechts durch das Menü „gescrollt“ werden kann.

In dem Bild nicht zu sehen, aber doch vorhanden, sind Anzeigen von Fehlermeldungen. Wenn z.B. der MQTT-Broker nicht mehr erreichbar ist, oder das WiFi Probleme macht, wird dies über einen entsprechend Dialog auf der Oberfläche angezeigt. Damit ist aber auch gleichzeitig die normale Bedienung über die Touchoberfläche nicht mehr möglich, bis der Fehler behoben wurde.

Ein weiteres Kernfeature, welches auch in meinen Jobs teilweise bewusst missachtet wurde, ist der Watchdog. Sollte der Fall eintreten, dass einmal der verbaute Mikrocontroller hängen bleibt, so wird das Device automatisch neu gestartet. Dieses Feature kann ein- bzw. ausgeschaltet werden und auch der Timeout in Sekunden festgelegt werden, dazu aber mehr bei der Erklärung der Konfiguration.

Ein weiteres Feature ist die Uhr, die angezeigt wird, siehe Abbildung 2. Diese wird eingeblendet, wenn die Zeit angezeigt werden soll und damit der NTP-Dienst startet.

Abbildung 2: Aktuelle Uhrzeit und Datum

Damit wird nicht immer die Statusseite aller Geräte gezeigt. Ist dies doch einmal notwendig, so reicht eine Berührung des Touchdisplays, um auf die Buttonseite zu gelangen. Auch hier wird der Wechsel von Button-Oberfläche zur Uhr über eine einstellbare Zeit in der Konfiguration realisiert.

Die Konfiguration

Wie bei der Vorstellung des Displays erwähnt, wird über Konfigurationsfiles auf einer SD-Karte das AZ Wandmod konfiguriert. Dazu wird bei Start versucht, auf den SD-Kartenslot des Displays zuzugreifen. War dies erfolgreich, so wird nach folgenden Dateien gesucht, die zwingend auf der SD-Karte liegen müssen:

• general.xml
• MQTT.xml

Wie die Endung vllt. vermuten lässt, handelt es sich um zwei separate XML-Dateien. Die Syntax von xml ist nicht schwierig, ich empfehle an der Stelle gerne Notepadd++ mit dem Plugin XML Tools, welches direkt auf Fehler in der XML-Syntax beim Speichern hinweist.

general.xml

Zunächst die general.xml, welche die Grundkonfiguration fürs AZ Wandmod beinhaltet. An dieser Stelle wird z.B. der Zugang zum WiFi und dem MQTT-Broker beschrieben. Schaut man sich die Beispieldatei im Projekt an, siehe Code 1, ist die Konfiguration überschaubar.

 <?xml version="1.0" encoding="utf-8"?>
 <root>
     <GUI name="AzTouch openHab" darkMode="0" showTime="1"/>
     <WiFi name="WiFi" SSID="Test-WiFi" Pass="Test-Pass"/>
     <Secure name="Secure" active="0" pass="12345" timeout="5"/>
     <MQTT name="MQTT" broker="Testbroker" port="1883" user="" pass="" clientName="Wallmount"/>
     <Watchdog name="Watchdog" active="1" time="10"/>
 </root>

Code 1: Beispieldatei von general.xml

Tabelle 2 erklärt dabei jeden einzelnen Parameter, um Missverständnisse auszuräumen.

Knoten	Attribut	Beschreibung	Default
GUI	name	Name der auf der Oberfläche angezeigt wird. Max 18. Zeichen auf dem Display erlaubt.	AzTouch openHab
	darkMode	Wird in einem späteren Release zwischen einem hellen oder dunklen Bildschirm wechseln	„0“, helles Display
	showTime	Soll die Uhrzeit angezeigt werden? Startet einen NTP-Client und synct die Zeit	1
WIFI	name	Name des Knotens, hat hier keine Bedeutung	„WiFi“
	SSID	Hier die SSID des WLANs eintragen	„Test WiFi“
	Pass	Passwort des WLANs	„Test-Pass“
Secure	name	Name des Knotens, hat in der Konfiguration keine Bedeutung	„Secure“
	active	(De-)aktiviert das Numpad auf dem Display, um das Passwort einzugeben. Noch nicht implementiert!!!	„0“
	pass	Das Passwort zum Freischalten, nur Zahlen erlaubt	„12345“
	timeout	Die Zeit, die vergehen muss, bis der Bildschirm wieder gesperrt wird und die Uhr oder das Numpad für die Zahleneingabe. Zeit in Minuten	5
MQTT	name	Name des Knotens, hat in der Konfiguration keine Bedeutung	„MQTT“
	broker	Hier den DNS-Namen oder die IP-Adresse eintragen	„Testbroker“
	port	Der Port zu MQTT, kann abweichen	1883
	user	Sofern ein User zur Anmeldung gebraucht wird, hier den User eintragen	„“
	pass	Passwort für den User, um sich mit MQTT zu verbinden	„“
	clientName	Beschreibt den Namen, unter dem sich das Device bei MQTT anmeldet. Keine Leerzeichen im Namen erlaubt!	„Wallmount“
Watchdog	name	Name des Knotens, hat in der Konfiguration keine Bedeutung	„Watchdog“
	active	(De-)aktiviert den Watchdog	„1“
	time	Die Watchdogzeit in Sekunden. Achtung: Werten unter 2 Sekunden können zu einem boot-loop führen	„10“

Tabelle 2: Erläuterung der Parameter general.xml

Mehr Einträge sind in dieser Datei nicht vorhanden und werden auch nicht geprüft. Um Fehler oder Probleme zu vermeiden, sollte die Beispieldatei als Vorlage verwendet werden.

MQTT.xml

Fast genauso wichtig wie die general.xml ist die MQTT.xml. Diese beschreibt aktuelle mehrere Dinge:

• Den anzuzeigenden Namen des Buttons
• Den Typ des Buttons, wichtig für Anzeige und Steuerung,
• Die Position für den Button auf der aktuellen Seite
• Auf welcher Seite der Button sich befinden soll, aktuell geht nur die erste Seite
• Den pub und sub-Knoten, um Kommandos an MQTT zu schicken und den Status zu erhalten

Auch an der Stelle hilft das Beispiel aus dem Projekt, siehe Code 2.

 <?xml version="1.0" encoding="utf-8"?>
 <root>
     <Element name="Switch" type="Switch" pos="1" page="1">
         <pub>cmnd/NOUS_Monitor/POWER</pub>
         <sub>stat/NOUS_Monitor/POWER</sub>
     </Element>
     <Element name="Info" type="Measurement" pos="2" page="1">
         <sub unit="Grad">shellies/shellyht-office/sensor/temperature</sub>
         <sub unit="%">shellies/shellyht-office/sensor/humidity</sub>
     </Element>
 </root>

Code 2: Beispieldatei für MQTT.xml

Für das Verständnis der einzelnen Knoten und Attribute hilft Tabelle 3.

Knoten	Attribut	Beschreibung	Default
Element	name	Name für den Button	„“
	type	Art des Buttons, wird weiter unten genauer beschrieben	„“
	pos	Gibt die Position auf der jeweiligen Seite an	„-1“
	page	Gibt an, auf welcher Seite der Button sein soll	„-1“
Element -> pub		Beschreibt, an welchen MQTT-Knoten ein Kommando gesendet werden soll
Element -> sub		Beschreibt, welcher Knoten für den Status überwacht werden soll
	Unit	Spezialfall beim type „Measurement“ oder „Info“, hier wird ein Suffix an den Inhalt der Nachricht angefügt	„“

Tabelle 3: Erläuterung der Parameter MQTT.xml

Bei der Definition gibt es aber ein paar Regeln. Zwar kann man beliebig Position und Seite für den Button vergeben, jedoch überprüft das Programm intern, wie viele Seiten tatsächlich benötigt werden und ob die Position schon belegt ist. Wird eine Seite ausgewählt, die nicht den kalkulierten Seiten entspricht, oder aber die Position auf der Seite schon belegt sein sollte, so werden diese Elemente erst einmal übersprungen und nachträglich Lücken in den Seiten gefüllt. Sollten zu wenige Seiten vorhanden sein, so wird auch hier erweitert, sodass alle Elemente Platz finden.

Bei den Typen „Measurement“ oder „Info“ ist es möglich, bis zu drei Sub-Knoten zu hinterlegen. Diese dienen aber nur der Anzeige und können nichts an den Broker verschicken! Dadurch werden dann in dem Button in drei Zeilen die Werte angezeigt. Das ist z.B. praktisch, wenn man hier Umgebungswerte anzeigen möchte.

Eine große Frage wird wahrscheinlich noch sein, welche Typen es alles gibt, dazu gibt Tabelle 4.

Type	Beschreibung	Bild	Bemerkung
Info	Zeigt bis zu drei Werte an, entsprechende Sub-Knoten müssen dem Element angehängt sein		Symbol ist grau beim Button hinterlegt
Measurement	Zeigt bis zu drei Messwerte an. Entsprechende Sub-Knoten werden benötigt		Symbol ist grau beim Button hinterlegt
Light	Button um einen Lichtschalter zu symbolisieren		Wenn „off“ rot, sonst grün
Socket	Button, der z.B. für eine Steckdose gedacht ist		Wenn „off“ rot, sonst grün
Switch	Button, der ein Ein-/Aus-Schalter symbolisiert		Wenn „off“ rot, sonst grün
Shutter	Knoten definiert einen Rollladen, der jeweils zwei Sub und Pub-Knoten benötigt. Dadurch werden zwei getrennte Buttons, die untereinander dargestellt werden, angezeigt		Ist aktuell noch nicht in der Software implementiert.
	Symbol auf dem Display, um zwischen den Seiten zu „scrollen“		Kann nicht als Typ in der Konfiguration ausgewählt werden. Ist immer Schwarz

Tabelle 4: Aktuell vorhandene Typen

Aktueller Projektstand Dezember 2023

Das Projekt ist bei mir schon seit gut 5 Monaten am Laufen. Während der Entwicklung sind viele Ideen entstanden und auch viele Ideen wieder verworfen worden. Letztlich haben es folgende Features in meine Release 1.2.2 geschafft:

• Anzeige einer analogen Uhr mit Kalenderwoche und digitalen Anzeigen
• Volle Konfiguration über den internen SD-Card Slot des Displays
• Ein Darkmode, damit der Bildschirm gerade nachts nicht so hell ist
• Mehrere Seiten für Buttonaktionen und Anzeige
• NTP-Kommunikation
• Diverse Buttontypen, die verschiedene Dinge bewirken
• Anzeige der Verbindungsstärke
• Freie Konfiguration aller Pins via platformIO, wenn das Projekt z.B. ein anderes Display nutzen soll

Damit ist das Ende meiner Featureliste zwar nicht erreicht, es reicht aber zunächst für den ersten Start. Da ich aktuell keine elektrischen Fensterheber habe, hat das Feature „Shutter“ noch keine große Relevanz für mich, was sich aber bestimmt noch ändern wird.

Über den Tellerrand

Dieses Projekt ist parallel zu meiner Blogserie über openHAB entstanden. Dadurch habe ich noch einmal viel über openHAB, aber auch MQTT gelernt. Das Projekt kommt aber auch sehr gut ohne openHAB aus! Lediglich ein MQTT-Broker und ein paar IoT-Geräte sind notwendig, um mit dem Display schon etwas machen zu können. Gerade mein 3D-Drucker oder mein großer Arbeits-PC haben Tasmota-Smart-Steckdosen verpasst bekommen, um den Stromverbrauch im Haus zu senken. Denkbar sind aber auch andere Konzepte in den eigenen vier Wänden. Da MQTT eines der Protokolle ist, die fast jedes gängige Smart-Home-Device kennt,

Fazit

Das hier vorgestellte Projekt ist noch lange nicht fertig. Schon vor Release ist der Quellcode auf meinem GitHub-Repository verfügbar, aber eben noch nicht so detailliert beschrieben. Viele Features und Bugfixes warten noch bei diesem Projekt auf mich, aber gerade solche Projekte zeigen, dass es nicht immer eine teure Lösung von namenhaften Herstellern braucht, um z.B. die Heimautomation von openHAB auf ein externes Display zu bringen. Mit dem bisherig verwendeten Arbeitsspeicher des NodeMCU ist noch viel möglich. Das komplette Projekt ist zu finden unter https://github.com/M3taKn1ght/AZ-Touch-Control