Nach dem Upgrade von Raspbian 9 (Stretch) auf Raspberry Pi OS 11 (Bullseye) lief mein SmartHome-System ziemlich auf Anschlag. Der Raspi 3B mit seinem 1GB RAM war dem nicht mehr gewachsen. Anscheinend benötigten die einzelnen Bestandteile mit Node 16.18 anstelle zuvor 14.20 und npm 8.19 anstelle 6.14 einiges mehr an Systemressourcen. Hmpf

What next?

Der erste Gedanke war natürlich: einen Raspberry 4 kaufen. Ich bin ja fast umgekippt: der kleine Kamerad mit 4 GB RAM kostet aktuell um die 150 EUR. WTF?! Pandemie, Lieferengpässen etc. sei Dank. Ok, das ist keine Alternative.

Glücklicherweise habe ich aber noch einen Ex-PC meines Vaters hier rumstehen, sowie einen Ex-Server meines Mannes. Die Wahl fiel auf letzteren.

Kurz vor Weihnachten widmete ich mich dem Unterfangen, und setzte den schon seit mehreren Jahren nicht mehr im Betrieb gewesenen Server neu auf mit Debian 11.

First + Second Try

Die Besonderheit an dem Rechner: Er hat zwei 3 TB Platten drin, eignet sich also für ein Raid. Mit Hilfe des Internets fand ich heraus, wie ein SoftwareRaid unter Linux konfiguriert wird. Im ersten Anlauf band ich die kompletten 3 TB (von Swap- und System-Partitionen abgesehen) ins Raid1 ein, obendrüber konfigurierte ich ein LVM.

Und er formatierte, und er syncte, und er machte und tat – omg, das Einrichten dauerte ewig und alles war elend langsam. Ich ließ ihn über Nacht mit dem initialen Sync rödeln. Obwohl dieser am nächsten Morgen fertig war, kam mir das System dennoch laaaahm vor.

Nächster Versuch: ich partitionierte die Platten mit jeweils einer 300GB Partition, den Rest ließ ich ungenutzt, und verband diese zu einem Raid1, wiederum mit einem LVM obendrüber. Das initiale Setup ging deutlich schneller, aber am Ende vom Tage fand ich die Kiste dennoch unheimlich laggy.

Ich gehe mal stark davon aus, dass ich entweder nicht geduldig genug war und initiale Prozesse noch liefen, oder dass ich irgendetwas nicht richtig konfiguriert hatte. Ich bin ja nach wie vor Linux-Laiin.

That’s It

Da ich jedoch rein für den Betrieb des iobrokers gar nicht so eine aufwendige Ausfallsicherheit benötige (Dank BackItUp ist die Wiederherstellung nach einer Neuinstallation easy+quick+dirty machbar), war die nun beibehaltene Lösung eine einfache LVM-Partition mit 300GB.

Last Call

Während ich mit dem Server rumbastelte, aktualisierte ich parallel den iobroker auf dem noch produktiven Raspi. Dank RAM-Auslastung von quasi 100% war das eine ziemliche Gratwanderung. Er stürzte mir dabei mehrfach ab, kam glücklicherweise aber immer wieder hoch. Dennoch – es war höchste Zeit, die Smart Home Basis auf leistungsstärkere Füße zu stellen. Sozusagen just in time, schätze ich mal.

Läuft!

Seit dem 23.12.22 läuft der iobroker-Server nun unauffällig und tut, was er soll. So muss das sein!

Die RAM-Auslastung liegt bei 13%, LOL , er verfügt ja auch über 8 GB. So habe ich wenigstens wieder genug Luft, um auch mal neue Adapter o.a. zu testen.

Der Umzug war nur möglich durch den „neuen“ Zigbee-Controller, der nicht mehr direkt im Raspi steckt, sondern per LAN verbunden ist:

Neuer Coordinator ist eingetroffen

Andernfalls hätte es noch die Möglichkeit gegeben, einen Master-Slave-Betrieb aufzusetzen: den neuen Server als Master mit den notwendigen Adaptern, und den Raspberry Pi als Slave, der den Zigbee-Coordinator zur Verfügung stellt. Aber das hätte wieder zusätzliche Kompliziertheit in den Aufbau hineingebracht (nein, nicht Komplexität!, schließlich wäre das ganze System weiterhin (meistens…. ) deterministisch).