In 📗 ESPuino und MQTT hatte ich gewissermaßen ja die Basics bereits beschrieben. Warum? Weil ohne MQTT an dieser Stelle nix geht. Der Vorteil an MQTT ist, dass es ein offenes Netzwerkprotokoll ist und dieses von verschiedenen Hausautomationssystemen verwendet wird. Davon gibt es eine ganze Reihe wie z.B. Node-RED, Home Assistant, ioBroker, FHEM, nymea oder auch openHab. Das soll hier aber weder eine vollständige Aufzählung sein, noch will ich behaupten, dass ich abseits von openHAB bereits etwas Anderes getestet hätte. Daher möchte ich mich im Folgenden auf openHAB einschießen.
Muss ich eine Hausautomationssoftware verwenden?
Grundsätzlich nicht. Die Frage ist nur, ob man Spass dran hat, via MQTT auf Textebene ständig mit seinem ESPuino zu „reden“ 
Es gibt bereits auch via WebGUI eine Steuerung des ESPuino, die nach und nach erweitert wird, so dass man dann die Wahl hat. Weil eine Hausautimationssoftware ausschließlich für ESPuino einzurichten ist vermutlich eher too much. Aber wenn sie eh schon läuft, dann macht das Einbinden eines ESPuino (meines Erachtens) total Sinn.
Warum openHAB?
Mir schwebte damals vor, meine Gartenbewässerung mit einem Raspberry Pi zu steuern. Also im Prinzip so: Man schließt an die GPIOs ein mehrkanaliges Relais an und schaltet damit die Steuerspannung (24V AC) auf Ventile. Nun kann ich meiner Frau halt schlecht sagen: „Dann loggst du dich schnell in die Shell des Raspis ein, schreibst eine 1 in Register xyz und wenn fertig, dann halt wieder eine 0“. Der WAF, wie man das neudeutsch nennt, will ja gewahrt bleiben. Ich hatte dann überlegt, selbst etwas zu programmieren, aber im Endeffekt kam ich dann doch auf die Idee, mal zu suchen, ob es da nicht bereits was gibt. Gestoßen bin ich dann auf openHAB (OH) und FHEM und bin bei OH geblieben, weil es mir moderner vorkam. Aber da gibt es natürlich auch zig andere wie beispielsweise NodeRed, Home Assistant oder ioBroker.
Wie richtet man openHAB ein?
Man kann den manuellen Weg nehmen und selbst Raspi OS + Java + OH installieren/konfigurieren. Alternativ kann man auch openHABian verwenden. Das ist im Prinzip ein Raspi OS, welchem ein paar zusätzliche Install-Routinen zugefügt wurden, so dass es im Anschluss genau auf OH zugeschnitten ist (und das ohne großen manuellen Aufwand). D.h. man schreibt das Image auf einen Datenträger und bootet dann von diesem. Nach dem normalen Bootvorgang wird noch einiges nachinstalliert und schließlich kann man einen Großteil der Konfiguration in der Shell über openHABian-Config vornehmen. raspi-config verschwindet jedoch damit, weil diese gegenseitig konkurrieren würden.
Läuft openHAB auf allen Raspis?
Ja, im Prinzip schon. Ich würde jedoch empfehlen, mindestens einen 3b+ zu verwenden. Ist noch kein Raspi im Haus, dann nehmt am besten gleich einen 4b mit 4 GB Ram. A propos Empfehlung: Normalerweise arbeiten Raspis primär mit SD als Speichermedium. Das Problem mit SD ist jedoch, dass diese es nicht sonderlich gut vertragen, wenn ständig z.B. Logdaten drauf geschrieben werden. Ich arbeite daher mit einer SSD. Der 3b+ konnte davon auch direkt booten, beim 4b muss man dafür erst die Firmware auf den aktuellen Stand bringen. Bei mir hat das problemlos funktioniert, aber ich übernehme keine Haftung dafür, wenn es bei irgendwem Probleme gibt!
Wie wird openHAB konfiguriert?
Puh, damit lassen sich im Prinzip ganze Bücher füllen 
Grundsätzlich gibt es bei OH zwei Wege:
a) Über WebGUI
b) Über Textfiles
Erstgenanntes war bis dato eher ein halbgarer Flickenteppich (meiner Meinung nach), dies wurde mit dem im Dezember 2020 erfolgten 3.0-Release erheblich besser. Für mich persönlich waren die einzigen Dinge, die man dort nicht konfigurieren konnte, die Sitemaps und die Persistence. Über Textfiles lässt sich alles konfigurieren, aber man kann sich leichter ins Bein schießen Im Gegenzug klickt man sich über die GUI zuweilen tot. Beispielsweise wenn ein ESPuino bereits eingerichtet ist und ein weiterer kommt dazu. Bei txt ist man mit Configfiles sehr schnell mit Copy’n’Paste und leichten Veränderungen am Ziel. Also zumindest in der Theorie, denn in der Praxis vergisst man dann doch schnell was zu ändern und plötzlich gibt es Probleme. Wegen Copy’n’Paste sind schon Raketen abgestürzt - warum sollte das hier anders sein? Ich denke ihr kennt das
openHAB via Webgui
Ist openHABian mit der Systemeinrichtung fertig, was gut auch mal 30 Minuten dauern kann, dann könnt ihr via http://:8080 die GUI erreichen und müsst dort erstmal einen Systemaccount einrichten.
Für OH gibt es zahlreiche Plugins, die jedoch Bindings genannt werden. MQTT ist beispielsweise so eines und muss zuerst nachinstalliert werden. Schaut euch dort mal um, da gibt’s wirklich alles Mögliche. Tipp: Es gibt auch für die Fritzbox eines, aber dafür muss man weiter unten nach tr064 suchen. Möchte man MQTT nun verwenden, muss man unter Things schauen und dort ein Konnektor-Element einrichten. Dort legt man dann z.B. die IP-Adresse des Brokers fest, ob TLS gebraucht wird, Passwörter etc pp. Und auf ein solches Konnektor-Element werden dann „Channels“ konfiguriert. Z.B. Volume für einen ESPuino wäre ein solcher Kanal und in diesem Kanal legt man dann auch das MQTT-Topic fest. Gibt es publish+subscribe, was bei Volume ja der Fall ist, dann sind es deren zwei. Um das Ganze dann steuern zu können, braucht man auch noch ein sog. Item, mit dem man den Channel verknüpft. Items können ganz unterschiedliche Typen haben (switch, dimmer, number etc…).
Diese Items organisiert man sich am besten schön in einem Model. Also steht bei mir z.B. ein ESPuino im Zimmer der Tochter, dann habe ich das z.B: so gemacht:
Home (Element vom Typ Location)
Haus (Element vom Typ Location)
Dachgeschoss (Element vom Typ Location)
Zimmer Tochter (Element vom Typ Location)
ESPuino (Element vom Typ Equipment)
Lautstärke (numerisches Item)
Ausschalter (Switch-Item)
Titelanzeige (String-Item)
…
Stellt euch das bitte als Baum vor. Ja und jedes Item verknüpft man dann eben mit jeweils einem MQTT-Channel.
Wie sehe ich das nun alles in einer App?
Was ich bisher erklärt habe ist im Prinzip nur Grundkonfiguration, Organisation und Speicherung der Daten. Das Modell dient dazu, dass man seine Items später auch wieder gut findet. Zur Präsentation dienen sog. Sitemaps. Dort wird festgelegt, wie das Ganze in der App repräsentiert wird. Also beispielsweise könnte man dort das o.g. Modell einfach nochmal nachbilden (was sicherlich Sinn macht), man könnte aber auf oberster Ebene (zusätzlich) z.B. eine Sektion „ESPuinos“ machen. Dort werden dann alle ESPuinos aufgelistet und man muss nicht umständlich durch mehrere Ebenen gehen. Oder stellen wir uns vor, wir haben 15 Räume und in jedem Raum messen wir Temperatur + Luftfeuchtigkeit. Dann wünschen wir uns vielleicht eine Überichtsseite, in der wir alle Werte auf einen Blick haben. In einer Sitemap könnte ich mir dann eine Seite einrichten, die alle Werte untereinander auflistet. Und es ist mir dann gewissermaßen egal, dass die Werte von sonstwo her zusammengesucht werden. Eine Sitemap ist gewissermaßen einfach nur eine „Sicht auf die Dinge“, die nicht notwendigerweise dem o.g. Modell entsprechen muss.
Ist OH uneingeschränkt zu empfehlen
Ganz klar: nein! Also man muss schon Bock drauf haben und Vieles erfährt man erst über Foren, da die Doku (gemessen an der Komplexität von OH) vergleichsweise dünn ist. Also wer einfach nur „anstecken und los“ will, der ist bei OH komplett falsch. Wie das bei anderen Systemen ist kann ich nicht sagen. Aber OH ist auf jeden Fall nicht einfach zu verstehen und ich habe mich mehr als einmal aufgeregt, wenn Konzepte komplett umgestellt wurden oder irgendwas nicht geklappt hat.
Was ist eigentlich aus der Gartenbewässerung geworden?
Die gibt es weiterhin. Allerdings ist der Raspi irgendwann ins Haus gezogen und die Ansteuerung der Ventile läuft über einen ESP32, der mit Ethernet angebunden ist. Auf dem Raspi läuft OH und der ESP32 erhält seine Kommandos, wie soll es auch anders sein, per MQTT von eben diesem Ich erwähne das hier nur nochmal, weil dieses Projekt vermutlich erst dazu geführt hat, dass es ESPuino in seiner jetzigen Form (ESP32 + MQTT) überhaupt gibt.
