Von der Haustürklingel über den ioBroker zum Handy

Ziel war es, auf dem Handy eine Push-Benachrichtigung zu erhalten, wenn es an der Haus- oder Wohnungstür klingelt, um darüber z.B. auch im Garten oder im Keller informiert zu werden.

Folgendes war zu beachten:

1. Ein verändernder Eingriff in die Klingelanlage des Hauses war nicht möglich, da es eine Mietwohnung ist, die Klingelanlage also dem Vermieter gehört.
2. Die Klingelanlage selbst ist relativ alt. Es ist eine RITTO 4630 TwinBus Türsprechanlagen mit 2-Draht-Bus, also mit einem Bussystem.
3. Jeder auch testweise Eingriff in dieses Bussystem kann im Mietshaus alle Mietparteien beeinträchtigen (das Internet ist voll von derartigen Berichten) und sollte tunlichst vermieden werden.
4. Die geplante Erweiterung muss spurenlos rückbaubar sein.
5. Eine Stromversorgung mit 220V in unmittelbarer Nähe zur Türsprechanlage besteht nicht.

Daraus folgte:

1. Eine Überwachung des Stromflusses, wie bei klassischen Klingelanlagen z.B. mit dem ELV Bausatz Homematic IP Klingelsignalerkennung HmIP-DSD-PCB, ist nicht möglich.
2. Eine Überwachung des Klingeltones mittels Geräuscherkennung außen an der RITTO Türsprechanlage ist technisch möglich. Offen sind da allerdings die Störmöglichkeiten durch andere Geräusche (Türschlagen). Offen wäre weiterhin die Frage einer dauerhaften, sparsamen Stromversorgung der zu bauenden Schaltung. Eine Deep-Sleep im Programmablauf eine ESP-32 z.B. wäre nicht möglich, da kontinuierlich auf die Klingel „gelauscht“ werden müsste.

Lösung im Überblick:

1. Zentrales Teil ist eine Erweiterung, die der Hersteller für die RITTO 4630 anbietet, ein sogenanntes Rufanschaltrelais (RITTO 4646).
2. Eingebaut in die Türsprechanlage 4630 stellt dieses Rufanschaltrelais einen potentialfreien Relaiskontakt zur Verfügung, der bei Betätigung der Klingel schließt.
3. Parallel zu diesem Kontakt wird der Reed-Kontakt eines kommerziellen Tür- und Fenstersensor geschaltet.
4. Das Schließen des Kontaktes des Rufanschaltrelais beim Klingeln wird per ZigBee (Tür- und Fenstersensor) an den ioBroker gemeldet.
5. Der ioBroker wertet das Signal aus und sendet mittels des Adapters „Pushover“ ein Signal (Ton und Schrift) an die gekoppelten Handys.

Die Lösung im Detail

Das Rufanschaltrelais

RITTO stellt für seine Türsprechanlagen ein sogenanntes Rufanschaltrelais zum Einbau zur Verfügung. Dieses dient üblicherweise dazu, über einen potentialfreien Relaiskontakt weitere Signaleinrichtungen an die Türsprechanlage zu koppeln, wie z.B. Klingeln, Hörner oder Lichtsignale. Zu beachten ist, dass diese Rufanschaltrelais zumindest bei RITTO speziell für die jeweilige Türsprechanlage sind, hier für die relativ alte Türsprechanlage 4630 das Rufanschaltrelais 4646.
Das 4646 ist allerdings nicht mehr vom Hersteller lieferbar, auf einschlägigen Webseiten für Gebrauchtgeräte hingegen noch zu finden. Das 4646 kostete beim Hersteller damals ca. 25 €, hier wurde es gebraucht gekauft, über den Preis wird schamhaft geschwiegen. Es ist mittlerweile halt selten.

RITTO 4646 - Rufanschaltrelais

Für die neueren Türsprechanlagen RITTO 7630, 7650, 7132 und 7230 ist das Rufanschaltrelais 7646 vorgesehen, das im Handel noch erhältlich ist.

Der Tür- und Fenstersensor

Der Tür- und Fenstersensor übernimmt die Aufgabe, das Schließen des Kontaktes des Rufanschaltrelais („es klingelt“) mittels ZigBee an den ioBroker zu melden. Es muss ein Sensor sein, der das Schließen der Tür oder des Fensters mit Hilfe eines Reed-Kontaktes detektiert. Sensoren, die auf dem Hall-Effekt basieren (z.B. einige Tuya-Sensoren) sind nicht nutzbar. Verwendet ist hier ein Sensor mit Reed-Kontakt von Aqara (Modell MCCGQ11M). Der kostet beim freundlichen Chinesen von neben an ca. 10 €.

Aqara Tür- und Fenstersensor (ZigBee) im demontierten Zustand

Auf dem Bild ist der Aqara Tür- und Fenstersensor im demontierten Zustand zusehen, der dazugehörige Fenstermagnet fehlt, da er für diese Aufgabe nicht benötigt wird. Deutlich zu erkennen ist an der linken Kante der Leiterkarte der grünliche Reed-Kontakt.

Vorbereitung des Tür- und Fenstersensors

In das Gehäuse des Sensors wird neben dem Reed-Relais ein Schlitz gefräst, durch den der Draht zum Relais herausgeführt werden kann.

An die Kontakte des Reed-Relais wurde ein zweiadriger Draht gelötet und nach außen geführt. Nach einigen wenigen, vergeblichen Versuchen, das Reed-Relais auszulöten, ist es auf der Leiterkarte verblieben, um irreparablen Schaden bei weiteren Versuchen zu vermeiden.

Zum Schluss wurde der Sensor wieder zusammengebaut und auf eine kleine Leiterkarte geklebt, die genau die Maße der Clip-Vorrichtung der Türsprechanlage besitzt.

Zusammenbau

Abschließend wurden das Rufanschaltrelais 4646 (mittig, grün) und der Fenstersensor (oben, weiß) wie vorgesehen in die Türsprechanlage eingeclipt und der Draht (schwarz-rot) vom Fenstersensor zur Leiterkarte des Rufanschaltrelais geführt und dort in die dafür vorgesehenen Anschlüsse des potentialfreien Relaiskontaktes geklemmt. Nach dem Schließen des Deckels der Türsprechanlage ist der Einbau nicht mehr erkennbar.

Den Fenstersensor direkt in die Türsprechanlage zu kleben, empfiehlt sich nicht, da sich dann das Wechseln seiner CR1630-Zelle als schwierig erweisen könnte.

ioBroker

Der Fensterkontakt erscheint nach dem Einbinden in ZigBee unter den Objekten des ZigBee-Adapters. Mit Hilfe eines Skriptes wird seine Eigenschaft „Contact event“ ausgewertet. Ändert sich diese auf „true“ (es klingelt), wird mit Hilfe des Adapters Pushover die Meldung „Es klingelt.“ an alle gekoppelten Handys geschickt. Dazu ertönt auf dem Handy ein spezifisches Signal, das es auch ohne Blickkontakt ermöglicht, ein Klingeln an der Haus- oder Wohnungstür zu bemerken.
Es erfolgt zusätzlich eine Überwachung des Batteriezustandes des Tür- und Fenstersensors, weitere Auswertungen wären möglich.

Fazit

Diese Lösung arbeitet seit einigen Wochen ohne Probleme. Die spürbare Verzögerung des Signales von der Klingel zum Handy ist minimal und hinnehmbar.

In der Pushover-App auf dem Handy (Android) ist es möglich, den Benachrichtigungston für einen geplanten Zeitraum abzuschalten, was vor nicht benötigten Informationen bei Abwesenheit von der Wohnung schützt.

Eine Erweiterung wäre die Aufnahme eines Bildes von der klingelnden Person. Das ist über den ioBroker leicht steuerbar, so eine über diesen auslösbare Kamera existiert und diese installiert werden darf (Mietwohnung!). Eventuell ginge das zumindest über eine Kamera hinter dem Türspion. Allerdings ist eine derartige, vom ioBroker steuerbare Kamera momentan unbekannt.

@jahnbes Hier die versprochene Lösung meines Problems mit der Reinigung einzelner Räume. die Ursachen waren doch vielfältiger, als gedacht.

Zunächst noch mal das Problem, ich hatte versucht, die Zimmerreinigung (einzelne Zimmer getrennt) wie hier im Forum beschrieben zu nutzen:

"Für die Raumreinigung die Räume unter Floors entsprechend auf true oder false setzen und anschließend unter commands app_segment_clean auf true setzen."

Hat auch exakt einmal geklappt, seitdem ging diesbezüglich nichts mehr, egal, wie ich die Räume gesetzt hatte, commands app_segment_clean sprang nicht mehr an.
Nur wenn ich alle Räume auf true setzte, dann säubert er mit commands app_segment_clean wieder alle Räume. Setzte ich danach nur einen Raum auf true, egal, welchen, verweigert commands app_segment_clean den Dienst.
Die Hinweise von [David G.] und [copystring] habe ich getreulich getestet. Es gelang mir zumindest, den Namen der Etage auf „EG“ zu setzen, wie von [David G.] vorgeschlagen. Allerdings funktionierte die Reinigung einzelner Räume danach immer noch nicht.
Während der Test fiel mir auf, dass der roborock immer ins Schlafzimmer marschierte, wenn das Schlafzimmer auf „true“ gesetzt war, ebenso beim Wohnzimmer, die anderen Räume aber ignorierte er.
Ein Blick auf die Kartendarstellung in der App (Handy) zeigte merkwürdigerweise für das Schlaf- und Wohnzimmer die korrekten Bezeichnungen mit einem Icon davor, für alle anderen Räume allerdings nur so etwas wie „Raum1“, „Raum2“ usw., allerdings ohne Icon, obwohl im entsprechendem Item im iobroker „Flur“, „Bad“ u.ä. stand. Diese Bezeichnungen wurden offensichtlich nicht in die Kartendarstellung übernommen.

Offensichtlich hatte ich die Namen dieser Räume über den iobroker eingetragen, die von Wohn- und Schlafzimmer aber über die App (Handy).

Die Lösung des Problems war es, auch die Namen der Räume, für die die Einzelreinigung bisher nicht funktionierte, über die App (Handy) einzutragen:

[Karten verwalten] -> gewünschte Etage [Bearbeiten] -> [Raum bearbeiten] -> [Name] -> Raum aus der Karte auswählen -> [Zimmertyp auswählen] -> [OK]

Als erstes erschien in der Kartendarstellung nun bei allen Räumen vor deren Bezeichnung auch das Icon und - Heureka - die Einzelraumreinigung funktioniert nun für jeden Raum!

Vielen Dank an das Forum für all die Hinweise, die halfen, mich auf den Weg zur Lösung zu bringen!

@liv-in-sky

Nun ist es geschafft, die Systemdaten des Windows-PC werden auf diesem mittels Telegraf gesammelt und mit MQTT an den iobroker gesandt, der auf einem Raspberry Pi läuft.
Von dort aus erfolgt u.a. die Visualisierung mit HABpanel:

Die Daten der Netzwerkplatte, ein Synology-NAS, kommen über den Adapter "Synology NAS" in den iobroker.

Die Temperaturen im PC würde ich auch gern darstellen, da bin ich aber auch mit Telegraf noch nicht rangekommen.

@spacerx
Da hast Du Recht. Mir fehlt da auch mancher Punkt, z.B. kann ich in der Handy-App die Anzahl der Zyklen einstellen. Die habe ich im Adapter noch nicht gefunden.
Und nur verbal direkt vom Gerät bekomme ich die Mitteilung, dass der Staubbehälter entfernt wurde, etwas, was ich anderweitig auch gern sehen und in der gui anzeigen würde.
Es gibt bei dem tollen Adapter noch etwas Luft nach oben, trotzdem, er ist große Klasse, Dank an copystring!
Gruß Bert.

Einzelraumreinigung
@maxb Hallo,
eine Einzelraumreinigung vom iobroker, bzw. von der davor geschalteten gui aus, ist möglich:

• Für die Einzelraumreinigung den gewünschten Raum unter floors auf true und alle anderen auf false setzen.
• Anschließend [commands.app_segment_clean] auf true setzen. (Geht automatisch nach kurzer Zeit wieder auf false.
• Die Reinigung des Raumes beginnt.

Meiner Erfahrung nach reicht das noch nicht, sondern es müssen die Namen der Räume über die App (Handy) eingetragen worden sein. Eine Eintragung der Namen nur über den iobroker reicht nicht!

[Karten verwalten] -> gewünschte Etage [Bearbeiten] -> [Raum bearbeiten] -> [Name] -> Raum aus der Karte auswählen -> [Zimmertyp auswählen] -> [OK]

Ist das erfolgt, erscheint in der Kartendarstellung bei allen Räumen vor deren Bezeichnung auch das Icon und - Heureka - die Einzelraumreinigung funktioniert nun für jeden Raum!

@copystring Vielleicht bin doch ich es, der sich irrt - so war es. Ich habe zwar die log-Ausschriften nicht verstanden, den -meinen- Fehler aber trotzdem gefunden. Es lag nicht am Adapter.
Gruß Bert.

Raumreinigung mit Wiederholung (Reinigungszyklen)

Um die mehrfache Reinigung eines Raumes zu erreichen, ist vor dem Start der Reinigung der Wert
[floors.cleanCount]
auf die gewünschte Anzahl der Reinigungszyklen zu setzen, wobei die Werte [1, 2 oder 3] möglich sind.

Anschließend ist mit [commands.app_segment_clean] die Reinigung zu starten.

Bei 2 z.B. wird die Reinigungsrichtung beim zweiten Zyklus um 90° gedreht, d.h. es wird kreuzweise z.B. gewischt.

Wiki
@maxb
Da schau mal im zugehörigen Wiki nach. Da stehen ein Menge der Objekte dieses Adapters (noch nicht alle) und ihre Bedeutung.
Gruß jahnbes.
(Wer Objekte und ihre Bedeutung kennt, die im Wiki noch nicht oder gar falsch aufgeführt sind, oder bei denen dorten ein "?" steht, melde sich bitte hier!)

@spacerx Danke, ist geändert!

@deekay-0
Hallo deekay,
nein, es ist kein Github-Issue notwendig, das ist schon erfolgt (von mir):
https://github.com/copystring/ioBroker.roborock/issues/348
Und copystring hat auch schon das Problem gelöst, in der dev-Branch von Github ist der Fehler weg.
Bei Gelegenheit wird copystring es in die stable-Version stellen.
Wenn Du die Dev-branch haben willst, die findest Du im obigen Github.
Viele Grüße, Bert.

jahnbes created this issue in copystring/ioBroker.roborock

closed after software update on roborock to02.58.40 #348

@simatec
Das das Restore lokal sicherer ist, hatte ich gelesen und, da vollkommen einleuchtend, auch versucht, zu befolgen. Das hat dann ja auch geklappt. Nur die Files auf den Host zu bekommen, gelang erst über den Umweg. Warum, weiß ich nicht.
Beim nächsten großen Crash, der hoffentlich nie eintritt, werde ich es noch mal versuchen.
Danke noch einmal für Eure Hinweise, ich habe den Hinweis zum lokalen Restore in meine obigen Empfehlungen aufgenommen.

@simatec sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

Zum Thema Influx restore hättest du die Doku von Backitup lesen sollen.
Es darf keine DB vorhanden sein. Wenn du aber den Influx Adapter bereits gestartet hattest, legt der Adapter die Datenbank bereits an.
Somit kann kein Restore erfolgen... Also erst die DB wieder löschen und zuvor den Influx Adapter stoppen. Dann den restore ausführen.

Zum Thema kopieren per FTP usw. Warum so kompliziert? Backitup bietet die Möglichkeit über die Gui ganz einfach Backup Dateien auf dem Host System hochzuladen... Und das ganz bequem von deinem PC aus.

Also alles im allem, kann ich einige Punkte und Empfehlungen nicht so recht nachvollziehen.

Hallo simatec,

welche von meinen Empfehlungen (s.u.) kannst Du nicht nachvollziehen? Ich würde sie gern korrigieren.
Fazit und Empfehlungen:
...
Der backitup-Adapter des ioBrokers ist zu nutzen, er ist sicher und einfach bedienbar.
Alle Backupdaten müssen unbedingt auch außerhalb des Speichermediums des Raspberry Pi gespeichert werden, z.B. auf einer NAS. Das ist innerhalb des backitup-Adapters einstellbar.
Es ist ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi durchzuführen. Dafür wird die Software raspiBackup empfohlen.
Die Sicherung der mit raspiBackup erstellten Daten erfolgt auf einer externen SSD.
Die Nutzung von zwei Raspberry Pi ist erstrebenswert, wobei einer dem Testen (ohne Reue) und der anderen der Produktion (stabiler Lauf der Hausautomatisation) dient.

@simatec
Da hast Du recht, mein "Restore" ist etwas irrtümlich. Ich meinte damit, den gesamten Vorgang, einschließlich dem Upload.
Und der hatte nicht geklappt, das Restore im eigentlichen Sinne hatte noch gar nicht begonnen.

@homoran
Ich habe keine screenshots davon mehr da, liegt auch eine Weile zurück.
Wenn ich mich recht erinnere, geschah einfach nix, ein Fenster öffnete sich, es sah aus, als ob das Restore losgeht und dann endloses nichts, weißes Fenster, keine Ausschrift, auch keine Fehlerausschrift. Nach einer halben Stunde Abbruch und Nachschauen, es erfolgte kein Umspeichern von der NAS und kein Restore. In den in backitup angegebenen Directorys auf dem Raspberry standen die backupfiles von influxDB und Grafana nicht drinn.
Möglicherweise eine von mir nicht verstandene Rechte-Frage.
Der Weg über FTP und FileZilla klappte sofort, siehe oben.

@simatec sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

Zum Thema Influx restore hättest du die Doku von Backitup lesen sollen.
Es darf keine DB vorhanden sein. Wenn du aber den Influx Adapter bereits gestartet hattest, legt der Adapter die Datenbank bereits an.
Somit kann kein Restore erfolgen... Also erst die DB wieder löschen und zuvor den Influx Adapter stoppen. Dann den restore ausführen.

Zum Thema kopieren per FTP usw. Warum so kompliziert? Backitup bietet die Möglichkeit über die Gui ganz einfach Backup Dateien auf dem Host System hochzuladen... Und das ganz bequem von deinem PC aus.

Also alles im allem, kann ich einige Punkte und Empfehlungen nicht so recht nachvollziehen.

Hallo simatec,

danke für die Hinweise.
zu Punkt 1:
Die Doku habe ich schon gelesen, leider habe ich diese Hinweise auf den Hilfeseiten nicht gefunden, ansonsten wäre ich ihnen selbstverständlich gefolgt. Beim nächsten mal werde ich es sicher tun.
zu Punkt 2:
Genau das hat ja nicht funktioniert, deshalb der Weg über FTP.

Aber vielleicht bin ja ich es, der sich irrt.

ioBroker-Backup - Erfahrungen und Empfehlungen

Aus unbekanntem Grund kam es während oder nach einem Update von node.js zu einem totalen Crash des Betriebssystems (Raspberry Pi OS) auf einen Raspberry Pi 4. Der Rechner steckte in Folge nach dem Booten in einer endlosen, sekündlichen Wiederholung einer nicht lesbaren Fehlerausschrift, ohne dass ein Zugriff auf den Rechner oder eine Unterbrechung der Ausgabe dieser Liste möglich gewesen wäre.

Nichtsdestotrotz lief der ioBroker in rudimentärem Umfang weiter. Nach und nach verabschiedeten sich allerdings immer mehr Adapter, der Funktionsumfang der Hausautomatisation wurde schrittweise geringer. Glücklicherweise zog sich das über einige Wochen hin.
Eine Neuinstallation mit Übernahme der Backup-Daten wurde notwendig.

Ausgangssituation:

1. hardware: Raspberry Pi 4, HS: 8 GByte, SSD: 128 GB
2. booten: von SSD
3. software: Raspberry Pi OS (12, bookworm), ioBroker (26 Adapter), Grafana, InfluxDB
4. Laufzeit: seit ca. 3 Jahren
5. Backup: Adapter backitup
   https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md
6. backitup: Backup-Files auf der SSD und mittels FTP auf einem Synology-NAS
7. kein zweiter Raspberry Pi zum Testen

Erfahrungen hard- und software:

1. Der Zugriff auf das System zur partiellen Fehlerbehebung unter möglichst geringer Zerstörung der ioBroker-Installation scheiterte.
2. Es blieb nur die komplette Neuinstallation des Betriebssystems Raspberry Pi OS mit dem totalen Verlust des bisherigen Plattenstandes.
3. Diese Neuinstallation erfolgte sicherheitshalber auf einem inzwischen beschafften nahezu gleich ausgestatten zweitem Raspberry Pi 4 (HS: 8 GByte, SSD: 256 GB).
4. Der „kranke“ Raspberry Pi lief unterdessen weiter.
5. Die Neuinstallation des Betriebssystems Raspberry Pi OS erfolgte mit Hilfe des Raspberry Pi Imager (Windows-PC). Die SSD des Raspberry Pi muss dabei vom Raspberry Pi getrennt und an den Windows-PC angeschlossen werden. Dazu ist lediglich der Doppel-USB-Stecker zwischen dem Raspberry Pi und der SSD zu entfernen und die USB-Buchse des SSD mit dem PC zu verbinden (siehe Bild). Eine zusätzliche Stromversorgung des Raspberry Pi ist dabei nicht notwendig.
   
6. Installiert wurden:
   a. Raspberry Pi OS (12, bookworm)
   b. ioBroker
   c. Grafana
   d. InfluxDB

Einspielen des iobroker-Backups:

1. Ein Zugriff auf die von backitup auf der (alten) SSD erstellten Backup-Files war nicht mehr möglich.
2. Das Einspielen der auf der NAS geretteten Files (javascripts, zigbee, iobroker) mittels des backitup-Adapters gelang problemlos, die Daten waren danach im ioBroker sichtbar.
3. Aus unbekanntem Grund verweigerte backitup die Übernahme der Backup-Files von Grafana und InfluxDB von der NAS. backitup blieb ohne Fehlermitteilung stehen.
4. Als Workaround gelang es, die Backup-Files von Grafana und InfluxDB per FTP (FileZilla) von der NAS in die Directory (/opt/iobroker/backups) der SSD des Raspberry Pi zu kopieren, in der die anderen Backup-Files (javascripts, zigbee, iobroker) schon vorhanden waren.
5. Von dort aus konnten sie mittels backitup in den ioBroker eingespielt werden.
6. Danach waren in Grafana alle Diagramme verfügbar.
7. In InfluxDB wurden alten Daten nicht übernommen, obwohl das Backupfile der Datenbank die zu erwartende Größe hatte, die Daten im Backupfile offensichtlich noch vorhanden waren! Diese Daten waren verloren.

Erfahrungen mit dem backitup-Adapter:

1. Der Aufbau des Systems auf einem zweiten Raspberry Pi erleichterte die Arbeit wesentlich durch die dann gegebene Möglichkeit der wiederholten, auch testweisen kompletten Neuinstallation ohne Verlust während des Testbetriebes.
2. Nur die auf der NAS gespeicherten Backupdaten standen zur Verfügung, alles auf der SSD des alten Raspberry Pi war verloren.
3. Eine Übernahme der Backupdaten von Grafana und InfluxDB direkt von der NAS mittels des backitup-Adapters gelang nicht. Die Übernahme dieser beiden Backups erforderte mehrere Schritte und erfolgte mittels FTP.
4. Es gelang nicht, die in InfluxDB gespeicherten Messdaten zu übernehmen.

Backup der SSD
Die schrittweise komplette Neuinstallation des Betriebssystems, der Software und der Backupdaten erforderte einiges an Zeit und innerlicher Ruhe. Um diesen Aufwand in Zukunft gering zu halten, wurde nachfolgend ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi installiert.

1. Als Speichermedium für ein komplettes Backup der SSD wurde über den freien USB-3.0-Ausgang des Raspberry Pi eine externe 1 TB - SSD ständig angeschlossen.
2. Dieser Anschluss sollte über einen aktiven Hub erfolgen, da der Raspberry Pi nicht dauerhaft und sicher über den USB-Ausgang den Strom liefert, den die externe SSD benötigt.
3. Genutzt wird für das automatisierte Backup die Software raspiBackup.
4. Die originale, umfangreiche Webseite zu raspiBackup ist:
   a. https://www.linux-tips-and-tricks.de/de/raspibackup
5. Eine empfehlenswerte weitere Webseite zu raspiBackup, die sich auf das Wesentliche konzentriert, ist:
   a. https://forum-raspberrypi.de/article/7-raspibackup-installation-grundeinstellungen-erstes-backup-und-restore/
6. Es wird im Rhythmus „3-4-12-3“ gerettet, d.h., aufgehoben werden
   a. 3 Tages-Backup
   b. 4 Wochen-Backups
   c. 12 Monats-Backups
   d. 3 Jahres-Backups
7. Die Variante „0-4-12-3“, d.h. kein tägliches Backup, sondern die Backups beginnen im wöchentlichen Rhythmus, funktioniert offensichtlich nicht. Es muss immer mindestens ein tägliches Backup erfolgen.
8. Die Backups mittels raspiBackup erfolgen nachts um 3:00 Uhr.
9. Der in raspiBackup dafür einzustellende Backuptyp ist „rsync“.
10. rsync benötigt den geringsten Speicherplatz, da hier nur die tatsächlich geänderten Daten gesichert werden und jedes Folgebackup ein inkrementelles Backup unter der Verwendung von Hardlinks ist.
11. Es ist möglich, mit raspiBackup das Backup einer größeren SSD auf eine kleinere SSD zu kopieren, wenn es der Umfang der vorhandenen Daten erlaubt.
12. Die Nutzung der Synology-NAS zur Speicherung der Backupdaten gelang nicht, obwohl von raspiBackup angeboten.

Ergebnis des kompletten Backups der SSD mit raspiBackup:

1. Mit dem Befehl
   sudo du -sh /backup/raspberrypI-4/*
   ist es möglich, die Liste der Backups und des von ihnen real belegten Speicherplatzes anzuzeigen. "/backup/raspberrypI-4/" ist dabei die Directory der Backups und muss gegebenenfalls angepasst werden.
2. Das erste Backup (20240806) ist ein Snapshot, der jederzeit händisch angelegt werden kann, dauerhaft besteht und nicht der inkrementellen Beschränkung der Anzahl der Backups unterliegt. Er verschwindet erst durch manuelles Löschen.
3. Das zweite Backup (20240816) ist eines der vier wöchentlichen inkrementellen Backups.
4. Die folgenden drei Backups (20240818 … 20) sind drei tägliche inkrementelle Backups.
5. Ein monatliches oder gar jährliches inkrementelles Backup ist noch nicht erfolgt.
6. Deutlich zu erkennen ist die Ersparnis an Speicherplatz bei der Speicherung von eigentlich nahezu gleichgroßen Backups durch die Verwendung von rsync und Hardlinks.
7. Die mit raspiBackup erstellten Backups wurden testhalber mehrmals ohne Probleme wieder eingespielt (restore).

Backup der SSD mit anderen Programmen

1. Win32DiskImager
   a. Der Win32DiskImager läuft auf einem Windows-PC.
   b. Eine Nutzung des Win32DiskImager empfiehlt sich nur für ein allererstes, einmaliges und schnell zur Verfügung stehendes Backup der SSD des Raspberry.
   c. Das Restore eines solchen Backups wurde erfolgreich getestet.
   d. Ein Nachteil dieser Variante ist die Nutzung eines fremden Betriebssystems und fremder hardware.
   e. Zum Vorgehen bei der Kopplung beider Rechner siehe Abschnitt „Erfahrungen hard- und software (Punkt 5)“ weiter oben.
   f. Win32DiskImager rettet die gesamte SSD als Imagefile, egal wieviel Plattenplatz darauf wirklich belegt ist.
   g. Es ist nicht möglich, eine größere SSD auf eine kleinere zu kopieren, auch wenn es der Datenumfang erlauben würde.
   h. Ein automatisiertes Backup ist nicht möglich.
2. SD Card Copier
   a. Raspberry Pi OS in der grafischen Version bringt im Startmenü unter „Zubehör“ den SD Card Copier.
   b. Eine Nutzung des SD Card Copier empfiehlt sich für ein einmaliges und schnell zur Verfügung stehendes Backup der SSD des Raspberry.
   c. Das Restore eines solchen Backups wurde erfolgreich getestet.
   d. SD Card Copier kopiert nur die tatsächlich vorhandenen Daten, nicht die gesamte SSD.
   e. Es ist möglich, damit eine größere SSD auf eine kleinere zu kopieren, wenn es der Umfang der vorhandenen Daten erlaubt.
   f. Ein automatisiertes Backup ist nicht möglich.
   g. SD Card Copier ist in der Kommandozeilen-Variante von Raspberry Pi OS nicht enthalten.

Fazit und Empfehlungen:
Um nach einem Crash des Raspberry Pi mit ioBroker und Totalverlust des Speichermediums (SD-Karte oder SSD) mit vertretbarem Aufwand das System wieder herstellen zu können, wird empfohlen:

1. Der backitup-Adapter des ioBrokers ist zu nutzen, er ist sicher und einfach bedienbar.
2. Alle Backupdaten müssen unbedingt auch außerhalb des Speichermediums des Raspberry Pi gespeichert werden, z.B. auf einer NAS. Das ist innerhalb des backitup-Adapters einstellbar.
3. Es ist ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi durchzuführen. Dafür wird die Software raspiBackup empfohlen.
4. Die Sicherung der mit raspiBackup erstellten Daten erfolgt auf einer externen SSD.
5. Die Nutzung von zwei Raspberry Pi ist erstrebenswert, wobei einer dem Testen (ohne Reue) und der anderen der Produktion (stabiler Lauf der Hausautomatisation) dient.

Ergänzung zu den Empfehlungen:
Simatec und homoran haben mich dankenswerteweise (s.u.) auf eine wichtige Empfehlung aufmerksam gemacht, die ich zwar in der Doku gelesen und auch befolgt hatte, aber aus den Augen verlor:
Das Restore eines Backupfiles sollte mit backitup immer lokal erfolgen, d.h. das betreffende Backupfile steht bereits auf dem Speichermedium des RaspberryPi und wird von dort mittels backitup restored.
Wenn das Backupfile von außerhalb des RaspberryPi kommt, sollte es zuerst auf das Speichermedium des RaspberryPi kopiert werden, was z.B. komfortabel mit der backitup-GUI passieren kann (auch s.u.).

@thomas-braun
Hallo,

ich denke, das ist alles schon gescheit, denn die Backups vom iobroker selbst, die von javascripts und zigbee werden ja problemlos restored, nur die von Grafana und InfluxDB machen Probleme. Ob es daran liegt, dass das eigentlich Systeme sind, die außerhalb des iobroker arbeiten, extra in Raspberry Pi OS installiert wurden?
Ob bei diesen "externen" was mit den Zugriffsrechten nicht stimmt?
Viele Grüße, jahnbes.

@thomas-braun
Wie, ich schrieb, ich habe die Synology mit FTP im Backitup-Adapter eingebunden.
Danke für Deine Reaktion, ich weiß zwar immer noch nicht, warum der übliche Weg nicht geklappt hat, da aber das workaround mit der Kopie der gewünschten Files mittels FileZilla (FTP) problemlos geklappt hat und hoffentlich auch weiter klappen wird, habe ich momentan keine Veranlassung, weiter nachzuforschen.
Viele Grüße, jahnbes.

@jahnbes
Einen workaround habe ich vielleicht gefunden. Offensichtlich funktioniert nur das downloaden nicht. ich habe die beiden backupfiles (influxdb und grafana) von der NAS auf den PC und von dort mit Filezilla auf den Raspberry kopiert.
Dann im iobroker von "local" restored und das ging!
Hast Du eine Idee, was da los ist?
Viele Grüße, jahnbes.

Hallo simatec,

ich habe ein massives Problem mit backitup und dem Backup von influxdb und grafana.

Zunächst, das restore eines Backups von iobroker und javascripts hat problemlos geklappt.

Versuche ich aber das auf der NAS vorhandene backup von influxdb oder grafana von der NAS zu restore startet das Ganze zwar, bleibt aber dann offensichtlich endlos mit dem screen

hängen. Es tut sich rein gar nichts mehr, nur der Laufbalken oben läuft.

Der Versuch in backitup das file erste einmal durch einen download local zu bekommen, gelingt auch nicht, der download startet zwar, aber es ist kein Fortschritt zu sehen, auch erscheint das file nicht unter "local":

Nur links unten pumpt (stark blau zu schwach blau usw.) die Ausschrift "Download ist gestartet". Aber es geschieht offensichtlich nichts:

Was ist zu tun? Kannst Du mir einen Tipp geben?
Viele Grüße und Dank im Voraus, jahnbes.