Zuhause,

Umzug der SmartHome-Base

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:

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