Schlagwort: nodered

Kaputt gespielt – Backup und Wiederherstellung

Was soll ich sagen, irgendwie habe ich mein Raspberry Pi OS (Raspbian) kaputt gespielt. Es fing damit an, dass ich nicht per VNC auf das System kam (für deCONZ). Zeitweise ging nicht mal raspi-config. Und: jedes mal ging nach ein paar Betriebsstunden die CPU Last massiv in die Höhe – ausgelöst durch einen Fehler mit oder durch kworker. Also fiel die Entscheidung: neu aufsetzen. Ein praktischer Präzedenzfall für Backup & Restore.

In meinem Setup waren drei, oder besser vier Dinge zu sichern und zu überspielen. Da ich noch einen Raspberry Pi 4 herumliegen hatte, konnte ich die Systeme parallel laufen lassen, und musste nicht ständig zwischen alt und neu wechseln, sofern mir noch Infos fehlten. Auch konnte ich so die Vollständigkeit der Daten gut prüfen.

Zum Kopieren der Daten zwischen den Raspberrys nutze ich immer WinSCP.

1. deCONZ/Phoscon

Bei Phoscon einfach über die Weboberfläche unter „Gateway“ ein Backup ziehen und an gleicher Stelle auf dem neuen System wieder einspielen. Das Einspielen des Backups habe ich jedoch erst gemacht, als die microSD-Karte mit dem neuen System auch im Raspberry Pi mit dem Conbee II steckte, um mögliche Probleme zu vermeiden.

2. InfluxDB

Hier sollte man zwingend mit den Backup & Restore Befehlen von influxd arbeiten, ein Kopieren der Datenordner führte (zumindest bei mir) nicht zum Erfolg.

Es müssen sowohl der META-STORE als auch die Datenbank(en) gesichert werden.

$ influxd backup <speicherort-fuer-backup>
$ influxd backup -database iobroker <speicherort-fuer-backup>

Das Wiederherstellen ist ähnlich leicht.

$ influxd restore -metadir /var/lib/influxdb/meta <speicherort-des-backups>
$ influxd restore -database iobroker -datadir /var/lib/influxdb/data <speicherort-des-backups>

Anschließend muss man ggf. noch die Benutzerrechte des Ordners anpassen.

$ sudo chown -R influxdb:influxdb /var/lib/influxdb

3. ioBroker

Bei ioBroker kann man ein komplettes Backup sehr leicht über die Kommandozeile erstellen:

$ cd /opt/iobroker
$ sudo iobroker stop
$ sudo iobroker backup
$ sudo iobroker start

Das Backup liegt dann unter /opt/iobroker/backups/.

Ebenso einfach ist das Wiederherstellen. Das Backup-Archiv muss man dazu in den gleichen Ordner auf dem neuen System kopieren.

$ sudo iobroker stop 
$ sudo iobroker restore 0
$ sudo iobroker start all
$ sudo iobroker start
$ sudo iobroker upload all

(der Befehl „sudo iobroker upload all“ lädt die Webseiten aus den Ordnern „www“ und „admin“ aus den Adaptern in den ioBroker-Dateispeicher hoch)

Nun dauert es je nach Umfang der ioBroker-Installation einige Minuten, bis automatisch wieder alle Adapter installiert sind. Über die Weboberfläche – Instanzen kann man den Prozess rudimentär beobachten.

4. Node-RED

Die Flows werden beim ioBroker-Backup (3.) mitgesichert. Allerdings werden die zusätzlich installierten Node-Module (über „Palette verwalten“) beim Wiedereinspielen nicht automatisch installiert. Hier hilft ein Screenshot der Liste oder eine kurze Notiz der installierten Node-Module. Aber: zur Not lassen sich die auch anhand der Auflistung fehlender Nodes recherchieren und rekonstruieren.

Probleme

Probleme gab es eigentlich gar nicht. Einzig der ioBroker PING Adapter ändert den Objektpfad anhand des Hostnames – wählt man hier bei der neuen Installation einen anderen, muss man sämtliche Pfadangaben des PING Adapters z.B. im Node-RED korrigieren.

Nachtrag 23.06.2021

Inzwischen (?) kann man im PING Adapter einstellen, dass der Hostname nicht im Zustandsnamen verwendet werden soll. Wenn man bei der Einrichtung darauf achtet, kann man beim Backup & Restore dieses Problem umschiffen.

Schnelles Smartphone UI

Ich mag ioBroker, ich mag Node-RED – aber ein User Interface, welches innerhalb von drei Sekunden auf dem Smartphone zur Verfügung steht, ist weder mit vis noch mit Node-RED UI / Dashboad möglich. Vielleicht liegt es am eingesetzten Raspberry PI und eine Monster-Hardware würde es schneller ermöglichen – so ist die Ladezeit je nach Verbindungsqualität (WLAN, VPN) jedoch belastend – gerade für den schnellen Blick auf die Haustechnik (z.B. Solarthermie) oder die Straßenbahn-Abfahrtszeiten.

Einzige Lösung kann eine native App fürs Smartphone sein, dachte ich mir. Doch weder für vis noch für Node-RED UI gibt es entsprechende perfomante Ansätze. Also musste eine weitere Lösung her. Erste Tests mit MQTT Dashboard-Apps waren verheißungsvoll, doch offenbarten sie dann Probleme. Denn bei MQTT muss die App weitgehend online sein, um die aktuellen Werte empfangen zu können. Frisst Akku und Leistung auf Seiten des Smartphones. Ein Abrufen der Werte nach einer längeren Offline-Phase ist nicht ohne weiteres möglich.

Covergestaltung

Dann stolperte ich über die App IOT Dashboard, welche mich gerade sehr begeistert. Die App von Ciprian Savastre ermöglicht es, via REST im JSON-Format Daten abzurufen, und auch Befehle zu senden. Ein paar Nodes in Node-RED ermöglichen sowohl die Auslieferung der Daten an die App, als auch das Empfangen von Befehlen aus der App.

  • Ja, die App ist funktionell noch ausbaufähig. Der Entwickler ist aber nett und ansprechbar für Bugs und Ideen.
  • Ja, es ist nur eine Ergänzung zu einem ausgefeilten UI via vis oder Node-RED Dashboard.
  • Ja, man muss auf dem Smartphone einigen Konfigurationsaufwand betreiben.

Dafür hat man aber in atemberaubender Geschwindigkeit den aktuellen Stand des Smart-Homes auf dem Schirm.

Und so sieht es gerade bei mir aus:

Aktuell benutze ich noch keine Steuerungsfunktionen, sondern nur das reine Auslesen von Werten. Daher sieht es im Node-RED auch bisher sehr einfach aus.

Die Steuerung realisiere ich bisher über Node-RED UI / Dashboard – einige häufig genutzte Funktionen werde ich aber sicher auch in der App IOT Dashboard abbilden – außer es läuft mir etwas besseres über den Weg.

NodeRed UI Design

Das Design von NodeRed Dashboard braucht meiner Meinung nach noch ein wenig „Nachhilfe“. Hier die drei wichtigsten Styles meiner „Nachhilfe“, welche ich über ein ui_template Node in die <head> Section einfüge.

<style>
body {
        font-size:0.8em;
        background-color:#E6F7FF !important;
    }
md-card {
        border-bottom: 1px solid #F2F2F2;
    }
.nr-dashboard-cardpanel > p {
        margin-top: 3px !important;
        margin-bottom: 3px !important;
        min-height: 23px !important;
    }
</style>

Das Ergebnis:

UI-Performance – Diagramme von Flot

Auch wenn ich das Node-RED Dashboard sehr mag, eines ging mir gehörig auf den Keks: die Performance. Ursache dafür waren bei mir (diesmal) die Diagramme (chart), die den Ladevorgang eines Tabs teils um 10 Sekunden verlängerten. Daher bin ich auf die Diagramme von Flot umgestiegen, welche als iframe (template Node) eingebunden werden und damit asynchron laden. Das Ergebnis: Der Seitenaufbau ist schnell, das Diagramm braucht halt vielleicht noch kurz …

Um die Flot Diagramme an das Dashboard anzupassen nutze ich folgende Einstellungen:

Die Legende ist sicher je nach Anwendungsfall nötig oder nicht nötig. Auch die Höhe des Diagramms sollte je nach Art der Werte angepasst werden.

Das Ergebnis kann sich sehen lassen.

Ladevorgang läuft …
Geladen.

Die Nutzung von Flot hat noch weitere Vorteile:

  • auch nach einem Neustart von Node-RED habe ich noch „volle“ Diagramme
  • die Farben der Linien bleiben auch nach einem Neustart gleich
  • es lassen sich einfach zusätzliche Linien/Marken in die Diagramme einzeichnen
  • man kann die Kurven falls nötig leicht glätten

Wetterradar im Dashboard

Ich wollte gern ein Wetterradar im Dashboard haben. Doch an solche grafischen Darstellungen kommt man ja nicht immer ohne weiteres (kostenlos) ran – und der DWD bietet nur eine Drei-Länder-Darstellung.

Also musste etwas CSS her, um mittels eines Node-RED template Node nur einen Bildausschnitt darzustellen.

<div style="position:absolute;width: 296px;height: 250px; background-color: #BEBEBE;overflow: hidden;">
<img src="https://www.dwd.de/DWD/wetter/radar/radfilm_thu_akt.gif" style="position: absolute;top:-250px;	overflow: hidden;" />
</div>

Ich definiere einen Container mit overflow:hidden; sodass alles was nicht reinpasst auch nicht angezeigt wird. Mittels top und left kann ich das Bild entsprechend vertikal und horizontal verschieben.

Update 2021

Inzwischen bin ich auf das Radar eines anderen Wetterdienstes umgestiegen. Da dieser bei der Fremd-Verwendung nicht so freigiebig ist, wie der DWD, erwähne ich dessen Namen hier nicht und sagen nur so viel: mit einem simuliertem Website-Zugriff (http request-Node) und der Übermittlung des Cookies und des richtigen Referer-Headers beim Abruf der Radar-Grafik ist so manche unwirksame Sperre überwindbar. Die Grafik speichere ich dabei lokal zwischen (httpStatic).

Ein change-Node zwischen simuliertem Website-Zugriff und Grafik-Abruf

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:

shelly-subflowHerunterladen

Gefrorener Raspberry Pi

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.

Verflixte GPIOs (2)

Fortsetzung von Verflixte GPIOs

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:

node-red-node-pi-gpio

Funktioniert wunderbar.

Verflixte GPIOs

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

Fehlersuche in NodeRED

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

msg.payload=parseFloat(msg.payload);

Wird sicher fortgesetzt …