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