Nein, in diesem Beitrag geht es leider nicht um ein leckeres Dessert. Es geht um ein Problem, welches ich in letzter Zeit immer wieder beobachtet habe: der Raspberry Pi, der mein Smart Home steuert, hängt sich auf.
Das Phänomen
Manchmal, wenn ich einen drahtlosen Zigbee Schalter (Xiaomi/Aqara) betätigt habe, war in der Folge der Raspberry Pi nicht mehr erreichbar, hatte sich aufgehängt – weder über die verschiedenen Ports (1880, 8081, 8082) noch per Ping gab er ein Lebenszeichen von sich.
Die Analyse
Die Problemanalyse lief tatsächlich recht schleppend, tröstete ich mich damit, dass ich das System wohl mal neu aufsetzen muss. Irgendwann fiel mir dann aber ein Muster auf.
Das Muster
Das Problem trat nur auf, wenn ein Zigbee Schalter einen Zigbee Aktor schalten sollte. (Logik via Node-RED) Sollte der Zigbee Schalter einen WLAN Aktor schalten, trat das Problem nicht auf. Sprich: wenn der Conbee II (Phoscon, Dresden Elektronik) zuerst ein Signal empfangen und Sekundenbruchteile später ein Signal senden sollte.
Die (vorläufige) Lösung
Die vorläufige Lösung, die seit zwei Wochen Ausfälle wirkungsvoll verhindert hat, ist ein Verzögerung (delay) zwischen Empfang und Senden des Signals. Aktuell experimentiere ich mit einer halben Sekunden – ist nicht unbedingt schön, aber scheinbar wirkungsvoll.
Die Freude über die Lösung mit dem exec-Node und wiringPi währte nur kurz, denn wiringPi wird nicht weiterentwickelt (wiringPi – deprecated…) und unterstützt so den Raspberry Pi 4 nicht.
Ersatz (hoffentlich langfristig) habe ich (natürlich) in einem NodeRED Node gefunden:
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.
Über die GPIOs des Raspberry Pi habe ich ein Relais-Board angeschlossen. Es manipuliert den Temperatursensor des Solar-Steuerung, um eine automatische Abkühlung des Warmwasserspeichers in der Nacht zu ermöglichen. So versuche ich auch in Hitze-Phasen eine Stagnation in der Solaranlage zu verhindern.
Zur Steuerung kam der ioBroker-Adapter RPI-Monitor (rpi2) zum Einsatz. Nach irgendeinem Update bekam ich diesen aber nicht mehr zum Laufen.
Ständig nur folgender Log-Eintrag:
GPIO is not initialized!
(Das Problem scheint nicht nur bei mir aufzutreten, ein Bug-Report findet sich bei GitHub.)
Einige Stunden Recherche und Probieren später, war ich es leid, und da ein Neuaufsetzen aktuell nicht zur Debatte steht, suchte ich eine andere Möglichkeit. Diese fand ich im exec-Node und wiringPi.
Hinweis: wiringPi wird leider nicht mehr weiterentwickelt, sodass diese Lösung nur mit Raspberry Pi’s bis Modell 3B+ funktioniert. Eine weiter Lösung gibts unter Verflixte GPIOs (2)
Nicht die schönste Variante, aber einfach und wirkungsvoll.
Über die Kommandozeile habe ich einmalig den Modus des entsprechenden GPIO auf „out“ gesetzt.
gpio -g mode 23 out
Nun kann ich über den exec-Node den Status des GPIO auslesen und auch setzen.
Macht man seine ersten – oder auch schon etwas intensivere – Schritte im NodeRED, geht nicht alles sofort glatt. Bei mir zumindest.
Häufige Fehler bei mir:
1. Ich baue Endlosschleifen – und nichts geht mehr.
Gerade im Zusammenhang mit NodeRED Dashboard ist es mir immer wieder passiert, dass ich Endlosschleifen gebaut habe.
Allein dieser Aufbau birgt schon das Risiko einer Endlosschleife.
Abhilfe ist einfach. Beim Laden des Variablenwertes den Modus auf „block unless value changes“ setzen.
An anderer Stelle kann auch der report-by-exception – Node (rbe) hilfreich sein. Hier wird jede msg aufgehalten, bis der payload sich unterscheidet.
2. Ich setze statt change ein switch
Eigentlich sind switch und change sehr leicht auseinanderzuhalten. Nur liegen sie in der Palette halt direkt nebeneinander, haben ähnliche Symbole, die gleich Farbe, und möchte man ein Change (ich ändere den Wert einer Variable) einsetzen und setzt stattdessen ein Switch (if then else) fällt auch das Properties Menü kaum negativ auf, sofern man nur kurz die payload verändern will. Mir schon mehrmals passiert – hier lohnt sich ein genauer Blick.
3. Datentypen
Im ioBroker-Adapter NodeRED ist standardmäßig eingestellt, dass alle aus dem ioBroker gelesen Werte in String (Text) umgewandelt werden.
Versucht man dann mit den Werten zu arbeiten, zu rechnen, true und false zu vergleichen, merkt man schnell, entweder muss die Option im Adapter umgestellt werden, oder man muss mit Datentypen jonglieren. In diesem Fall wird der JavaScript function-Node dein Freund.
Zum Beispiel zum Umwandeln einer Zahl (string) in eine „wirkliche“ Zahl (float).
Ab einer gewissen Zahl von WLAN Komponenten, wird es zur Herausforderung, die Firmware der Geräte auf dem aktuellen Stand zu halten. Zu diesem Zweck habe ich mir ein Tab in meinem Node-RED Dashboard eingerichtet.
Das grüne Herz zeigt, dass der Shelly online ist.
Die Abkürzung OTA steht für „Over The Air“, auf deutsch „über die Luft“. Es handelt sich dabei um eine drahtlose Methode, Updates auf Geräte zu übertragen.
Tasmota Firmware
Die aktuelle Tasmota Version, lässt sich durch einen automatisierten Abruf des GitHub-Feeds auslesen:
Auch die OtaUrl lässt sich per simplem HTTP-Aufruf anpassen. Leerzeichen oder Sonderzeichen in der OtaURL müssen durch ihre jeweiligen ASCII-Hex-Codes ersetzt werden. Dem Hex-Code muss ein Prozentzeichen % vorangestellt werden (z. B. %3B).
Bei der Original Shelly Firmware, ist es ähnlich leicht, aber ein wenig anders. Die aktuell zur Verfügung stehende Firmware Version lese ich aus der JSON-Datei der offiziellen API:
https://api.shelly.cloud/files/firmware
Hier findet man auch die Download-Urls zu den Firmwares für die Shelly Geräte. Die aktuelle Firmware, hier für den Shelly 2.5, liegt zum Beispiel hier:
Möchte man eine andere Shelly-Firmware-Version flashen, lässt sich hier auch eine Firmware-URL übergeben. Soweit ich weiß ist das Flashen auf eine alternative Firmware (Tasmota) so jedoch nicht möglich.
Seit Version 10.0.0 von Tasmota braucht man natürlich beim Filtern der Feed Version natürlich ein substring(0,6) – etwas unflexibel, sollte ich mal ändern.
Ich baue mir mein eigenes SmartHome. Da ich dies nicht während eines Neubaus, sondern in einer (unserer) Bestandsimmobilie tue, sind die meisten Lösungen auf Funkbasis.
Ich versuche beim Bau einigen Grundsätzen zu folgen:
kein Smartphone Zwang – alle wichtigen Funktionen wie Licht und Rollläden müssen auch über die normalen Schalter bedienbar sein.
keine Insellösung – das Festlegen auf einen einzelnen Hersteller schränkt nur unnötig ein und verteuert es.
my home is my castle – das SmartHome läuft bei mir zuhause – nicht in der Cloud.
Open Source – soweit es geht. Bei der Firmware (gerade von Zigbee-Geräten) stößt man hier natürlich an seine Grenzen.
kein „Alexa“, kein „Hey Google“ – Daten fallen in einem SmartHome wahre Unmengen an. Doch die bleiben bei mir.
es hat auch Grenzen: zumindest sage ich das jetzt noch.
Ich bin in dem Bereich kein Profi. Vor gut einem Jahr habe ich mit ioBroker und NodeRED angefangen. Trotzdem gibt es vielleicht die ein oder andere Erkenntnis, die ich hier teilen kann.
