smarthome

piVCCU3 – besser als das Orginal?

Nach einigen Schwierigkeiten mit der Abdeckung der Homematic CCU3 über mehrere Stockwerke bei mir zu Hause habe ich eine für mich sehr sinnvolle Lösung gefunden: Nutzung der piVCCU3 auf Basis von Raspberry PI 4 – hätte man auch gleich so machen können… 😉

Inhalt

Die Ausgangsituation

Die Alternativen

Die Vorbereitung

Die Installation

Das Fazit

Die Ausgangssituation

Ich verwende das Homematic System schon seit mehreren Jahren. Angefangen hat es mit einer einfachen Kopplung von Heizung und Fenster in einem Zimmer. Mittlerweile habe ich ein paar kleinere Abläufe realisiert, auf die ich nur sehr ungern verzichten würde. Allerdings: Wie bei jedem Smarthome-System, das expandiert, kommt man aber irgendwann an die Grenze der Reichweite – aber zwei Schritte zurück!

Meine Anforderungen an ein Smarthome gehen vor allem in Richtung automatisierte Abläufe. Dinge wie eine Überwachungskamera, die sich abschaltet, wenn die richtigen Mobilgeräte im heimischen Netz eingebucht sind, der Sonnenauf- und -untergang im Aquarium bis hin zur Umsetzung der Auflage, dass bei Betrieb einer offenen Feuerstelle die Dunstabzugshaube nur dann funktionieren darf, wenn irgendwo ein Fenster offen ist. Alles das lässt sich mit dem von mir gewählten System sehr einfach (wichtig!!) und schnell relaisieren. Anleitungen dafür gibt es zur Genüge im Netz.

Eine wesentliche Rahmenbedingung: Das Ganze findet innerhalb meines eigenen Netzes – also hinter meiner Firewall statt. Informationen die drinnen sind, bleiben drinnen. Zugriff von außen erfolgt nicht. Damit sind cloudbasierte Dienste wie Sprachsteuerung, Cloudspeicher (außerhalb meines Nextcloudsystems) oder auch HomematicIP per Definition raus…

Ich hab eine Alexa und einen FireTV-Stick. Beide fristen ihre düsteres Dasein, abgetrennt von jeglichen Netzverbindungen, in der Schreibtischschublade – ein Zustand, der sich in absehbarer Zeit nicht ändern wird…

Was sich aber geändert hat, war die Anzahl der Komponenten, die ich zur Überwachung und Automatisierung von Klima, Heizung und Sicherheit eingesetzt habe. Damit bin ich mit der CCU2 recht schnell an die Grenzen gestoßen. Die CCU3 hat das Ganze dann etwas verbessert, aber mittlerweile war ich dann auch hier ziemlich schnell an der Grenze des Möglichen. Also musste die Reichweite erhöht werden.

zurück zum Inhaltsverzeichnis

Die Alternativen

Um dieses Problem zu beseitigen gibt es mehrere Optionen:

  • Umstellung auf HomemticIP und Verwendung der verfügbaren Extender: HomematicIP bietet die Möglichkeit, die Kommunikation von HomematicIP Komponenten unter Verwendung von Extendern (schaltbare Steckdosen, die als Router fungieren können) zu verbessern…. Jaaaaaa… Aaaaber das würde bedeuten, alle nicht IP-Komponenten auszutauschen. Das sind bei mir einige. Außerdem traue ich per Definition keinem System, das Teile meines Netzes dem Zugriff von außen öffnet. Sorry eQ-3 – wird nicht passieren!
  • Verwendung eines Funk LAN Gateways: Dieses Gerät, dass bestimmt nur zufällig genauso aussieht, wie eine CCU2, wird per Netzwerkkabel ins gleiche Netz gebracht wie die existierende CCU3. Die Komponenten werden dann entsprechend der Verbindungssituation zugeordnet und Gateway und CCU3 managen dann die Kommunikation. Da ich OpenHAB zur Verbindung von NichtHomematic-Geräten einsetze, und nichts zu dem Thema „mehrere Gateways mit OpenHAB“ gefunden habe (Vermutung ist, dass zumindest eine extensive Anpassung der vorhandenen Skripte nötig ist…), war ich mir nicht ganz sicher. Die Tatsache, dass ein LAN-GW beinahe so viel kostet wie eine CCU UND ich an der zukünftigen Position eine Netzwerkdose benötige, hat die Entscheidung dann recht einfach gemacht.
  • Verwendung von piVCCU3 auf Raspberry PI 4: Zugegeben – das ist nicht wirklich als eine eigenständige Alternative gedacht gewesen. Eher eine Möglichkeit, Variante 2 auf kontrollierte Art und Weise umzusetzen. Der Plan war, die piVCCU3 auf Basis Raspberry 4 aufzubauen, die CCU3 zu ersetzen (weil Paspi 4 viel schneller und so…) und mit der CCU3 dann das LAN Gateway umzusetzen, so wie in diesem Artikel und in diesem Artikel beschrieben.

zurück zum Inhaltsverzeichnis

Die Vorbereitung

Zuerst müssen ein paar Kleinigkeiten beschafft werden:

  • Ein Raspberry Pi 4 (in meinem Fall die Variante mit 4 GB RAM – völlig ausreichend…)
  • Ein Netzteil (ein USB-C Kabel und eine entsprechende Stromquelle tun es vermutlich auch)
  • Ein Kühler für den Raspberry (den fand ich gut, weil er gleich die Verlängerung für die Pinbank mitbringt)
  • Das Funkmodul (HM-MOD-RPI-PCB) als Bausatz. Wer nicht löten will oder kann – das gibt es auch fertig.
  • Eine MicroSD Karte (haben die meisten vermutlich eh daheim herumliegen – bei mir war es eine 16GB Karte).

Danach muss die aktuelle Variante von Raspbian heruntergeladen werden und auf die MicroSD aufgespielt werden. Auf der Downloadseite von raspberrypi.org finden sich dafür Imager für diverse Betriebssysteme. Ich persönlich bevorzuge Rufus für diesen Zweck.

Alternativ kann man anstelle von Raspbian und der nachfolgenden Installation auch direkt ein Image mit piVCCU3 vewenden. Dann spart man sich den Folgeschritt.

zurück zum Inhaltsverzeichnis

Die Installation

Wenn man den Weg mittels Raspbian und manueller Installation von piVCCU3 gewählt hat, findet man hier eine detaillierte Beschreibung, welche Schritte zu durchlaufen sind.

Alle Infos zum Thema piVCCU3 und eventuell auch Kontakt zum Ersteller findet man hier.

Der Umstieg von der alten CCU3 auf die neue piVCCU3 ist in diesem Artikel sehr gut beschrieben. Unbedingt lesen!

zurück zum Inhaltsverzeichnis

Das Fazit

So weit, dass ich die CCU3 zum Gateway umbauen musste ist es nie gekommen. Mit der piVCCU3 sind meine dauerhaften Servicemeldungen und Verbindungsabbrüche verschwunden, obwohl sich sonst nichts geändert hat. Weder der Standort noch die Umgebung. Die Migration sowohl der Komponenten (ging nahtlos) als auch die Integration in den bestehenden openHAB (neuer Scan – und alles lief direkt weiter) war völlig stressfrei.

Alles in allem eine klare Empfehlung. Und wenn es nicht klappt, könnt Ihr immer noch ein Gateway aufbauen.

zurück zum Inhaltsverzeichnis

QNAP-NAS: Raid-Disk wird als Reserve erkannt, obwohl sie aktiv sein sollte

Hallo zusammen,

kurz vor dem Jahresabschluss hatte ich ein kleines Problem mit meinem QNAP-NAS:

Während das System eine der Festplatten neu aufgebaut hat, beschloss meine USV, dem NAS den Befehl zum herunterfahren zu geben, was dieses auch prompt tat.

Resultat: Der RAID-Controller war verwirrt und das RAID5 somit unbrauchbar.

An dieser Stelle möchte ich mich bei den diversen „Datenrettungsexperten“ – ja, die meisten davon tauchen ganz weit vorne in der Googlesuche auf – bedanken, die mir nach ihren „Analysen“ diverse Horrorszenarios geliefert haben, die nichts mit dem zu erkennenden Fehlerbild zu tun hatten und mich durch ihre Angebote zur Datenrettung von etwa 15.000 (in Worten: Fünfzehntausend!!) Euro für die Standardlösung bzw. 6000 EUR, wenn ich bereit bin, 3-4 Monate zu warten, nachhaltig dazu motiviert haben, mein Problem selbst zu lösen.
(Nicht falsch verstehen: Wenn mir jemand sagt: RAID-Wiederherstellung kostet 10.000EUR, dann ist das ehrlich und okay – jeder macht seine Preise selbst. Wenn mir aber wilde Stories geliefert werden, und die „kundenspezifische“ Lösung angeblich so aufwendig ist, dann ist das für mich nahe am Tatbestand der arglistigen Täuschung).

Noch einmal vielen Dank dafür – die 500 EUR Analysekosten betrachte ich als Lehrgeld!

Bevor ich jetzt anfange, die Lösung zu beschreiben, noch einige grundlegende Dinge:

  • Arbeitet nie mit dem Original: Ich hab mir bei dem Wiederherstellungsprozess die Kopien meiner Festplatten mehrfach zerschossen, bevor der Workflow funktioniert hat. Ein paar Ersatzfestplatten kosten nicht die Welt (verglichen mit der Alternative, s.o.) und die 35 EUR für die Kopierstation (z.B https://www.amazon.de/gp/product/B011NUPSCA/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 ) waren auch gut angelegt.
  • Markiert Eure Festplatten – die Reihenfolge, die die Platten im RAIDverbund hatten sind essenziell wichtig.
  • Das NAS nicht neu starten – die QNAPS haben die dumme Eigenschaft, dann die anwesenden Festplatten wahlweise platt machen zu wollen oder alles auf Werkseinstellungen zurückzusetzen. Das macht alles nur komplizierter.
  • Nehmt die Festplatten nach der Analyse raus, macht Euch eine Kopie und legt das Original zur Seite. Ihr braucht es als Grundlage für weitere Kopien, wenn was schiefgeht oder – wenn alles Stricke reißen und Euch die Daten so wichtig sind – um einen der oben genannten Kollegen zu bemühen…
  • [Update] Lest Euch im VORFELD die folgende Seite durch: https://wiki.ubuntuusers.de/Software-RAID/ . Eventuell findet Ihr hier schon eine einfache Lösung für Euer Problem. Auf jeden Fall hilft es zu verstehen, was Ihr tut.

Jetzt aber zur eigentlichen Lösung:

Als erstes benötigt Ihr einen Konsolenzugriff auf das NAS. Also Putty herunterladen (http://www.putty.org/ ), IP-Adresse des NAS, Port 22 eintragen, verbinden, als admin anmelden und Ihr seid im Rennen.

Im nächsten Schritt müsst Ihr herausfinden, auf welchen Partitionen Eure Daten liegen.

Mit

ls /dev/sd*

bekomm Ihr eine Liste mit allen Partitionen, die aktuell auf dem System vorhanden sind. Im nächsten Schritt schaut Ihr Euch eventuell vorhandene Superblocks auf diesen Partitionen an:

mdadm --examine /dev/sdXn

Das X müsst Ihr durch den Buchstaben für die jeweilige HDD ersetzen, das n durch die Nummer der Partition. Zum Beispiel:

mdadm --examine /dev/sda3

Als Ergebnis bekommt Ihr dann hoffentlich etwas, das so aussieht:

Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 6e16c374:46c69b71:bc77c868:069371e2
Name : 0
Creation Time : Fri Jan 16 07:58:21 2015
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 7810899112 (3724.53 GiB 3999.18 GB)
Array Size : 15621798144 (14898.11 GiB 15996.72 GB)
Used Dev Size : 7810899072 (3724.53 GiB 3999.18 GB)
Super Offset : 7810899368 sectors
Unused Space : before=0 sectors, after=296 sectors
State : clean
Device UUID : 61479a3c:76b05353:1a7e0713:ee1d4d9b

Update Time : Thu Nov 3 14:31:33 2016
Checksum : 29591b87 – correct
Events : 81892

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 0
Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)

Ihr werdet mehrere solcher Blocks finden. Aber nur eines je HDD beinhaltet Eure Daten. Erkennbar am einfachsten an der Größenangabe unter „Array Size“. Ich hab den ganzen Kram dann jeweils ins Notepad++ kopiert, und hatte nachher eine schöne Übersicht über meine Festplatten.

Ihr braucht außerdem die Angabe unter „Chunk Size“ sowie die „Device Role“. Letztere gibt Euch eine Aussage darüber, an welcher Stelle sich die Platte im RAID-Verbund befunden hat (hier die erste Platte).

Das Ergebnis der fehlenden Platte sah bei mir so aus:

sdd3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 6e16c374:7b4c1961:bc77c868:069371e2
Name : 0
Creation Time : Fri Jan 16 07:58:21 2015
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 7810899104 (3724.53 GiB 3999.18 GB)
Array Size : 15621798144 (14898.11 GiB 15996.72 GB)
Used Dev Size : 7810899072 (3724.53 GiB 3999.18 GB)
Super Offset : 7810899368 sectors
Unused Space : before=0 sectors, after=288 sectors
State : active
Device UUID : cd0c0b7e:b0514866:041b0d10:38d519f3

Update Time : Thu Nov 3 14:31:33 2016
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : d2979675 – correct
Events : 0

Layout : left-symmetric
Chunk Size : 64K

Device Role : spare
Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)

Ihr seht: Das Ding wurde als „spare“ gekennzeichnet, sollte aber eigentlich „active device 3“ sein!

Bei QNAP gibt es eine Festplatte, die nicht im Datenverbund ist. Darauf befinden sich das Betriebssystem und andere Systeminfos. Die hat keinen Superblock. Für alle anderen Festplatten solltet Ihr wenigstens einen Superblock finden, der die ARRAY UUID des Datenarrays hat. Ansonsten funktioniert das Ganze nicht.

Bevor wir zum Zusammensetzen des RAIDs kommen, solltet Ihr Euch Gedanken machen, wo ihr Eure Daten hinschreiben wollt, wenn Ihr denn Zugriff darauf habt. Ich hatte einen Slot frei (6 HDDs möglich, nur 5 im Array), die ich im QNAP FrontEnd als Speicherpool eingebunden habe.

Wichtig – diese Platte muss genug Speicherplatz haben, um alle Eure Daten aufnehmen zu können. Wenn das nicht klappt, könnt Ihr externe Festplatten per USB anschließen und die Daten darauf verteilen.

So… jetzt geht’s aber ans Eingemachte.

Ihr habt die relevanten Partitionen in der richtigen Reihenfolge parat, Ihr kennt die Chunk Size, RAID Level, Anzahl der HDD,…

Es fehlt das Filesystem Eurer Partition:

blkid | grep sda3 | awk '{print $3}'

…wirft Euch am Ende sowas aus wie:  TYPE=“ext4″

Jetzt braucht Ihr noch eine freie Bezeichnung für Euer neues RAID.

ls /dev/md*

liefert Euch eine Information, welche Bezeichnungen bereits vergeben sind. In meinem Fall waren das:

md13 md256 md9

Das neue Raid hab ich dann also md5 getauft. Das könnt Ihr frei wählen.

Der Befehl zum Zusammenbau des RAIDs ist:

mdadm -Cv /dev/md5 --assume-clean -l5 -n5 -c64 /dev/sd[cdefg]3

MDADM ist der Befehl mit dem man in Linux Raidsysteme administriert. Man benötigt Root-Rechte zur Ausführung, also im Zweifel ein sudo voranstellen. Wird aber als admin auf dem QNAP nicht gebraucht.

-C steht für „create“, also ein neues RAID erstellen.
-v -> verbose: Ich will sehen, was passiert
/dev/md5 ist die Bezeichnung des neuen RAIDs
–assume clean bringt den eigentlichen Mehrwert bei der ganzen Aktion. Normalerweise würde das System sagen, dass nicht genügend HDDs zur Wiederherstellung des RAIDs vorhanden sind. Mit „assume clean“ wird die „Reserveplatte“ als aktiv behandelt und das RAID kann aufgebaut werden.
-l ist das RAID-Level. Findet Ihr als Information im Superblock – bei mir Level 5
-n ist die Anzahl der beteiligten Laufwerke – in meinem Fall 5
-c ist die Chunk Size aus dem Superblock. In meinem Fall 64
/dev/sd[cdefg]3 gibt die Partitionen in der richtigen Reihenfolge an. Hier also jeweils die Partition der Festplatten sdc3, sdd3, sde3, sdf3, sdg3. Man kann es auch trennen. Hier noch mal ein Beispiel eines Raid 1 mit 2 Festplatten (sdc3 und sdd3):

mdadm -Cv /dev/md5 --assume-clean -l1 -n2 -c64 /dev/sdc3 /dev/sdd3

Genauere Infos findet Ihr hier: https://linux.die.net/man/8/mdadm

Ihr werdet gefragt, ob das RAID jetzt erstellt werden soll. Mit „y“ bestätigen und wenn alles gut geht, bekommt Ihr die Meldung, dass das RAID gestartet wurde.

Im nächsten Schritt muss das RAID gemounted werden. Dazu braucht Ihr ein Verzeichnis, das nachher als Mountpunkt dient. Also z.B.:

mkdir /home/raid

Das ist der Punkt, an dem Ihr später hoffentlich Eure Daten wiederfindet. Hier hängen wir jetzt das RAID ein. Ich habe die leidvolle Erfahrung gemacht, dass jeder Versuch, die Daten zu verändern zu einem Verlust des RAIDs geführt hat. Also machen wir das Ganze schreibgeschützt:

mount -t ext4 -o ro /dev/md5 /home/raid

das „ext4“ ersetzt Ihr durch das, was Ihr vorher beim Auslesen des Filesystems Eurer Platten gefunden habt. Eure Daten sollten jetzt im Verzeichnis /home/raid zu sehen sein:

ls /home/raid

Wenn das der Fall ist, dann habt Ihr den schwierigsten Part überstanden. Jetzt müssen die Daten nur noch an einen anderen Ort kopiert werden:

cp -av /home/raid /share/CACHEDEV1_DATA/

Unter /share/CACHEDEV1_DATA habe ich die Festplatte laufen, die die Daten aufnehmen soll. Ihr müsst hier natürlich das Ziel eintragen, wo Eure Daten hin sollen. Der Kopiervorgang hat bei mir satte 12 Stunden gedauert für 3,8TB. Wenn Ihr nicht alles auf eine Platte bekommt, dann kopiert nur einen Teil der Daten, wechselt dann das Laufwerk und kopiert dann den Rest.

Jetzt könnt Ihr Euch ein neues RAID anlegen und die gesicherten Daten wieder zurückspielen.

Am meisten geholfen hat mir dieser Beitrag hier: http://www.linuxquestions.org/questions/linux-server-73/mdadm-re-added-disk-treated-as-spare-750739/

Den Beteiligten vielen Dank, Euch viel Erfolg!