Manchmal möchte man Geräten im lokalen Netzwerk den Internet sperren. Als Besitzer einer Fritz!Box geht das denkbar einfach auch übers SmartHome. Klar lässt sich auch direkt im WLAN-Router einiges einstellen, doch braucht man es flexibler, ist das Node „node-red-contrib-fritz“ dein Helfer.
Zuvor muss ggf. die Schnittstellen in der Fritz!Box aktiviert werden. Diese Möglichkeit findet Ihr unter Heimnetz – Netzwerk / weitere Einstellungen (FRITZ!OS: 07.29). Wie man an die nötigen Benutzerdaten kommt, wird hier auch gleich erklärt.
In der Fritz!Box muss der Zugriff für Anwendungen zugelassen werden. Dafür werden jedoch auch Benutzerdaten benötigt.
Der nötige Service über die TR-069 Schnittstelle der Fritz!Box ist urn:dslforum-org:service:X_AVM-DE_HostFilter:1 und die passende Action ist DisallowWANAccessByIP:
Über ein simples JavaScript Objekt übergibt man die benötigten Werte, dabei ist NewDisallow: 1 = Sperren, und 0 = Entsperren.
Über die Action GetWanAccessByIP kann auch der Status abgerufen werden. In diesem Fall enthält das Objekt nur die IP. Beliebige Automationen sind so denkbar. Und Kinder und Jugendliche sind von dieser Funktion sicher auch „begeistert“.
Manchmal möchte man Informationen aus dem SmartHome in der realen Welt darstellen. Gerade für Kinder oder weniger technisch versierte Familienmitglieder ist dies praktisch bis notwendig. In meinem Fall ist dies beim Warmwasserbestand der Fall. Im Winter, wenn das Warmwasser der Solarthermie nicht mehr reicht, wird das Warmwasser nur auf Bestellung erwärmt, um unnötiges Aufheizen und Abkühlen im Warmwasserspeicher zu beschränken.
Im Winter und auch in den Übergangszeiten kommt es dann aber immer wieder zu der Frage: ist Warmwasser da? Diese Frage beantwortet inzwischen eine kleine Ampel im Bad, welche sich die Information aus dem SmartHome – besser gesagt direkt aus Node-RED über eine HTTP Schnittstelle – bezieht.
Hardware
Technische Basis bildet ein Wemos D1 mini (ESP8266) mit einem RGB LED SHIELD. Dazu noch eine kleine Powerbank (ein Werbegeschenk) und ein Schalter, damit er keine Steckdose blockiert.
Der Wemos D1 mini ist extrem einsteigerfreundlich, da er direkt über MicroUSB geflasht werden kann.
Software
Für die Software nutze ich einen Arduino IDE Sketch, den ich für meine Zwecke mit der Zeit immer weiter verfeinert habe.
Und so funktioniert der Sketch grob
sobald der D1 mini Strom hat, verbindet er sich mit dem definierten WLAN, während des Verbindungsversuch blinkt die LED lila
nach der erfolgreichen Verbindung mit dem WLAN fragt er die eingestellte URL ab und bekommt als Antwort eine Zahl zwischen 1 und 3, die für eine der drei Farben der Ampel steht
die LED des Shields zeigt die entsprechende Farbe
bei Fehlern leuchtet die LED weiß
alle 30 Sekunden wird die Schnittstelle neu abgefragt und die Farbe aktualisiert
Die komplette Logik liegt beim SmartHome – der Wemos D1 mini ist bei mir ein reines Ausgabegerät. In meinem Fall bedeutet 3, dass genug Warmwasser da ist – die Ampel/LED zeigt grün. Bei 2 wird das Warmwasser langsam knapp – gelb. Und die 1 bedeutet – wer hätte es anders erwartet – eine kalte Dusche (die rote Ampel hat dich gewarnt).
Natürlich könnte man auch einen Sensorwert abfragen und die Zuordnungen von Farben zu Messwert den Wemos D1 mini machen lassen. Für mich erschien die Möglichkeit, die entsprechenden Schwellen später ohne neues Flashen der Ampel ändern zu können, komfortabler.
Schnittstelle zu Node-RED
Der Flow in Node-RED ist bei mir richtig öde, aber sei hier doch aufgrund der Vollständigkeit erwähnt. An anderer Stelle wird der Warmwasserbestand schon für Dashboard/UI ausgewertet. Daher greife ich auf die vorgefertigten Daten zurück und gebe sie nach dem Request auf das HTTP-in Node einfach aus.
Und hier mein Sketch
(Immer wenn im Code ein xx steht, musst du etwas „persönliches“ eintragen. An anderen Stellen sicher auch.)
Seit Frühjahr 2019 bastle ich an meinem SmartHome herum – und zugegeben, es ist schon ganz schön angewachsen.
Die aktuell eingesetzten technischen Komponenten und Schnittstellen Stand: 28.08.2022
Basis sind zwei Raspberry Pi 4B 2GB mit Raspberry Pi OS 32-bit.
Auf dem primären Raspberry Pi läuft das SmartHome auf Basis von ioBroker. Ein sekundärer Raspberry Pi überwacht den primären Pi, ist Node-RED-Spielwiese für Dinge, die nichts mit dem SmartHome zu tun haben und sorgt im Heimnetz für weitere Funktionen wie Etherpad, Pi-hole, Netzwerkspeicher …
ioBroker ermöglicht es, den zersplitterten SmartHome Markt zusammenzuführen, indem alle Protokolle mittels verschiedener Adapter auf eine gemeinsame Objekt-Basis runtergebrochen werden. Als Logik-Instanz kommt Node-RED zum Einsatz, über welches ich auch weitere Schnittstellen realisiere.
Aus der Auswahl der Funklösungen habe ich mich für ZigBee entschieden. Preise und Verfügbarkeiten der Komponenten erschienen mir 2019 besser als bei Z-Wave. Auch wenn OSRAM/ledvance nicht mehr alleinig auf ZigBee setzt (hier kommt vermehrt Bluetooth zum Einsatz), ist die Auswahl der Komponenten sehr reichlich und die Auswahl der Hersteller wird immer größer. Hauptsächlich setze ich Zigbee-Geräte von Xiaomi Aqara, Philips Hue und IKEA ein, zunehmend auch Sonoff und Tuya. Der Raspberry Pi kommuniziert mittels des ZigBee Sticks von Dresden Elektronik Conbee II mit den Sensoren, Schaltern, Dosen und Birnen. Mit einer Batterielaufzeit von mind. zwei Jahren (auf dem Papier, real teils länger, teils kürzer), lassen sich drahtlose Sensoren ohne viel Wartungsaufwand betreiben. WLAN-Akku-Geräte können hier aktuell nicht mithalten.
Als Schaltaktoren setze ich vor allem WLAN-Relais ein – hauptsächlich Shellys von Allterco Robotics. Als Unterputzmodule konstruiert, passen sie mit etwas Gefrickel in eine normale (tiefe) Hohlwanddose. Der Clou daran: der Schalter bleibt intakt. Genauso wie man den Verbraucher ab sofort durch das SmartHome schalten kann, wird die Betätigung des Hardware-Schalters an der Wand an den ioBroker gemeldet und kann so auch zusätzliche Funktionen auslösen. Die meisten WLAN-Aktoren arbeiten mit der OpenSource Firmware Tasmota.
Weiterhin sind inzwischen auch WLAN-Zwischenstecker in nennenswerte Zahl vorhanden, vor allem von Sonoff und Gosund. Auch purzeln einige Osram Smart+ Plugs (Zigbee) herum.
Die WLAN Komponenten kommunizieren über das Nachrichtenprotokoll MQTT mit dem ioBroker oder über die HTTP Schnittstelle direkt mit Node-RED. Über mein NodeRED Dashboad kann ich neue Firmware-Versionen von Shelly Firmware (Mongoose OS) und Tasmota ausrollen, sodass sich der Wartungsaufwand in Grenzen hält.
Neu/Ende Januar 2020
Ende Januar kam die Überwachung der Solaranlage und der Speichertemperaturen hinzu. Leider gab es hier seitens des Steuergeräts keinerlei Schnittstellen. Daher musste ich alle Werte selbst erheben: Temperaturen werden über 1-Wire-Temperatursensoren gemessen – die Laufzeit und Leistung der Solaranlage über eine WLAN-Steckdose (Gosund) mit Stromverbrauchsmesser erhoben.
Neu/Ende März 2020
In der Zwischenzeit habe ich weitere Wetterstationen aus der Nachbarschaft eingebunden. Neben Regenmenge, Windstärke und Windrichtung importiere ich Messungen bezüglich der Sonneneinstrahlung, den UV-Index und Feinstaubwerte.
Ende März nahmen die Probleme mit Zigbee überhand. Durch eine komplette Neuinstallation hoffe ich, die Probleme zu lösen. Ein Upgrade auf den Raspberry Pi 4 habe ich dabei direkt auch gemacht. Ein größeres Relais-Board ist eingetroffen, damit ich noch mehr Temperatursensoren manipulieren kann.
Neu/April 2020
Im April wurden ziemlich viele weitere Datenquellen integriert. Meteoalarm für Unwetterwarnungen, der Abfallkalender mit den Entsorgungsterminen, der Ferienkalender zur Steuerung der Weckerfunktion, die Abfahrtzeiten der lokalen Verkehrsbetriebe. Außerdem geht das Haustür-Klingeln als Signal auch direkt ins SmartHome.
Auch das Relais-Board wurde wieder fit gemacht – die Solar-Abkühlfunktion auf eine Platine gelötet und instand gesetzt und eine Anbindung der Heizung vorbereitet.
Ein neuer „Meldungen“-Bereich sammelt Informationen und Fehlermeldungen aus allen Bereichen und gibt diese prominent aus.
Oktober 2021
Da ein Aqara Bewegungsmelder unzuverlässig geworden ist, habe ich jetzt auch Bewegungsmelder von Sonoff und Tuya (beides Zigbee) im Einsatz. Durch andauernde Probleme mit dem Raspberry PI 4 habe ich ein Downgrade auf einen Raspberry Pi 3b+ gemacht.
Dezember 2021
Ein USB IR Lesekopf (Hichi) liest jetzt meinen Stromzähler aus. Die Installation war eine wahre Freude: Plug&Play in seiner besten Form. Dank 5m USB Verlängerung hängt er direkt am PI – seitens ioBroker werkelt der Adapter ioBroker.smartmeter. Es werde Licht im Dachgeschoss – dank Shelly 2.5 und Shelly i3.
Januar 2022
Für im Dach neu zugewonnene Zimmer wurden neue Sensoren (Aqara) ergänzt. Auch ein neuer Lichtwecker (Zigbee-Glühbirne) mit entsprechendem Zigbee-Taster (Ikea) wurde ergänzt. Nach längerer Zeit habe ich mich mal wieder an ESP8266-ESP32-Arduino-Basteleien versucht und neue Erfolge gefeiert. Eine kleine Ampel im Bad (Wemos D1 Mini + RGB Shield) gibt nun Auskunft über den Warmwasser-Bestand. Da der Pi 3b+ vom Backup-Prozess überfordert war, wurde ein neuer 4B beschafft und installiert.
Februar 2022
Eine smarte Steuerung und Überwachung der Konvektorheizungen im Dachgeschoss wurde realisiert.
April 2022
Die Auswertung des Stromverbrauchs wurde ausgeweitet. Verschiedene alte Flows wurden überarbeitet und optimiert. Mit der App JRW Json Response Widget (die eigentlich gar kein JSON verarbeitet) wurde ein schnelles und (aktuell) zuverlässiges Widget gebaut. Die neuen Velux Integra Solar Rolladen wurden smart gemacht.
August 2022
In der Zwischenzeit wurden weitere Datenquellen integriert, z.B. der Vertretungsplan der Schule und solar-wetter.com für eine Prognose des Photovoltaik-Ertrags. Die Daten des Wechselrichters wurden zunächst über die Cloud von Growatt eingebunden, später dann über eine modifizierte Logger-Firmware (Growatt Shine WiFi-X) direkt lokal über MQTT. Zur Maximierung des Eigenverbrauchs wurde eine HAMA Steckdosenleiste (4x Schuko + 4x USB einzeln schaltbar) auf Tasmota umgestellt. Entsprechende Flows prüfen, ob Strom „übrig“ ist und schalten die zu ladenden Geräte zu.
September 2022
Überschüssiger Strom aus der Photovoltaik-Anlage wird jetzt, wo es langsam kalt wird, vollautomatisch „verheizt“. Dafür kommen Konvektorheizer mit 500 und 750 Watt zum Einsatz, welche vom SmartHome je nach Stromüberschuss dank smarter Steckdosen zugeschaltet und abgeschaltet werden können. Dafür entsteht gerade ein – ich nenne es großspurig – Energie Management System (EMS), welches verschiedene Verbraucher verwaltet und diese dabei selbstständig, ergänzt durch Sensorwerten (Temperaturen) und Wettervorhersagen, priorisiert. Ein wenig ist hier aber noch zu tun.
Rund um Strom-Verbrauch und -Erzeugung wurden diverse Diagramme (Flot & NodeRED Dashboard) erstellt und informative Statistiken zusammengestellt. Dafür hat die Sortierung meines NodeRED Dashboards eine größere Überarbeitung erfahren.
Ein weiterer Lichtwecker wurde schnell zusammenkopiert. Ist ja nichts neues mehr. Morgens hat das SmartHome mit vier meist weitgehend parallel laufenden Lichtweckerprozessen nun gut zu tun. Überfordern tut das den Raspberry Pi 4b 2GB aber nicht.
Seit ein paar Wochen habe ich Solar-Rollos (VELUX INTEGRA® Solar-Rollladen SSL) auf meinen Dachfenstern. Für jeden, der mit dem Gedanken spielt: die Nachrüstung ist sehr einfach, komplett von innen zu erledigen und geht sehr schnell.
Das Problem
Schon vorher hatte ich mich mit den Möglichkeiten zur Einbindung ins SmartHome beschäfitgt und es wurmte mich, dass der Weg wahrscheinlich sehr steinig/proprietär werden würde. Zwar existiert mit dem KLF 200 quasi ein Konnektor, aber sowohl der Preis, als auch das zusätzliche Gerät (Sicherheit, Stromverbrauch) schreckte mich ab.
An das verschlüsselte Funkprotokoll kommt man meinen Recherchen zufolge aktuell auch nicht ran und so blieb als einzige Möglichkeit, über die original Fernbedienungen zu gehen. Die Idee, die Schaltimpulse mit ein wenig Lötarbeit einem Relaisboard anzuvertrauen, habe ich aus einem Forum-Thread zu gleicher Problematik. Doch die mitgelieferten Fernbedienungen zu verwenden, widersprach meinem Credo (alles muss auch ohne Smartphone funktionieren). Gut, dass man Ersatzfernbedienungen kaufen kann. Doch für drei Fenster drei weitere Fernbedienungen zu kaufen und diese über (drei Tasten mal drei Fernbedienungen gleich) neun Relais zu steuern – das erschien mir dann doch etwas übertrieben.
Die Lösung
Dann stolperte ich durch Zufall über die Möglichkeit, mehrere Rollos auf eine Fernbedienung anzulernen und somit eine Gruppen-Fernbedienung zu erhalten. Auch wenn die individuelle Steuerung durch das SmartHome damit nicht möglich ist, entsprach diese Lösung doch meinen Zielen, die sommerliche Abschattung sicherstellen und die Halbstarken aus dem Bett schmeißen zu können. Eine individuelle Steuerung ist ja weiterhin über die mitgelieferten Fernbedienungen möglich.
Löten ist bisher nicht so meine Welt und die Schalter sind dazu auch noch ganzschön winzig, dennoch waren die Versuche schnell von Erfolg gekrönt. Ein Trigger-Node (500ms) in Node-RED erledigt den Rest.
Das Relaisboard habe ich kurzerhand zum Schutz der filigranen Lötstellen auf die Fernbedienung geklebt.
Geisterfahrten verhindern
Anfangs hatte ich überlegt, nur die Knöpfe „AUF“ und „ZU“ anzuschließen. Doch die Knöpfe sind quasi Toggle-Buttons: Ein kurzer Schaltimpuls reicht, um das Rollo vollständig zu öffnen/schließen – es sei denn, man drückt vorher STOP. Und da Relaisboards beim Neustart des Raspberry Pi oder von Node-RED dazu neigen, sich zu initialisieren und dabei mal munter zu klickern, wollte ich verhindern, dass dadurch die Rollos sich von Geisterhand öffnen/schließen. Dies erreiche ich, indem ich eine Sekunde nach Start/Deploy ein Stop an die Rollos sende.
Offen oder geschlossen?
Diese Lösung ermöglicht natürlich keinen Rückschluss über den aktuellen Status der Rollos. Hier behelfe ich mich mit einem Zigbee Xiaomi Mijia Helligkeitssensor (GZCGQ01LM). Nach Ermittlung der richtigen Schwellenwerte erlaubt dieser zumindest tagsüber recht zuverlässige Rückschlüsse über den Status des Rollos, an dessen Fenster der Sensor angebracht ist.
Doppelpack: Lichtsensor (links) und Fenster-Magnetkontakt-Sensor (rechts)
Inzwischen haben sich jede Menge Zigbee-Sensoren angesammelt. Diese halten mit einer Batterie echt lange durch. Viele zwei Jahre und mehr. Trotzdem geht die Batterie irgendwann mal zur Neige und davon möchte ich nicht überrascht werden. Also habe ich einen kleinen Flow in Node-RED, welcher die Akkustände jeden Tag einmal prüft und mich bei Bedarf benachrichtigt.
Um nicht für jeden Sensor neue Nodes ergänzen zu müssen, nutze ich die Möglichkeit, Nachrichten mit node.send(msg);asynchron zu versenden.
Sensoren zentral hinterlegen und einzeln durchgehen
Im Array zigbeesensoren sind einfach die abzufragenden Sensornummern (der ioBroker-Objekte) hinterlegt. Die forEach-Schleife sorgt dafür, dass das ganze Array durchgegangen wird und das richtige msg.topic für jeden Sensor gebaut und als Nachricht abgeschickt wird. So kann über „IoB read value“ jeder einzelne Batteriestand ausgelesen und in der Funktion „Batterie leer?“ geprüft werden. Wie gewohnt erstellt „UI Notification“ im Bedarfsfall die Benachrichtigung und leitet sie an das zentrale Benachrichtigungssystem.
Einen ähnlichen Aufbau kann man natürlich auch für beliebige andere Objekte nutzen, die vielfach ausgewertet werden müssen.
Nach knapp drei Jahren SmartHome-Spielereien zeigen sich bei den ein oder anderen Sachen erste Ermüdungserscheinungen oder technischen Defekte.
Hier eine Auflistung der bisherigen Defekte: (Stand 27.01.2022)
zwei Aqara Motion Sensor (RTCGQ11LM) Nach ungefähr zwei Jahren hörten sie von einem auf den anderen Tag auf, verlässlich Bewegungen zu erkennen. (zwei weitere habe ich noch im Einsatz)
ein Aqara Mini Schalter Kam schon defekt an, ließ sich nicht anlernen. Geld wurde erstattet. (aktuell ein weiterer im Einsatz)
ein Shelly 2.5 Nach knapp zwei Jahr in der Wand fing er an, ununterbrochen ein Relais umzuschalten. Mit dem WLAN verband er sich auch nicht mehr. Allterco Robotics war kulant und ersetzte ihn. (9 weitere habe ich im Einsatz)
ein Raspberry Pi 4B 2GB Aus unerklärlichen Gründen hielt er zuletzt nur noch wenige Stunden ohne einfrieren durch. Die selbe SD-Karte in einem 3B+ läuft problemlos. Selbst bei einem neu installierten OS auf neuer SD-Karte im Leerlauf konnte ich das Fehlverhalten des 4er beobachten. (ein weiterer 4B läuft problemlos)
Um Statistiken über verschiedene WordPress-Websites zu erheben, nutze ich das datenschutzfreundliche Plugin „Koko Analytics“. Leider hat dieses Plugin, wie viele andere auch, keine Schnittstelle, um auf die Statistiken anderweitig zuzugreifen. Möchte man dies trotzdem, um sie zum Beispiel in einem SmartHome Dashboard auszugeben, muss man sich quasi selbst eine kleine Schnittstelle basteln, und die erwünschten Daten direkt aus der Koko-MySQL-Datenbank laden.
Hier mein PHP-Code für die beiden Standardwerte Visitors & Page-Views der letzten 28 Tage – mit Ausgabe als JSON.
<?php
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
define('DB_NAME', '____DB_NAME____');
define('DB_USER', '____DB_USER____');
define('DB_PASSWORD', '____DB_PASSWORD____');
define('DB_HOST', 'localhost');
$mysqli = new mysqli(DB_HOST,DB_USER,DB_PASSWORD,DB_NAME);
$return = $mysqli->query("SELECT sum(visitors),sum(pageviews) FROM (SELECT visitors,pageviews FROM ____DB_PREFIX_____koko_analytics_site_stats ORDER BY date DESC LIMIT 28) AS subquery;");
$row = $return->fetch_array(MYSQLI_ASSOC);
echo json_encode(array("visitors"=>$row["sum(visitors)"], "pageviews"=>$row["sum(pageviews)"]));
$return->close();
$mysqli->close();
?>
Das Skript muss dafür auf die Datenbank der WordPress-Instanz zugreifen können – klar. Seitens Node-RED ist es nur ein kleiner HTTP-Request. Eine Authentifizierung für den Zugriff lässt sich natürlich auch entsprechend ergänzen.
Alle Angaben ohne Gewähr. Alle Ideen, die aus diesem Artikel entstehen, auf eigene Gefahr. Die beschriebenen Möglichkeiten sollte man als Mieter gar nicht erst lesen, oder direkt wieder vergessen.
Die Steuergerät meiner Gastherme und der Solarpumpe sind dumm. Natürlich kann man einiges einstellen, aber Schnittstellen, um sie smart zu machen, gibt es nicht. Zwar könnte ich für absurde Beträge zumindest der Gastherme mit einem Zusatzgerät ein wenig Vernetzung einhauchen, aber beim Blick auf die Kosten verzichtete ich darauf. Stattdessen trickse ich die Steuergeräte über ihre Sensoren einfach aus.
Was will ich steuern?
Am Anfang stand die Sorge um die Solarthermie-Anlage. Im Hochsommer bringt sie enorme Erträge und heizt den Warmwasserspeicher (leider unterdimensioniert) so weit und so schnell auf, dass die Gefahr besteht, dass sie in praller Mittagssonne aufgrund der nötigen Temperaturbegrenzung aufhört zu arbeiten, die Solarflüssigkeit sich nicht mehr bewegt und anfängt zu kochen. Das Steuergerät hat keine Funktion, dem zu begegnen. Also wollte ich die Möglichkeit, die Solaranlage bei Bedarf in der Nacht laufen zu lassen, um den Speicher abzukühlen, damit es am nächsten Tag nicht zu Problemen kommt.
Weiter ging es, als ich eigene Sensoren am Warmwasserspeicher hatte, und so in schönen Charts mit ansehen konnte, wie schnell das warme Wasser auch ohne Nutzung wieder kalt wird. Dies galt es effektiver zu gestalten und so wollte ich ein Bestellsystem für Warmwasser aufbauen, welches Komfort und Energieeffizienz unter einen Hut bringt. Das Bestellsystem benötigen wir sowieso eigentlich nur im Winter, weil die überwiegende andere Zeit im Jahr genug Warmwasser durch die Solarthermie-Anlage zusammenkommt.
Wie lässt sich die Steuerung umsetzen? (Theorie)
Die Steuerungen von Therme und Pumpe basiert auf Sensorwerten. Anhand dieser Sensorwerte werden bestimmte konfigurierbare Automatismen ausgelöst. Durch die Manipulation der Sensorwerte kann ich also bestimmen, wann ein Automatismus ausgelöst werden soll, und wann nicht. Voraussetzung dafür ist, dass ich die wahren Sensorwerte kenne, damit ich selbst den Überblick habe.
Da es mir nicht möglich war, die Sensorwerte aus den Hausgeräten auszulesen, habe ich eigene Sensoren (DS18B20) am Speicher und der Solarstation ergänzt und mit den Sensoren der Hausgeräte entsprechend abgeglichen.
Beispiel Solarthermie Steuerung: Die Solarthermie-Steuerung vergleicht die Temperatur im Speicher mit der Temperatur auf dem Dach. Ist die Temperatur auf dem Dach um ein konfiguierbares Offset höher als die im Speicher, startet die Steuerung die Pumpe. Wenn ich also mitten in der Nacht sage: „Hallo Steuerung, im Speicher sind es nur 5°C“, dann ist im Hochsommer die Temperatur auf dem Dach definitiv höher und die Solarpumpe bringt fleißig überschüssige Wärme zurück auf das Dach.
Beispiel Gastherme / Warmwasser: Die Steuerung der Gastherme hält den Speicher in einem konfigurierbaren Zeitraum auf einer gewissen Temperatur. Wenn ich also dem Steuergerät vorspiegele, dass die Speichertemperatur über der Zieltemperatur liegt, sieht sie keinen Handlungsbedarf. Schalte ich auf den realen Sensor um, greift wieder die eingebaute Steuerung und das Aufheizen des Speichers kann beginnen.
Wie lässt sich die Steuerung in der Praxis umsetzen?
Für die technischen Umsetzung muss man sich erst einmal vergegenwärtigen, wie ein Temperatursensor technisch funktioniert. Je nach Temperatur liefert der Sensor einen gewissen elektrischen Widerstand. Dieser unterscheidet sich von Modell zu Modell. Weiter hilft hier das Handbuch des Hausgeräts, in dessen Anhang meist eine Tabelle der Widerstände und zugehörigen Temperaturen zu finden ist. Teils muss man dafür das Installateurs-Handbuch bemühen, aber das findet man auch meist online.
Widerstände des Speichertemperaturfühlers einer Buderus GB172-14
Der erste Schritt ist also den passenden Widerstand für die beabsichtigte Temperatur zu besorgen – natürlich müssen es dabei nicht die exakten Werte aus der Tabelle sein, da es egal ist, ob es bspws. 57,0 oder 57,2°C sind. Der zweite Schritt bringt ein wenig Nervenkitzel ins Spiel, wenn man das Sensorkabel des Hausgeräts möglichst mit gut Luft in beide Richtungen einfach durchschneidet (Gerät vorher abschalten!) – im Ernstfall beeinflusst eine Lüsterklemme den Widerstand/Sensorwert aber auch nicht.
Mit einem herkömmlichen Relaisboard an den GPIO des Raspberry PI richtig verkabelt, hat man dann die Möglichkeit, zwischen echtem Sensorwert und vorbestimmten Sensorwert hin und her zu schalten. Meine Geräte stören sich daran nicht. Nach ausgiebigen Tests landete das ganze dann noch auf einer Platine.
Links das Relaisboard, rechts die Platine mit den Anschlüssen für die Sensorkabel und den Widerständen.
Dashboard / UI
Im Winter bemühen wir also jetzt das Dashboard, wenn es um Warmwasser geht.
Warmwasser ist alleTherme heizt (Flamme oben rechts)Warmwasser ist da
Im Dashboard habe ich nach anfänglich komplizierten Überlegungen die Steuerelemente sehr simplifiziert. Für Heute, Morgen und Übermorgen gibt es je die Möglichkeit, Warmwasser für den Morgen, Mittag oder Abend im Voraus zu bestellen. Um Mittnacht rutscht natürlich Morgen ➡ Heute und Übermorgen ➡ Morgen. Weiterhin gibt es neben der aktuellen Speichertemperatur auch eine Bewertung der Lage, inkl. Prognose, wie lange der aktuelle Warmwasserbestand noch für eine ausgiebige Dusche reicht. Für die Berechnung der Prognose habe ich Langzeitdaten über die Abkühlung des Speichers erhoben und ausgewertet.
„Nur halb aufheizen“ kommt zum Einsatz, wenn vrstl. nur wenig Warmwasser benötigt wird. Hier schaltet das Relais schon vor erreichen der Zieltemperatur auf den Fake-Wert um und die Therme sieht ihre Arbeit als erledigt an und hört auf zu heizen.
Auch kann man „Warmwasser jetzt!“ bestellen, dann dauert es durch die Leistung der Gastherme nur gut fünf Minuten, bis man duschen kann. Hat man eine trägere Wärmeerzeugung, ist das natürlich bei allen Überlegungen zu berücksichtigen.
Tipps / Warnhinweise
Die Verkabelung am Relais sollte so erfolgen, dass im Fehlerfall (Raspberry Pi kaputt, Relaisboard ohne Strom, etc.) der reale Wert an das Hausgerät gemeldet wird. So kann man zur Not auch mit „Stecker ziehen“ beim Raspberry Pi den „Normalzustand“ wiederherstellen.
Man sollte versuchen, alle Eventualitäten zu durchdenken. Hat man zum Beispiel eine thermische Desinfektion in seiner Warmwasserbereitung aktiviert, hat man neben dem beeinflussten Sensor-Trigger auch einen zeitlichen Trigger, der das Heizen startet. Hat die Therme in diesem Fall keine realen Speichertemperaturen, heizt sie im Ernstfall ohne Ende.
Wiederum ist es ratsam, einmal in der Woche gut durchzuheizen, um Kontaminationen zu verhindern.
Man sollte die Speichertemperaturen überwachen und mit entsprechenden Regeln reagieren. Steigt die Temperatur im Speicher zu stark an, wird bei mir z.B. automatisch der korrekte Sensorwert der Gastherme bereitgestellt.
Es kann günstig sein, einen zweiten Indikator zur Überwachung mit einzubeziehen, zum Beispiel einen Zwischenstecker mit Power Measurement. So kann man am Stromverbrauch des Gerätes ablesen, wie der Status des Hausgerätes ist und ob Steuerbefehle ausgeführt werden.
Was hat es mit dem Type des „ioBroker out“ – Nodes in Node-RED auf sich?
value? command? Was wie wo?
Nachdem ich in den Anfängen meiner SmartHome-Experimente festgestellt hatte, dass Adapter wie ioBroker.deconz oder ioBroker.sonoff die Befehle aus Node-RED nur ausführen, wenn man den Type auf „command“ stellt, machte ich das bis jetzt eigentlich immer so. Dass die Objekte im ioBroker dann teils Rot waren, ignorierte ich, funktionierte ja. Nach einigen Recherchen – ausgelöst durch einen Kommentar zu einem anderen Blogbeitrag – weiß ich jetzt, dass dies nicht unbedingt richtig war.
Was macht der Type im Node „ioBroker out“?
Der Type setzt das ioBroker Attribut ACK (ACKnowledgement = Bestätigung). Dabei steht „value“ für ACK = true, und „command“ für ACK = false.
Warum sollte man ack = false / command setzen?
Viele Adapter verarbeiten Änderungen von Adapter-States, die von anderen Adaptern geändert wurden, nur dann, wenn diese ACK=false haben (auf der Admin-Seite rot dargestellt).
Also werden Werte beispielsweise nur an ein Gerät geschickt, wenn ACK = false ist. Dieses quittiert den Empfang des Befehls auf ihre protokollspezifische Weise, was dann durch ein ACK = true im ioBroker vermerkt wird.
Wann sollte man ack = true / value setzen?
Nutzt man ein State/Objekt nur zum Speichern von Werten (zum Beispiel in 0_userdata), so nutzt man Type = value. Das mache ich jetzt auch häufiger.
Übrigens: In Node-RED hat man im „ioBroker in“ – Node die Wahl, ob nur ACK = true verarbeitet werden soll.
Okay, ich gebe zu: ich bin ein bisschen begeistert. Daher hier erstmal schnell der Disclaimer.
Die nachfolgend beschriebene Methode, einen Shelly auf eine andere Firmware zu flashen, basiert auf einer Fremd-Firmware, auf welche ich keinen Einfluss habe.Die Methode kann deinen Shelly auch kaputt machen. Dein eigenes Risiko.
Was?
Diese Möglichkeit, Tasmota auf Shelly Geräte zu flashen, funktioniert aktuell NICHT für Shelly Plus (ESP32) Geräte. Leider wurde die Firmware seit Januar 2021 nicht weiterentwickelt, sodass es fraglich ist, ob eine Unterstützung für weitere Geräte noch folgt.
Aktuell werden unterstützt:
Shelly 1
Shelly 1PM
Shelly Plug S
Shelly 2
Shelly 2.5
Shelly RGBW2 (color mode, latest firmware needed)
Shelly Dimmer 1
Shelly Dimmer 2
Shelly EM
Shelly Bulb
Shelly Vintage
Shelly Plug US
Shelly Duo
Shelly H&T
Shelly i3
Shelly 1L
Shelly Plug 2
Shelly Uni
Shelly Duo RGBW
Warum?
Ich betreibe meine Shelly 2.5 eigentlich alle mit der original Firmware. (warum steht hier) So hielt ich es auch mit einen Shelly 2.5, den ich nicht als Rolladen-Steuerung einsetze, sondern für einen Doppel-Lichtschalter. Einmal in der Wand verbaut, traten Probleme auf, die ich mit der Shelly Firmware nicht lösen konnte. Außerdem funktioniert das MQTT der Shelly-Firmware nicht mit dem ioBroker Sonoff Adapter, den ich für die Shellies nutze. Und ich will den ioBroker ja schlank halten. Ich ärgerte mich also kräftig, den Shelly nicht vor dem Einbau auf Tasmota umgestellt zu haben. Shelly ausbauen, flashen und wieder einbauen – das muss doch leichter gehen. Und: es geht.
Wie?
Ist der Shelly bereits eingerichtet und mit dem eigenen WLAN Shelly verbunden, geht es verboten einfach. Es gibt eine Mini-Firmware, welche kompatibel zu Mongoose OS (darauf basiert die Shelly-Firmware) ist, dann aber Tasmota (oder eine andere IOT-Firmware) installiert.
Ist die Magie abgeschlossen, spannt das Tasmota wie immer ein eigenes WLAN auf und lässt sich darüber konfigurieren/mit dem eigenen WLAN verbinden. Installiert wird die englische Tasmota Version, was sich über ein OTA-Firmware-Upgrade-Funktion in Tasmota aber problemlos auch auf die deutsche oder jede andere Version umstellen lässt. (http://ota.tasmota.com/tasmota/)
Zugegeben: Ich war etwas aufgeregt, da die Erfahrungsberichte in den Issues nicht unbedingt so positiv sind. Bei mir hat es geklappt: ich drücke euch die Daumen.
