Die Haus­au­to­ma­ti­sie­rung oder neu­deutsch das Smart Home ist seit etli­chen Jah­ren von kei­ner Computer- oder Elek­tronik­mes­se mehr weg­zu­den­ken. Manch­mal hat man ja das Gefühl, dass es dort seit mehr als 20 Jah­ren immer um die glei­chen bei­den The­men geht: intel­li­gen­te Kühl­schrän­ke und fern­steu­er­ba­re Hei­zungs­ther­mo­sta­te. Jüngst sind noch schalt‑, dimm- und ein­färb­ba­re Lam­pen dazu­ge­kom­men. Die­ser Arti­kel soll zei­gen, dass es auch durch­aus sinn­vol­le Anwen­dun­gen für die Smart-​Home-​Steuerungen gibt: bei­spiels­wei­se das Brauen.

SmartHome-​Pi

Das Pro­jekt Smar­tes Brau­en rich­tet sich an die­je­ni­gen Brau­er, die ohne­hin schon eine Haus­au­to­ma­ti­sie­rung besit­zen. Ins­be­son­de­re sind die Elektronik- und IT-​Freaks ange­spro­chen, die das mit Open-​Source-​Software wie dem Message-​Broker MQTT und dem Pro­gram­mier­sys­tem Node-​Red tun. Ein sol­ches Sys­tem arbei­tet bei mir, nach­dem ich mich lan­ge mit pro­prie­tä­ren Lösun­gen wie Home­ma­tic WebUI, AVM Fritz mit DECT-​ULE, Phil­ips Hue und Son­off E‑WeLink her­um­ge­är­gert habe.

Wie genau das Sys­tem auf einem Raspber­ry Pi auf­ge­baut ist, könnt ihr in mei­nem EDV-​Blog lesen [1]. Mit dem Smarthome-​Pi bin ich offen für nahe­zu alle Haus­au­to­ma­ti­sie­rungs­pro­to­kol­le und muss mich nicht mehr über ein gerin­ges Ange­bot an Sen­so­ren und Akto­ren, man­geln­de Kom­pa­ti­bi­li­tät mit Pro­duk­ten ande­rer Her­stel­ler, Bin­dung an Cloud-​Systeme und oft hohe Kos­ten der kom­mer­zi­el­len Lösun­gen ärgern.

Son­off TH16

Son­off ist für Haus­au­to­ma­ti­sie­rer ein bekann­ter Name. Die chi­ne­si­sche Fir­ma baut preis­wer­te WLAN-​Schaltsysteme, die güns­ti­ge Lösun­gen für vie­le Auto­ma­ti­sie­rungs­pro­ble­me mög­lich machen. Eine der bes­ten Eigen­schaf­ten der klei­nen Gerä­te ist die Mög­lich­keit, sie recht ein­fach aus der Bin­dung an die Cloud des Her­stel­lers lösen zu kön­nen. Durch Auf­spie­len einer alter­na­ti­ven Firm­ware wie Tas­mo­ta von Theo Are­nd [2] wer­den sie zu offe­nen Sys­te­men, die sich ein­fach an freie Auto­ma­ti­sie­rungs­lö­sun­gen wie FHEM, Open­HAB, ioBro­ker oder MQTT und Node-​Red kop­peln lassen.

Wie man die alter­na­ti­ve Tasmota-​Firmware auf die Sonoff-​Geräte bekommt, ist in unzäh­li­gen Anlei­tun­gen im Web beschrie­ben. Ich habe einen USB-​Seriell-​Adapter (ein preis­wer­ter FTDI aus Chi­na) benutzt und mich gene­rell an die Anlei­tung für die Vari­an­te mit Plat­for­mIO unter Visu­al Stu­dio Code gehal­ten [3]. Ähn­lich funk­tio­niert es auch mit dem Atom-​Editor [4] oder mit dem esp­tool direkt vom GPIO eines Raspberry-​Pi aus [5].

Bei eini­gen Vari­an­ten muss man vor dem Fla­shen noch Pins für die Sende- und Emp­fangs­lei­tun­gen auf­lö­ten. Die Boh­run­gen und Löt­pads sind schon vor­han­den, es muss also nur noch eine 4er Stift­leis­te ein­ge­setzt und ver­lö­tet wer­den. Rechts ist das exem­pla­risch bei einem Son­off Basic zu sehen. Die I/​O‑Pins lie­gen in der Mit­te hin­ter dem Taster.

Für die Tem­pe­ra­tur­steue­rung beson­ders inter­es­sant ist das Son­off TH16. Hier ist ein WLAN-​gesteuertes Schalt­re­lais für bis zu 16A Last mit einem per Klin­ken­ste­cker ansteck­ba­ren Tem­pe­ra­tur­sen­sor in einem Gehäu­se mit Elektriker-​freundlichen Klemm­an­schlüs­sen kom­bi­niert. Damit hat man in der Grö­ße einer Ziga­ret­ten­schach­tel alles zusam­men, um einen ein­fa­chen Ther­mo­sta­ten für Hei­zun­gen bis 3,5 kW auf­zu­bau­en. Die Kopp­lung an MQTT macht außer­dem eine maß­ge­schnei­der­te Pro­gramm­steue­rung möglich.

Der Test­auf­bau ist im Foto rechts zu sehen. Links auf dem Brett der TH16 mit dem Kabel­sen­sor (muss aus­drück­lich mit­be­stellt wer­den). Dazu wird ledig­lich ein Netz­ka­bel und eine Steck­do­se für die Hei­zung an die Schraub­klem­men des TH16 ange­schlos­sen. Die Zug­ent­las­tung durch die Gehäu­se­klap­pe ist zwar etwas wacke­lig, erfüllt aber ihren Zweck.

Kopp­lung an MQTT

Hat man die Tasmota-​Software auf das TH16-​Modul geflasht, kann man sich direkt mit ihrem Web-​Interface ver­bin­den, um die nöti­gen Ein­stel­lun­gen vor­zu­neh­men. Die (vom DHCP zuge­wie­se­ne) IP-​Adresse des Moduls wird am Ende des Flash-​Vorgangs im Pro­to­koll ausgegeben.

Auf der Home­page kann man schon mal aus­pro­bie­ren, ob das Schal­ten funk­tio­niert. Beim Druck auf die An/​Aus-​Taste soll­te das Relais im TH16 deut­lich hör­bar kla­ckern. Klappt das, kann man zu den Ein­stel­lun­gen und von dort zunächst zur Geräte-​Konfiguration gehen. Aus der Lis­te für den Gerä­te­typ wäh­len wir „Son­off TH (4)” aus. Die­ser Typ passt sowohl zum TH10 als auch zu unse­rem TH16.

Bei GPIO14 wird dann schon „Sen­sor” ange­zeigt, denn die­ser Digi­tal­aus­gang des Pro­zes­sors ist mit der Sensor-​Klinkenbuchse fest ver­drah­tet. Für den Tem­pe­ra­tur­sen­sor wäh­len wir aus der Lis­te den Ein­trag „DS18x20 (4)” aus. Nach dem Spei­chern soll­te auf der Home­page über dem Schalt­zu­stand nun auch die Tem­pe­ra­tur des Sen­sors ange­zeigt wer­den. Falls nicht, soll­te man die Steck­ver­bin­dung für den Sen­sor kon­trol­lie­ren; sie muss stramm bis zum Anschlag ein­ge­steckt sein.

Schließ­lich gehen wir zurück zu den Ein­stel­lun­gen und von dort zu „MQTT kon­fi­gu­rie­ren”. Dort tra­gen wir IP-​Adresse des MQTT-​Brokers ein. Falls der Bro­ker eine Anmel­dung ver­langt (und aus Sicher­heits­grün­den soll­te er das), tra­gen wir noch Nut­zer­na­me und Pass­wort ein. Den Rest kann man zunächst auf den Vor­ga­be­wer­ten belas­sen und das Gan­ze speichern.

Am MQTT-​Broker soll­te man jetzt unter dem Topic „sonoff/​#” schon Mel­dun­gen ein­lau­fen sehen. Zum Über­prü­fen kann man bei­spiels­wei­se den MQTT-​Client MQTT.fx ver­wen­den, wo es nach dem Ver­bin­den mit dem Bro­ker und dem Abon­nie­ren von „sonoff/​#” etwa wie auf dem Bild rechts aus­se­hen soll­te. Die Sta­tus­mel­dun­gen mit der aktu­el­len Sensor-​Temperatur wer­den stan­dard­mä­ßig aller­dings nur alle 5 Minu­ten gesendet.

Ein­bin­dung in Node-Red

Die Pro­gram­mier­um­ge­bung Node-​Red [6] wur­de ursprüng­lich 2013 von IBM ent­wi­ckelt, um im Umfeld der Indus­trie­au­to­ma­ti­sie­rung die Mani­pu­la­ti­on von Daten­strö­men mit gra­fi­schen Funk­ti­ons­le­men­ten (Kno­ten oder Nodes) und Ver­bin­dun­gen auch für Nicht-​Programmierer zu ermög­li­chen. Inzwi­schen ist das um hun­der­te Plug­ins in vie­len Rich­tun­gen wei­ter­ent­wi­ckel­te Sys­tem ein Open-​Source-​Projekt der JS-Foundation.

Die MQTT-​Ein- und Aus­ga­be­kno­ten gehö­ren zum Stan­dard­um­fang von Node-​Red. Zum Ken­nen­ler­nen kön­nen wir einen MQTT-​Eingang hin­zu­fü­gen und den Inhalt der Nach­rich­ten mit den debug-​Konten ausgeben.

Auf einem neu­en Flow plat­zie­ren wir dazu den mqtt-​Knoten aus der Grup­pe Ein­ga­be. Mit einem Dop­pel­klick dar­auf öff­net sich der Kon­fi­gu­ra­ti­ons­dia­log. Zunächst müs­sen wir unse­ren MQTT-​Broker bekannt­ma­chen, wenn er nicht schon für ande­re Flows ein­ge­rich­tet wur­de. Dazu kli­cken wir auf die Server-​Liste, wäh­len „Neu­en mqtt-​Broker hin­zu­fü­gen…” aus und kli­cken dann auf das Stift-​Symbol rechts daneben.

Dadurch öff­net sich der Dia­log zum Kon­fi­gu­rie­ren des mqtt-​Servers. Wir ver­ge­ben zunächst einen belie­bi­gen Namen. Unter „Ver­bin­dung” tra­gen wir die IP-​Adresse des mqtt-​Brokers ein. Läuft er auf dem glei­chen Rech­ner, wäre das 127.0.0.1. Unter „Sicher­heit” muss Nut­zer­na­me und Pass­wort ein­ge­ge­ben wer­den. Alle ande­ren Anga­ben kön­nen zunächst auf den Vor­ga­ben blei­ben. Mit einem Klick auf „Hin­zu­fü­gen” keh­ren wir zur Kon­fi­gu­ra­ti­on des mqtt-​Knotens zurück.

Hier muss noch ein Topic ein­ge­tra­gen wer­den. Das ist der Nach­rich­ten­typ, auf den wir mit dem mqtt-​Knoten hören möch­ten. Für die­sen Test abon­nie­ren wir mit „sonsoff/​#” ein­fach alle Nach­rich­ten, die mit „sonoff/​” begin­nen. Das Hash-​Zeichen schließt als Wild­card alle dar­un­ter­lie­gen­den Ebe­nen ein. Mit „Fer­tig” schlie­ßen wir die Kon­fi­gu­ra­ti­on ab.

Nun brau­chen wir noch eine Mög­lich­keit zur Anzei­ge der Nach­rich­ten. Dazu dient für Test­zwe­cke der „debug” Kno­ten, der Tei­le oder die gan­ze Nach­richt im Debug-​Fenster der Node-​Red-​IDE anzeigt. Wir zie­hen ihn aus der Grup­pe „Aus­ga­be” auf unse­ren Flow und ver­bin­den sei­nen Ein­gang mit dem Aus­gang des mqtt-​Knotens. In sei­ner Kon­fi­gu­ra­ti­on (Dop­pel­klick) stel­len wir bei „Aus­ga­be” noch von „msg.payload” auf „Vol­les Nachrichten-​Objekt” um; so sehen wir die kom­plet­te Message.

Mit einem Klick auf „Imple­men­tie­ren” im Kopf der IDE wird unser Test-​Flow wirk­sam. Ein Klick auf die klei­ne Wan­ze im rech­ten Teil­fens­ter zeigt das Debugging-​Window an. Dort soll­ten nach kur­zer Zeit die Mel­dun­gen unse­res Sonoff-​Switches einlaufen.

Im Debugging-​Fenster erken­nen wir den Auf­bau der Mes­sa­ges. Sie ent­hal­ten ein Objekt, des­sen topic-​Property das MQTT-​Topic dar­stellt. In der Pay­load steckt die eigent­li­che Nach­richt in Form eines Strings im json-​Format. Er reprä­sen­tiert ein Object mit dem Mess­zeit­punkt (im ISO-​Format), der Tem­pe­ra­tur­ein­heit (hier: °C) und einem wei­te­ren Object mit dem eigent­li­chen „Temperature”-Wert.

Tem­pe­ra­tur­an­zei­ge

Als klei­ne Übung kli­cken wir uns jetzt eine simp­le Tem­pe­ra­tur­an­zei­ge zusam­men. Das ist mit Node-​Red-​Bordmitteln ganz einfach.

Falls das Dash­board noch nicht in unse­rer Node-​Red-​Instanz instal­liert ist, holen wir das jetzt nach: aus dem Pizza-​Menü rechts oben wäh­len wir „Palet­te ver­wal­ten” aus. Damit kön­nen unter ande­rem neue Kno­ten­ty­pen instal­liert wer­den. In das Such­feld unter „Instal­lie­ren” tip­pen wir „Dash­board” ein, wonach in der Lis­te dar­un­ter „node-​red dash­board” erschei­nen soll­te. Ein Klick auf Instal­lie­ren fügt die Kno­ten hin­zu. Am Ende der Kno­ten­lis­te links soll­te jetzt eine neue Grup­pe „dash­board” auf­ge­taucht sein.

Dar­aus wäh­len wir jetzt einen Tacho-​Anzeiger, den Kno­ten­typ „gau­ge”, und set­zen ihn neben unse­ren mqtt-​Eingang. In der Kon­fi­gu­ra­ti­on set­zen wir das Label auf „Sensor-​Temperatur”, die „Ran­ge”, also die mög­li­chen Wer­te, auf 0 bis 100 und die „Units” auf °C.

Den mqtt-​Eingang schrän­ken wir auf die SENSOR-​Meldungen ein, indem wir das Topic auf „sonoff/tele/+/SENSOR” ändern. Das + ist dabei ein Platz­hal­ter für eine Ebe­ne der Topic-​Bezeichnung. Dadurch errei­chen uns nur noch die SENSOR-​Meldungen der sonoff-Geräte.

Als nächs­tes müs­sen wir aus dem json-​String, der vom Sen­sor gelie­fert wird, ein Java­script Object erzeu­gen. Das erle­digt ohne wei­te­re Kon­fi­gu­ra­ti­on der json-​Knoten aus der Grup­pe „Funk­ti­on”. Wir set­zen ihn zwi­schen mqtt und gauge.

Als letz­tes muss noch der Tem­pe­ra­tur­wert aus dem Object extra­hiert wer­den. Das macht am bes­ten der change-​Knoten, eben­falls aus der „Funktion”-Gruppe. in der Kon­fi­gu­ra­ti­on set­zen wir den Inhalt der Mes­sa­ge (msg.payload) auf msg.payload.DS18B20.Temperature.

Jetzt müs­sen noch die Ein- und Aus­gän­ge in der Rei­hen­fol­ge mqtt – json – chan­ge – gau­ge ver­bun­den wer­den und der Flow mit „Imple­men­tie­ren” akti­viert werden.

Danach erscheint im Dash­board unse­re Temperaturanzeige.

Manu­el­les Schalten

Zum manu­el­len Schal­ten benut­zen wir den „switch”-Knoten. In der Kon­fi­gu­ra­ti­on kön­nen wir ihm ein pas­sen­des Label ver­pas­sen, zum Bei­spiel „Manu­ell An/​Aus”. Stan­dard­mä­ßig sen­det der Schal­ter eine Mes­sa­ge mit „true” wenn er ein­ge­schal­tet wird und ein „fal­se” beim Aus­schal­ten. Wir ändern das auf die Strings „ON” und „OFF”. So kön­nen wir die­se Mes­sa­ge sofort an den mqtt-​Broker wei­ter­lei­ten, und zwar an das Topic, das für das Schal­ten des Relais ver­ant­wort­lich ist. In unse­rem Fal­le wäre das das Topic „sonoff/​cmnd/​sonoff-​4938/​POWER”, dass wir in einen neu­en mqtt-​Ausgang ein­tra­gen. Sei­nen Ein­gang ver­bin­den wir mit dem Aus­gang des Schalters.

Das Schal­ten soll­te nach dem Imple­men­tie­ren schon funk­tio­nie­ren. Aller­dings zeigt der Schal­ter nicht unbe­dingt den wirk­li­chen Zustand des Relais an, etwa nach Neu­start der Node-​Red-​Umgebung. Um das zu errei­chen, legen wir den Sta­tus des Relais (Topic sonoff/​stat/​sonoff-​4938/​POWER) als Ein­gang des Swit­ches an. Im Switch muss noch der Haken bei „If msg arri­ves on input, pass through to out­put” ent­fernt wer­den, ansons­ten gäbe es eine Rück­kopp­lung. Statt­des­sen wäh­len wir unter „Indi­ca­tor” den Ein­trag „Switch shows the sta­te of the input”, damit uns immer der wah­re Sta­tus des Relais ange­zeigt wird. Beim Betä­ti­gen merkt man jetzt eine gerin­ge Ver­zö­ge­rung, bis der Schal­ter den gewünsch­ten Sta­tus anzeigt, da die­se Infor­ma­ti­on jetzt über den Umweg mqtt und WLAN geht.

Das Dash­board soll­te jetzt so wie unten dar­ge­stellt aus­se­hen, und ein Klick auf den Schal­ter soll­te das Relais hör­bar schal­ten lassen.

Ein­fa­cher Thermostat

Wir kön­nen jetzt zwar das Relais für die Hei­zung von Hand schal­ten und die Sen­sor­tem­pe­ra­tur anzei­gen, um aber eine Auto­ma­ti­sie­rung zu errei­chen, müs­sen wir den Schalt­vor­gang von der Soll- und Ist-​Temperatur abhän­gig machen.

Dafür fügen wir zunächst ein zwei­tes Gau­ge zur Anzei­ge der Ziel-​Temperatur ein, ver­ge­ben ein Label und set­zen Mini­mal– und Maxi­mal­tem­pe­ra­tur sowie Ein­heit wie bei der Sensor-Temperatur.

Zum Ein­stel­len der Ziel-​Temperatur benut­zen wir einen slider-​Knoten aus der dashboard-​Gruppe. Er erhält die glei­chen Grenz­wer­te wie die Anzei­ge (0 bis 100). Ver­bin­det man slider-​Ausgang und gauge-​Eingang, kann man nach dem Imple­men­tie­ren die Anzei­ge schon mit dem Schie­be­reg­ler steuern.

Lei­der kann man in Node-​Red auf den ein­ge­stell­ten Wert eines Kno­tens nicht so ein­fach zugrei­fen. Statt­des­sen benut­zen wir den Kontext-​Speicher des Flows, um die Ziel­tem­pe­ra­tur zwi­schen­zu­spei­chern. Ein Change-​Knoten, der die payp­load der slider-​Message auf flow.targetTemp spei­chert, erfüllt die­sen Zweck. Er wird zwi­schen slider und gau­ge platziert.

Jetzt fehlt nur noch eine Temperatur-​Auswertungslogik. Sie soll im ein­fachs­ten Fal­le die Hei­zung ein­schal­ten, wenn die Sensor-​Temperatur unter­halb der Ziel-​Temperatur liegt, und bei Errei­chen der Ziel-​Temperatur wie­der abschal­ten. Das errei­chen wir mit einem function-​Knoten aus der Grup­pe „Funk­ti­on”, in dem man belie­bi­gen Javascript-​Code aus­füh­ren las­sen kann, in unse­rem Fal­le diesen:

return {payload: msg.payload < flow.get('targetTemp') ? 'ON' : 'OFF'}

Somit gibt die Funk­ti­on eine Mes­sa­ge mit der pay­load „ON” aus, solan­ge die aktu­el­le Tem­pe­ra­tur unter­halb der Ziel-​Temperatur liegt, ande­ren­falls „OFF”. Die Ziel­tem­pe­ra­tur wird dafür aus dem flow-​Kontextspeicher geholt, wohin wir sie oben im change-​Knoten gespei­chert hat­ten. Den Aus­gang kann man nun direkt mit dem mqtt-​Knoten für das Schalt­kom­man­do verbinden.

Hier könn­te man sicher eini­ges opti­mie­ren, indem man zum Bei­spiel einen Zwei­punkt­reg­ler mit Schalt-​Hysterese oder einen PID-​Regler einsetzt.

Das Relais soll­te nun ein­schal­ten, sobald die ein­ge­stell­te Ziel-​Temperatur unter­schrit­ten ist. Der Tem­pe­ra­tur­ver­gleich wird immer aus­ge­führt, sobald ein neu­er Mess­wert eintrifft.

Stan­dard­ein­stel­lung für das Mess­in­ter­vall sind 300 Sekun­den, so dass also nur alle 5 Minu­ten eine neue Tem­pe­ra­tur ein­geht. Man kann es aber mit einem Kom­man­do ein­stel­len. Dafür nut­zen wir einen inject-​Knoten, der mit einem mqtt-​Ausgang auf das Topic „sonoff/​cmnd/​sonoff-​4938/​TelePeriod” ver­bun­den wird und ein­ma­lig eine Sekun­de nach Start den neu­en Inter­vall­wert in Sekun­den lie­fert. Mini­mal­wert sind 10 Sekunden.

Noch eine letz­te Ver­bes­se­rung: damit sich manu­el­les Schal­ten und die Thermostat-​Automatik nicht ins Gehe­ge kom­men, soll die Auto­ma­tik nur grei­fen, wenn der „Thermostat”-Schalter ein­ge­schal­tet ist. Den Sta­tus spei­chern wir wie­der im flow-​Kontext und wer­ten ihn beim Tem­pe­ra­tur­check aus:

if (flow.get('thermostat')) return {payload: msg.payload < flow.get('targetTemp') ? 'ON' : 'OFF'}

Der fer­ti­ge ein­fa­che Ther­mo­stat sieht im Dash­board jetzt so aus:

Den kom­plet­ten Flow könnt ihr euch gern von [7] her­un­ter­la­den. Er kann über das Piz­zamenü -> Import -> Zwi­schen­ab­la­ge impor­tiert wer­den. Es müs­sen dann nur die mqtt-​topics ent­spre­chend eurem Gerä­te­na­men geän­dert werden.

Pro­gramm­steue­rung

Etwas kom­pli­zier­ter ist eine kom­plet­te Pro­gramm­steue­rung, die ein Tem­pe­ra­tur­pro­fil abfährt und Ras­ten ein­hält. Mit Node-​Red-​Bordmitteln wür­de das ein sehr unüber­sicht­li­cher Flow wer­den. Des­we­gen habe ich einen Groß­teil der Logik in zwei Blö­cken zusammengefasst.

Zunächst brau­chen wir ein For­mu­lar, in das wir die Rast-​Temperaturen und ‑Zei­ten ein­tra­gen kön­nen. Das erle­digt ein template-​Knoten, der belie­bi­gen html‑, css- und script-​code auf­neh­men kann. Er erzeugt eine Tabel­le mit Ein­mai­schen, Abmai­schen und Ras­ten, die dyna­misch erwei­tert wer­den kann, um belie­big vie­le Ras­ten zu defi­nie­ren. Außer­dem ent­hält das tem­p­la­te die Steu­er­tas­ten zum Star­ten, Stop­pen und Pau­sie­ren des Pro­gramms sowie zum Über­sprin­gen von ein­zel­nen Schritten.

Die eigent­li­che Ablauf­steue­rung steckt als Java­script in einem function-​Knoten, der über meh­re­re Aus­gän­ge mit den rest­li­chen Ele­men­ten kom­mu­ni­zie­ren kann. Die fer­ti­ge Ober­flä­che sieht dann so aus:

Die Soft­ware ist als Beispiel-​Implementierung zu ver­ste­hen, die ihr als Grund­la­ge für ein Sys­tem nut­zen und nach euren Bedürf­nis­sen erwei­tern und ver­bes­sern könnt. In der jet­zi­gen Form ist sie sicher nicht für den Pro­duk­tiv­ein­satz geeig­net. Den kom­plet­ten Flow könnt ihr von [8] her­un­ter­la­den und belie­big ver­än­dern. Ich wür­de mich freu­en, wenn ihr eure Lösun­gen dann wie­der hier vorstellt.

Die Nut­zung zusätz­li­cher Tem­pe­ra­tur­sen­so­ren oder Schalt­re­lais ist pro­blem­los mög­lich. Es kann zum Bei­spiel ein zwei­tes TH10/​16 ein­ge­bun­den wer­den, das dann wie­der einen Sen­sor und ein Relais zur Ver­fü­gung stellt. Mit etwas mehr Auf­wand kann man auch die vor­han­de­nen zusätz­li­chen GPIO- Ein- und Aus­gän­ge der Sonoff-​Switche für Sen­so­ren, Relais oder SSDs nut­zen. Und schließ­lich ist man durch das offe­ne Sys­tem auch nicht auf nur einen Her­stel­ler ein­ge­schränkt, son­dern kann belie­bi­ge IoT-​Geräte nut­zen und mit der glei­chen Ober­flä­che steuern.

MQTT und CraftBeerPi

Wer nicht selbst pro­gram­mie­ren möch­te, kann die Sen­so­ren und Akto­ren, die er in MQTT ein­ge­rich­tet hat, auch von Manu­el Frit­schs Craft­Beer­Pi steu­ern las­sen (sie­he auch [10]). Die Soft­ware kann dabei sogar auf dem glei­chen Raspber­ry Pi wie der MQTT-​Broker lau­fen, sie stö­ren sich gegen­sei­tig nicht.

Zur Kom­mu­ni­ka­ti­on zwi­schen Craft­beer­Pi und MQTT dient das cbpi-​mqtt Plug­in. Die Doku­men­ta­ti­on dazu ist lei­der äußerst dürf­tig. Ein­zig die readme-​Datei im Github-​Paket gibt eini­ge Hin­wei­se. Zunächst muss die paho-​MQTT Biblio­thek für Python nach­in­stal­liert werden:

pip install paho-mqtt

Das eigent­li­che Plug­in ladet und instal­liert ihr über die CraftBeerPi-​Oberfläche unter Sys­tem -> Add-​On. In der inzwi­schen recht üppi­gen Plugin-​Liste fin­dest ihr es unter „MQTT­Plug­in”. Ein Click auf Down­load holt das Paket aus dem Github-​Repository und instal­liert es.

Die Ein­stel­lun­gen zur Kom­mu­ni­ka­ti­on mit dem MQTT-​Broker erle­digt ihr unter Sys­tem -> Para­me­ter. Gleich am Beginn der Lis­te fin­det ihr die neu­en Ein­trä­ge MQTT Pass­wort, Port, Ser­ver, TLS und User­na­me. Da der MQTT-​Broker auf dem glei­chen Ser­ver läuft, könnt ihr den Ser­ver Ein­trag auf local­host belas­sen. Der Port bleibt, wenn ihr ihn nicht aus­drück­lich ver­än­dert habt, eben­falls auf dem Vorgabe-​Wert von 1883. Unter User­na­me und Pass­wort tragt ihr die am Bro­ker ein­ge­stell­ten Wer­te ein. Das Pass­wort wird danach im Klar­text ange­zeigt – unschön. Wenn ihr per SSL mit dem Bro­ker kom­mu­ni­zie­ren wollt (und ihn ent­spre­chend kon­fi­gu­riert habt), muss unter TLS noch true gesetzt werden.

Jetzt steht ein Restart des Sys­tems an. Danach könnt ihr noch­mals kon­trol­lie­ren, ob das Plug­in auch gela­den ist.

In Menü Sys­tem -> Hardware-​Settings kann man jetzt unter Sen­sors respek­ti­ve Actors neue Typen aus­wäh­len: MQTT_​SENSOR und MQTTActor.

Beim Aktor muss ledig­lich das Topic ein­ge­tra­gen wer­den, in unse­rem Fal­le wäre das sonoff/​cmnd/​sonoff-​4938/​POWER.

Aller­dings sen­det das Plug­in eine fal­sche Pay­load an das Topic, näm­lich die JSON-Strings

{"state": "on"}

bezie­hungs­wei­se

{"state": "off"}

Tas­mo­ta ver­langt aber einfach

on

bezie­hungs­wei­se

off

Das muss man lei­der im Source­code ändern, da das in der Konfigurations-​Oberfläche nicht vor­ge­se­hen ist [9]. Also ändern wir in der Datei ~/craftbeerpi3/modules/plugins/MQTTPlugin/__init__.py die Zei­le 43 von

self.api.cache["mqtt"].client.publish(self.topic, payload=json.dumps({"state": "on"}), qos=2, retain=True)

auf

self.api.cache["mqtt"].client.publish(self.topic, payload="on", qos=2, retain=True)

und Zei­le 46 von

self.api.cache["mqtt"].client.publish(self.topic, payload=json.dumps({"state": "off"}), qos=2, retain=True)

auf

self.api.cache["mqtt"].client.publish(self.topic, payload="off", qos=2, retain=True)

Die Zei­len­num­mern bezie­hen sich auf die momen­tan aktu­el­le Ver­si­on vom Novem­ber 2018. Nach der Ände­rung muss Craft­Beer­Pi noch­mals neu gestar­tet werden.

Beim Sen­sor kann man im Kon­fi­gu­ra­ti­on­fens­ter neben dem Topic (bei uns: sonoff/​tele/​sonoff-​4938/​SENSOR) freund­li­cher­wei­se auch das soge­nann­te Payload-​Dictionary ange­ben, also defi­nie­ren, wie der Sensor-​Wert in der Pay­load „ver­packt” ist. Wir erin­nern uns, dass die Sensor-​Payload so aussieht:

{"Time":"2019-09-18T17:14:59","DS18B20":{"Temperature":21.8},"TempUnit":"C"}

In unse­rem Fal­le wäre das Topic also DS18B20.Temperature . Zudem kann die Ein­heit ange­ge­ben wer­de, bei uns also °C für Grad Celsius.

Sind Sen­sor und Actor defi­niert, kann man sie wie gewohnt einem Kett­le oder Fer­men­ter zuwei­sen, um dort die Tem­pe­ra­tur zu mes­sen und Hei­zung bzw. Küh­lung zu steu­ern. Am Ende kann man die MQTT-​Geräte wie jeden ande­ren direkt ange­schlos­se­nen Sen­sor oder Actor verwenden.

Klei­ner Nach­teil: der Craft­Beer­Pi schal­tet blind, das heißt: er nutzt zur Anzei­ge des Actor-​Status nicht die per MQTT bereit­ge­stell­ten rea­len Sta­tus­da­ten, son­dern nimmt ein­fach an, dass der ein­ma­lig abge­setz­te Ein­schalt­be­fehl erfolg­reich war. Das kann man ein­fach nach­voll­zie­hen, wenn man die Hei­zung manu­ell ein­schal­tet, ohne dass das End­ge­rät am Netz ist. Dann zeigt die CraftBeerPi-​Oberfläche brav eine lau­fen­de Hei­zung an, obwohl sie gar nicht erreich­bar ist.

---

Quel­len:

1. SmartHome-​Pi auf Müg­gel­land EDV-​Splitter: edv.mueggelland.de
2. Tasmota-​Software bei Gut­Hub: github.com/arendst/Sonoff-Tasmota
3. Tas­mo­ta mit VS Code fla­shen: medium.com/@tarilabs
4. Tas­mo­ta mit Atom fla­shen: ownsmarthome.de
5. Tas­mo­ta mit Raspber­ry­Pi fla­shen: heise.de/make
6. Node-​Red Home­page: nodered.org
7. Thermostat-​Flow: thermostat.json
8. Programmsteuerungs-​Flow: program.json
9. Dis­kus­si­on Craft­Beer­Pi 3.0 mit HTTP­Sen­sor und HTT­PAc­tor funzt! bei hobbybrauer.de
10. Arti­kel Brau­steue­rung Craft­Beer­Pi im brau!magazin Herbst 2018