Der aktuelle Aufbau

Dieser Artikel wird fortlaufend aktualisiert.

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.

September 2023

Bedingt durch einen neuen Wechselrichter musste ich mich mit der lokalen Integration eines Hoymiles HMS-800w 2t beschäftigen. Dank des hms-mqtt-publisher ging das dann schnell besser als gedacht.

Dezember 2023

Der unterstützende Pi, der nebenbei auch allerlei andere Aufgaben im Heimnetz übernimmt, wurde auf einen Pi 5 geupgraded. Eine aufwändigere Arbeit als erwartet.

Mai 2024

Neue Zigbee-Sensoren kamen in den letzten Monaten hinzu. Dabei bin ich tiefer in die Funktionalität von Zigbee und Deconz eingetaucht. Leider streiken die Wassersensoren gerade – ich hoffe das klärt sich …

Juni 2024

Mein EMS (Energie Management System) ist inzwischen erwachsen geworden. Viel Arbeit floss in den letzten Monaten hinein. Inzwischen können Verbraucher flexibel über das Frontend ergänzt, bearbeitet, aktiviert und deaktiviert werden.

Mehrere Geräte können gleichzeitig (automatisch) geschaltet werden. Dabei wird immer die optimale Kombination aus Geräten erhoben, welche das Stromangebot optimal ausnutzt.

Das Einschalten und Ausschalten der Geräte richtet sich nach diversen Bedingungen wie Temperaturen, Jahreszeiten, Tageszeiten, Schonzeiten, Mindestlaufzeiten, Pardonzeiträumen, Prioritäten …

Auf Wunsch wird ein abstufbar-umfangreiches Log geschrieben, welches alle Entscheidungen transparent macht – und das Debugging enorm erleichtert. Ebenso werden Statistiken geführt, wie z.B. Verbrauch und Einschalthäufigkeiten.

Den Wifi-Tasmota IR-Lesekopf (Hichi) per HTTP Request auslesen

Der IR-Lesekopf für den Stromzähler von Hichi ist seit Jahren eine etablierte Lösung für das Auslesen des Stromzählers. Schon lange habe ich selbst den USB-Lesekopf im Einsatz und er läuft extrem zuverlässig.

Einem Freund hatte ich kurzerhand die WLAN-Variante mit ESP-01 geschenkt, ohne jedoch auf die Limitierung zu achten, dass ein sinnvolles Auslesen nur mit SmartHome über MQTT (Tasmota als MQTT Client) möglich ist. Also musste etwas Bastelei her, um auch ohne MQTT Broker bequem an die Daten zu kommen.

Für die Einrichtung des Tasmota auf dem Hichi gibt es sehr gute Anleitungen im Netz, die will ich nicht wiederkäuen. Dazu gibt es für eigentliche alle Stromzähler im Tasmota Wiki das passende Script.

Das Auslesen ohne SmartHome

Um ohne SmartHome bequem an die Daten zu kommen, ist MQTT eine schlechte Option. Gewählt habe ich daher eine Variante über die sehr schöne Open Source-App „HTTP Request Shortcuts„.

Endpoint des HTTP Requests ist (bei mir) die IP + ?m=1:

http://xx.xx.xx.xx/?m=1

(Im Zweifel bekommt man die korrekte URL auf der Tasmota Seite des Devices, über die Developer Tools – Netzwerk.)

Man bekommt einen nicht ganz so schön nutzbaren Datensatz, den man mittels JavaScript aber leicht etwas zerlegen kann. Den Response des Request deaktiviert man am besten („Nichts anzeigen“), weil man diesen dann über das Scripting steuert.

Das Script selber muss man an die individuelle Zählerkonfiguration anpassen. Bei meinem Fall war es so sehr gut nutzbar:

const regex = /\{s\}(.*?)\{m\}(.*?)kWh/g;
let match;
const extractedValues = {};

while ((match = regex.exec(response.body)) !== null) {
  extractedValues[match[1].replace("LK13BE ","")] = match[2].replace("000","");
}

showDialog("Aktueller Verbauch: "+extractedValues["Verbrauch aktuell"].split(",0")[0] + " W\n\n1 Tag: " + extractedValues["Verbrauch 1 Tag"] + " kWh\n7 Tage: "+ extractedValues["Verbrauch 7 Tage"] +" kWh\n30 Tage:" + extractedValues["Verbrauch 30 Tage"] + " kWh\n365 Tage: "+extractedValues["Verbrauch 365 Tage"]+" kWh\n\nZählerstand: "+extractedValues["Gesamtverbrauch"]+" kWh");

Alternativ kann man es auch als Toast ausgeben lassen (showToast) oder vorlesen lassen (speak). Die Verknüpfung zum Request lässt sich dann auf den Homescreen legen und die aktuellen Zählerdaten sind nur einen Tab entfernt.

Fröhliches Ausprobieren …

Workarround: GPIO Raspberry Pi 5 / Bookworm

Der neue Raspberry PI 5 unter Raspberry Pi OS Bookworm schmeißt einiges in Sachen GPIO über den Haufen. Viele altbekannte Tools funktionieren nichtmehr. Damit war nach dem Upgrade auf Pi 5 auch meine Velux Rollosteuerung im Eimer, da diese über ein Relaisboard an den GPIOs gesteuert werden.

Obwohl der Raspberry Pi 5 immer noch über den standardmäßigen 40-Pin GPIO verfügt, unterscheidet sich seine Funktionsweise nun, da er an den neuen RP1-Southbridge-Chip angebunden ist. Dies ist von Bedeutung, da es die Art beeinflusst, wie manCode zur Interaktion mit dem GPIO schreibt. Früher setzten viele Projekte auf RPi.GPIO, ein von der Community initiiertes Projekt von Ben Croston, das mehrere Generationen des Raspberry Pi unterstützte. Beim Raspberry Pi 5 ist die Verwendung von RPi.GPIO jedoch nicht mehr möglich.

Mit libgpiod gibt es wohl auch schon einen Ersatz für RPi.GPIO, aber mich tiefgreifend damit zu beschäftigen und in NodeRED zum Laufen zu bekommen, dafür habe ich in der „ruhigen“ Adventszeit irgendwie keine Zeit. Hinweise nehme ich gern entgegen. Bis dahin mein quick-and-dirty Workarround mit pinctrl.

Befehle

-p listet dir die verfügbaren GPIOs und deren Status auf:

sudo pinctrl -p

set 18 op dh initialisiert den GPIO18 als Output und setzt ihn auf high (dh)

sudo pinctrl set 18 op dh

Achtung! op ist nicht bootfest.

set 18 dl setzt GPIO18 auf low (dl)

sudo pinctrl set 18 dl

In Node-Red

In Node-Red kriegt ihr das ganze mit dem exec Node ausgeführt. Ich habe entsprechende Trigger integriert, damit mein Relais nur für 500ms angetippt wird.

Maybe to be continued

Pi-hole über das Smart Home steuern

Möchte man Seiten flexibel auf die Black- oder Whitelist von Pi-hole setzen, so gibt es dafür eine recht karge HTTP-API (GET), mit welcher du die „Domains“ von Pi-hole befüllen oder bereinigen kannst.

Diese findest du unter folgender – für deine Situation anzupassenden – URL:

http://[IP]/admin/api.php?list=regex_white&add=(%5c.%7c%5e)youtube%5c.com%24&auth=[Auth-Code]

Erläuterung der Bestandteile

Die IP deines Pi-hole solltest du kennen – genauso ob du den Adminbereich per http oder https erreichst.

Wie in der Adminoberfläche hast du auch über die API die Möglichkeit, die URLs auf die folgenden vier Listen einzutragen:

  • white
  • black
  • regex_white
  • regex_black

Du hast die Möglichkeit eine Domain hinzuzufügen (add) oder zu entfernen (sub).

Die Domain selbst muss encodiert sein. Ein Regex-Filter für youtube.com als Wildcard lautet somit:

(%5c.%7c%5e)youtube%5c.com%24

Das %5c steht z.B. für ein Backslash „\“, %7c ist ein senkrechter Strich „|“, %5e ist ein Zirkumflex „^“ und %24 ist ein Dollar Zeichen „$“.

Zuletzt brauchst du noch den Auth-Code. Diesen findest du in der Pi-hole-Adminoberfläche unter [Settings] -> [API] -> [Show API token].

Geräten das Internet sperren

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.

msg.payload = {
    "NewIPv4Address": "192.168.2.10",
    "NewDisallow": 1
};

return msg;

Ü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“.

Eine Statusanzeige/Ampel fürs SmartHome

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.)

#include <Adafruit_NeoPixel.h> 
#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>

#define PIN D2 //RGB LED Chip auf dem Digitalen PIN D2

const char* ssid = "xx";
const char* password = "xx";

IPAddress staticIP(192, 168, xx, xx); //ESP static ip
IPAddress gateway(192, 168, xx, xx);   //IP Address of your WiFi Router (Gateway)
IPAddress subnet(255, 255, 255, 0);  //Subnet mask
IPAddress dns(192, 168, xx, xx);  //DNS

Adafruit_NeoPixel pixels = Adafruit_NeoPixel(1, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
    Serial.begin(115200);
    WiFi.hostname("xx");
    pixels.begin(); //initialisieren
    WiFi.config(staticIP, subnet, gateway, dns);
    WiFi.begin(ssid, password);
    WiFi.mode(WIFI_STA); 
    while(WiFi.status() != WL_CONNECTED){
        Serial.println(".");
        pixels.setBrightness(15); 
        pixels.setPixelColor(0, pixels.Color(255, 0, 255)); 
        pixels.show(); //Aktualisieren des NeoPixels
        delay(100);
        pixels.fill(0x000000);
        pixels.show();
        delay(100);
    }
  
    Serial.println(millis()); 
}

void loop() {
  if ((WiFi.status() == WL_CONNECTED)) { //Check the current connection status
     WiFiClient client;
     HTTPClient http;
     http.begin(client, "http://192.168.xx.xx:1880/arduino/ww");
     int httpCode = http.GET();
  
     if(httpCode == 200) {
        String payload = http.getString();
        if(payload == "1") {
           pixels.setPixelColor(0, pixels.Color(255, 0, 0)); 
           Serial.println("Kein Warmwasser da");
        }
        else {
           if(payload == "2") {
              pixels.setPixelColor(0, pixels.Color(255, 255, 0));         
              Serial.println("Wenig Warmwasser da");
           }
           else {
              pixels.setPixelColor(0, pixels.Color(0, 255, 0));          
              Serial.println("Genug Warmwasser da");
           }
        }
     }
     else {
        Serial.println("Error on HTTP request");
        pixels.setPixelColor(0, pixels.Color(255, 255, 255));          
     }
     
     http.end();
     pixels.show(); //Aktualisieren des NeoPixels
  }
  delay(30000);
      pixels.setPixelColor(0, pixels.Color(255, 0, 255)); 
      pixels.show(); //Aktualisieren des NeoPixels
      delay(300);
}

Hinweise

  • Die Vergabe einer festen IP beschleunigt den Verbindungsversuch um ein paar Millisekunden, kann man machen, muss man aber nicht.
  • Die LED des Shields ist sehr hell, ich habe die Helligkeit daher deutlich reduziert.
  • Über die serielle Schnittstelle (Baud 115200) ist der Sketch sehr gesprächig.

Velux Dachfenster Solar-Rollos smart machen

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)

Bei einer Vielzahl von Sensoren den Akkustand prüfen

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

var zigbeesensoren = [2,4,5,6,9,10,11,14,15,16,17,21,23,26,29,30,31,32,33,34,36,38,41,44,45,46,49,50,51,52,53,56,57,58];

zigbeesensoren.forEach(function(val) {
    msg.topic = "deconz.0.Sensors."+val+".battery";
    node.send(msg);
});

return;

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.

Was schon alles kaputt ging …

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)

WordPress Koko Analytics im SmartHome Dashboard

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.