Was wäre ein Smarthome-System ohne Automatisierung? Verbinden wir also die Fenstersensoren mit den Thermostaten, visualisieren mit dem NodeRed-Dashboard unsere Temeperatur- und Luftfeuchtigkeitsdaten und Berechnen den Taupunkt.
In NodeRed geht es um Nachrichten (Messages), die durch verschiedene Knotenpunkte (Nodes) einen Weg (Flow) durchlaufen und auf diesem Weg verändert und genutzt werden, um andere Dinge anzustoßen. Was liegt also in einem ersten Schritt beim Automatisieren eines (Gemeinde)Hauses näher, als bei einer Fensteröffnung die Heizkörper auszuschalten? (Oder ist das Unsinn? Wenn du ein Energieberater bist, gib mir gern Rückmeldung, ab wie viel Minuten Fensteröffnung sich so etwas lohnt, oder wie auch immer das am effizientesten ist.) Wir nehmen uns für den Anfang einen Zigbee2mqtt-Node den wir für einen Fenstersensor konfigurieren. Nun müssen wir die Nachricht entweder weiter nutzen, wenn das Fenster offen ist, um das Thermostat auszuschalten, oder die Nachricht ins Leere Laufen lassen, wenn das Fenster geschlossen ist. Dafür gibt es den switch-Node. Der gibt uns verschiedene Verbindungspunkte, wenn wir ihn mit verschiedenen Möglichkeiten konfigurieren. In unserem Fall muss er uns zwei Möglichkeiten geben weiter zu machen. Der Sensor gibt uns einen Boolean-Wert aus: true für ein geschlossenes Fenster und false für ein geöffnetes Fenster. Entsprechend konfigurieren wir den Switch.
Wenn man mit der Maus über den Verbindungspunkt hovert, kann man auch ohne Konfigurationsfenster sehen, wofür er da ist. Wir machen natürlich erstmal mit dem unteren Verbindungspunkt weiter, den der ist false und sagt uns, dass das Fenster offen ist.
Thermostat ansprechen
Jetzt ist die Frage, was wir mit der Information „Fenster 1 ist offen“ alles machen. Heizkörper runterregeln machen wir auf jeden Fall. Wir können uns das aber auch in einer Übersicht (im sogenannten Dashboard) anzeigen lassen, wir können eine globale Variable setzen, wir können auch eine mqtt-Nachricht an ein externes Display oder eine LED schicken, u.v.m. Schauen wir uns zuerst die beiden ersten Möglichkeiten an. Um das Thermostat zu schalten nehmen wir uns einen mqtt-out Node. (In den z2m-Nodes habe ich keine Möglichkeit gefunden.) Dort tragen wir als topic zigbee2mqtt/thermostat1/set ein und speichern. Bevor wir ihn jetzt mit unserem angefangenen Flow verbinden, müssen wir uns entscheiden, was mit dem Thermostat passieren soll (und was er kann) und brauchen dazu noch einen weiteren Node dazwischen. Je nach Thermostat kann man entweder auf einen Fenstermodus zurückgreifen, oder auf einen System-Modus oder man muss direkt an der Themperatur etwas ändern. Auch hier gilt: Die Gerätedatenbank auf zigbee2mqtt.io sagt euch, was das Thermostat kann. Entsprechend muss dann der Payload angepasst werden. das tun wir mit dem Node change. Dort setzen wir den msg.payload auf {"open_window": "ON"} bzw. {"system_mode":"off"} bzw. {"current_heating_setpoint": 5} für 5°C. Jetzt verbinden wir noch den unteren Verbindungspunkt (der angesteuer wird, wenn das Fenster offen bzw. der Payload false ist) mit dem change-Node und diesen mit dem mqtt-out Node, der jetzt zigbee2mqtt/thermostat1/set heißen sollte. (Zu guter letzt das Deploy nicht vergessen! Oder du macht direkt weiter.)
Das Entgegengesetzte sollten wir tun, wenn das Fenster wieder geschlossen wird/ist. Deshalb holen wir uns wieder einen change-Node und ändern hier den msg.payload auf {"open_window": "OFF"} bzw. {"system_mode":"auto"} bzw. {"current_heating_setpoint": 20} für 20°C. Jetzt verbinden wir den oberen Verbindungspunkt des switch-Nodes (der angesteuer wird, wenn das Fenster geschlossen bzw. der Payload true ist) mit dem neuen change-Node und diesen mit dem selben mqtt-out Node wir eben, der ja jetzt zigbee2mqtt/thermostat1/set heißt. Und natürlich wieder ein „Deploy“, um das ganze zu speichern und zu aktivieren. Herzlichen Glückwunsch, unsere erste Automatisierung ist gebaut. Das kann man jetzt beliebig komplexer machen: Warten, wenn das Fenster zu geht (mit dem delay Node), eine LED am Raspberry Pi ein- und ausschalten (um auch im Wohnzimmer den Überblick zu haben, welche Fenster gerade offen sind – mit dem node-red-node-pi-gpio Node-Paket), oder eben eine Übersicht auf einer (netzwerkinternen) Website bauen:
Bedienoberfläche bauen
Mit dem das letzte Mal schon installierten Node-Paket node-red-dashboard kannst du eine Bedien- und Kontrolloberfläche bauen. Für den Anfang lassen wir uns den Status vom Fenster 1 anzeigen. Dazu holen wir uns den Node text in der Nodekategorie Dashboard auf die Arbeitsfläche. In der Konfiguration erstellen wir erst eine Gruppe und einen Tab. (So ungefähr: Ein Seitenbereich und eine Seite. Ein Tab kann mehrere Gruppen beinhalten, das Dashboard selbst kann aus mehreren Tabs bestehen, die in einem Menü anwählbar sind.) Nachdem Guppe und Tab erstellt sind, legst du ein Beschriftung (Label) fest, das Value Format kann für unsere Zwecke {{msg.payload}} bleiben und das Design ist Geschmackssache. Wer CSS besser schreiben kann als ich, kann sich hier richtig austoben. Den text-Node verbinden wir jetzt mit dem Zigbee2mqtt-Node. Nach einem Deploy können wir uns das Ergebnis auf dem Dahsboard ansehen: http://deine-Adresse: 1880/ui
Schön ist das aber noch nicht. Fenster 1 true ist jetzt nur so semi aussagekräftig… Aber du hast schon das Handwerkszeug, um daraus ein „Fenster 1 ist zu“ zu machen (mit dem change Node).
Mehr Visuelles
Weiter geht es mit der Temperatur, die wir uns im Dashboard anzeigen lassen können. Letztlich reichen uns die Zigbee2mqtt-Nodes, die uns direkt die Temperatur ausgeben, die wir dann alle mit einem chart-Node verbinden. Jetzt bist du gefragt: Welche Daten brauchst du wirklich? Welche Daten sind sinnvoll in einem Diagramm anzeigbar? Willst du eine Legende? Welcher Zeitraum soll angezeigt werden? Wenn du einfach nur wie im Screenshot acht Semsoren in ein Diagramm packst, wird es einfach unübersichtlich und man bestenfalls einzelne Fensteröffnungen erkennen. Es ist also eine geschickte Auswahl von Daten wichtig, ebenso wie ein wenig Einsatz vom change-Node, um die Benennungen in der Legende und an den Datenpunkten zu ändern (es wird das msg.topic angezeigt). Genau parallel läuft die Anzeige von Luftfeuchtigkeit. Je nach Aufgabenbereich von deinem Smarthome kann es aber durchaus sinnvoller sein, gar nicht mehrere Temeperaturen in ein Diagramm zu schreiben und mehrere Luftfeuchtigkeiten in ein anderes Diagramm schreiben zu lassen, sondern lieber aus beiden Daten Schlüsse zu ziehen.
Taupunkt
Der Taupunkt ist eine Größe, die angibt, ab wann die Luftfeuchtigkeit zu kondensieren beginnt. (So in etwa…) Dieser Taupunmkt hilft also dabei zu schauen, bis wohin wir eine Raumtemperatur maximal absenken können, bevor die Luftfeuchtigkeit anfängt zu kondensieren und damit dem Schimmel eine gute Basis gibt. Es ist zwar um Einiges komplizierter (Zeit spielt eine Rolle*, der Sensor muss am kältesten und feuchtesten Punkt des Raumes platziert werden,…), aber wenn man die Raumtemperatur immer eine ordentliche Spanne vom Taupunkt entfernt hält, hat man zumindest eine einigermaßen sichere Basis geschaffen.
Erstelle einen function-Node uns kopiere folgendes hinein:
function dewPoint(temp1, feuchte2) {
//falls Datentypen ein Problem sind folgende twei Zeilen auskommentieren
// if (typeof temp1 === 'string') temp1 = parseFloat(temp1)
// if (typeof feuchte2 === 'string') feuchte2 = parseFloat(feuchte2)
var a = 17.271;
var b = 237.7;
var temp = Math.log(feuchte2 * 0.01) + ((a * temp1) / (b + temp1));
var Td = (b * temp) / (a - temp);
return Td.toFixed(1);
// oder falls du lieber einen aufgerundeten (weil in diesem Fall
// sichereren) Integer haben möchtest:
// return Math.ceil(Td);
}
const temp1 = msg.payload.temperature;
const feuchte2 = msg.payload.humidity;
const taupunkt = dewPoint(temp1, feuchte2);
msg.payload = taupunkt;
// Falls du lieber ein Objekt mit allen drei Werten haben möchtest:
// msg.payload = { dewpoint: taupunkt, temperature: temp1, humidity: feuchte2}
// oder noch ein Topic setzen willst:
// msg.topic = "Konfiraum";
return msg;Exkurs: Kirchgebäude
Gerade in Kirchgebäuden ist die Heizung oft zu träge, um den Raum immer weit genug vom Taupunkt entfernt zu heizen, aber Schimmel entsteht nicht innerhalb von Minuten. Daneben ist es gerade in historischen Kirchen gut, nicht nur auf den Taupunkt, sondern auch generell auf die Feuchtigkeit zu achten und ständig an verschiedenen Stellen zu messen (und dann bloß nicht mit einem Durchschnittswert arbeiten!). Ansonsten kann die Wetterseite zu feucht sein, es werden Maßnahmen getroffen, um die Luftfeuchtigkeit aus dem ganzen Raum zu bringen, dabei wird auf der Sonnenseite das Holz rissig, weil zu wenig Luftfeuchtigkeit in diesem Raumteil ist. Diese Geschichte ist real passiert – sowohl die Durchschnittsermittlung (von einer Heizungsanlage eines namenhaften Herstellers, der schlicht auf andere Gebäudetypen spezialisiert ist), wie auch die unterschiedlichen Feutchtigkeiten in einem Raum.
Generell kommt bei so großen Räumen hinzu, dass die Heizung extrem teuer sein kann. Bei mehreren hundert Euro für einen warmen Abend in einer großen historischen Kirche sollten sich Gemeinden genau überlegen wie und wann sie heizen. Dummerweise ist eine Möglichkeit, den Taupunkt niedrig zu halten, die Temperatur höher zu machen, weil warme Luft die Feuchtigkeit besser aufnimmt. Um Schimmel zu vermeiden, kann es aber die deutlich bessere und günstigere Methode sein, Luftentfeuchter an den zu feuchten Stellen einzusetzen. Das kann in extremfällen den Faktor 10 bei den Kosten ausmachen (die Anschaffungskosten für die Luftentfeuchter mal außen vor gelassen). Dazu sollten dann pragmatische Lösungen kommen, wenn es mal zu trocken wird (es gibt in Gemeindehäusern immer mal wieder Wäsche, die getrocknet werden muss).
Zuletzt ist eine gute Überwachung gold wert! Auch deshalb habe ich mich an dieses Projekt gewagt. Nur wer tatsächlich Messwerte und Verbrauchswerte hat, kann etwas verbessern. Nur so kann auffallen, dass die Kirche über die Woche zu warm gehalten wird, weil der eingebaute Temperaturfühler streikt. Nur so kann erkannt werden, dass ein manuelles Heizungstermostat die Heizung nicht mehr abriegelt, wenn man es auf Null stellt. Nur so sieht man, ob der Eintrag der Feuchtigkeit an einem regnerischen Sonntag durch Schirme und nasse Jacken gefährlich ist, oder sich so schnell verflüchtigt, dass sich erst gar kein Schimmel bilden kann. Nur so können unnötige Stromverbraucher gefunden werden, verwirrte Bewegungsmelder richtig eingestellt und laufende Wasserhähne schnell erkann werden. Und ja, auch diese Beispiele sind alle real…
SmartGemeindehaus Artikel:
I-Installation | II-Verbindungen schaffen (und Hardware) | III-Erste Automatisierung |
IV – Speichern + Visualisieren
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.