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.

Tasmota OTA auf Shelly flashen

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.

Die Firmware findet ihr hier: https://github.com/yaourdt/mgos-to-tasmota

Man benötigt die Shelly-IP und den zur Shelly-Variante passenden Link – welchen ihr auf github findet. Zum Beispiel:

http://shellyip/ota?url=http://dl.dasker.eu/firmware/mg2tasmota-Shelly25.zip 

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.

Warum ich meine Shelly 2.5 nicht mehr mit MQTT steuere

Bisher habe ich die Shelly 2.5, welche ich zur Rolladensteuerung einsetze, über iobroker + MQTT gesteuert. Ich nutze bei ihnen die original Firmware, weil ich die Positionskontrolle, die Kalibierierung und die Hindernis-Erkennung sehr schätze. Darum steuere ich jetzt nicht mehr per MQTT:

Scheinbar ein Firmware Bug

Disclaimer: dieser Artikel ist schon etwas älter. Ob es ein Bug war und ob es diesen potentiellen Bug noch gibt, weiß ich nicht. Ich komme mit der Nicht-MQTT Steuerung sehr gut klar, daher habe ich dies beibehalten.

Ab und zu kommt es bei meinen Shellys dazu, dass die WLAN Verbindung abbricht. Dies liegt einfach an der Reichweite des WLANs, die in mancher Wand im Grenzbereich liegt. Dies ist normalerweise kein Problem, da sich die Shellys recht zuverlässig wieder mit dem Router verbinden. Doch manchmal öffnen sich nach der Wiederverbindung wie von Geisterhand die Rollos – also sie fahren unvermittelt nach oben. Viele Tests später ist meine Theorie, dass dies am MQTT liegt, und es hier scheinbar einen Bug in der Firmware gibt.

MQTT + iobroker Objekte

Zweiter Grund: Von NodeRED kommt die Logik meines SmartHomes. So auch die Rolladensteuerung. Über das Setzen/Ändern von iobroker Objekten, sendet man die Befehle per MQTT. Ein Problem: hat das Objekt bereits den gleichen Wert, wie den, den man setzen will, wird der Befehl nicht übertragen. Wurde also zum Beispiel zuletzt das Rollo auf 60% gestellt, das Rollo danach per Wandtaster wieder hochgefahren, kann man es nicht erneut auf 60% einstellen, weil das Befehls-Objekt noch auf 60 steht. Man muss also umständlich auslesen, welcher Wert gerade im Objekt steht, und ggf. z.B. 61 übermitteln.

Darum nutze ich jetzt die HTTP API

Umgestiegen bin ich auf die HTTP API. Über sie rufe ich peridoisch den aktuellen Status ab (tags öfter als nachts) und sende Befehle. Die Vorteile:

  • Ich habe einen Adapter weniger im iobroker, spart Arbeitsspeicher.
  • Ich umgehe den möglichen Firmware Bug und habe (bisher) keine geisterhaft öffnenden Rollos mehr.
  • Ich kann Befehle senden, ohne diese vorher mit dem aktuellen Status abgleichen zu müssen.
  • Ich bekomme über den HTTP StatusCode (200) direktes Feedback, ob ein Befehl angekommen ist.

So mache ich es

Zum einen habe ich in Node-RED einen HTTP in-Node erstellt, bei dem sich die Shellys über die I/O URL Actions melden, wenn sie stoppen – also die Rollos eine neue Position eingenommen haben. Der dann angestoßene Abruf der Position hält den Wert im iobroker aktuell.

Zum anderen habe ich einen Subflow erstellt, welcher die Befehle an die Shellys übermitteln. Er benötigt als Argument die IP des betroffenen Shellys und einen Befehl. Dabei verarbeitet der Subflow sowohl Open, Close und Stop als Textbefehle als auch Integer-Werte – zwischen 0 und 100 – für die Position des Rollos in „Prozent geöffnet“. (100% = ganz offen)

Hier das Flow:

MQTT/Tasmota ALIVE?

Beim MQTT-Adapter und SONOFF-Adapter im ioBroker gibt es eigentlich bei jedem Gerät auch eine ALIVE/online Variable, die nach meinem Verständnis eigentlich darüber Auskunft geben sollte, ob das Gerät „am Leben“, also online und erreichbar ist. Irgendwie ist diese Anzeige aber sehr unzuverlässig/zeitverzögert.

Daher nutze ich den PING Adapter, um im Minutentakt zu erfahren, ob ein Gerät offline ist, und um dann entsprechende Warnungen im Dashboard ausgeben zu können, oder bei kritischen Aktoren eine Warnmeldung per E-Mail zu versenden.

Alle 60.000 ms – also eine Minute – reicht für meine Zwecke.