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.

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.

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)

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.

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.

Eine eigene PHP-Web-API bauen

Um Daten aus dem SmartHome auf eine eigene Website zu bringen, habe ich mir eine Authentifizierung gebaut, die es mir erlaubt, per POST Request Daten bereitzustellen – und zwar nur mir. Einfach nur ein festes Passwort war mir da zu unsicher. Daher habe ich eine zeitbasierte Komponente mit eingebaut.

Zum Einsatz kommt seitens Node-RED node-red-contrib-cryptography.

Ich generiere einen Auth Token, dieser basiert auf der aktuellen Zeit und einem geheimzuhaltenden Passwort, quasi einem Salt.

msg.payload = Math.round(Date.now()/10000) + "dasGeheimePasswort1234!";
msg.headers = {};
msg.headers["Content-Type"] = "application/x-www-form-urlencoded";
return msg;

Beim Token habe ich mich für eine Gültigkeit von 10 Sekunden (daher geteilt durch 10.000) entschieden, dann sind minimale Ungenauigkeiten bei den Uhrzeiten zwischen SmartHome und Webserver nicht so dramatisch. Der Payload wird dann durch die hash-Funktion sha256 gehasht. Anschließend wird der POST Request mit Daten bepackt und der http request abgeschickt.

msg.payload = {
"auth": msg.payload,
"temperatur": msg.temperatur
};
return msg;

Um dem POST Request zu empfangen und zu authentifizieren muss die PHP Gegenstelle den gleichen Token generieren und mit dem mitgeschickten Token abgleichen. Dazu braucht die Gegenstelle natürlich auch den auf 10 Sekunden gerundeten Timestamp und das gleiche geheime Passwort, wie es im Node-RED hinterlegt ist.

<?php
   if($_POST["auth"] == hash('sha256',(round(time()/10))."dasGeheimePasswort1234!")) {
echo "true";
}
?>

Achtung! PHP arbeitet bei den Timestamps in Sekunden, während JavaScript in Millisekunden arbeitet. Daher ist hier nur eine Division durch 10 nötig.

Statt dem echo „true“; kann man natürlich beliebiges mit den mitgeschickten Werten anfangen.