Welches Reservesystem für Tinker Board S?

[drhwpot]

Hallo liebe Mitstreiter!

Aktuell habe ich ein Asus Tinker Board S, 16GB eMMC, Rockchip Quad-Core RK3288 Prozessor, 2GB für meine RaspberryMatic im Einsatz. Ein wunderbares und sehr stabiles System. Ich bin mit der Leistung zufrieden und es gibt eigentlich keinen Änderungsbedarf.

Da ich leider wieder einmal erleben musste, dass die Raspi & Co ohne Vorankündigung „Opfer“ von unvorhergesehenen Ereignissen werden und nicht mehr funktionieren, bin ich auf der Suche nach einer „Backup / Standby“ – Lösung.

Hierzu wollte ich mir eigentlich einfach ein Asus Tinker Board S als Reserve in den Schrank legen. Dieses ist nicht mehr verfügbar, zumindest ich konnte keines finden.

Meine Alternativen?

Tinker Board S R2.0
Dieses wird wohl nicht richtig von RM unterstützt, zumindest gibt es ein Problem mit dem USB – wenn ich die Diskussion richtig verfolgt habe. Oder übersehe ich hier etwas?

Raspberry Pi (Pi4B)
Jenseits der aktuell Beschaffungsprobleme wird der Pi4 wohl nur richtig funktionieren, wenn ich den HB-RF-ETH zu Einsatz bringe? Ich bin hier zögerliche, da ich beim Löten nicht sehr gut bin. Eine fertig verlötete HB-RF-ETH kann man wohl nicht kaufen, oder?

Synology DS 220+
Ich habe für Sicherungsaufgaben und Dateiablagen die DS im Einsatz. Ich könnte wohl eine VM für RM dort aufbauen. Dann müsste ich aber auch den HB-RF-ETH nutzen. Hier stellt sich wieder mein Löt-Problem (wenn es wirklich so groß ist, wie befürchte).

Wie kann ich ein Reservesystem aufbauen? Was sind Eure Lösungen? Was schlagt Ihr vor?

Rettung im Ernstfall – Reichen tägliche Backups?
Ist es ausreichend ein tägliches Backup von meinem System zu machen oder sollte ich mir eine „Umstiegs-Backup-Datei“ schaffen?

Was meine ich: sollte ich kein Reservesystem (Tinker Board) haben und müsste dann auf eine CCU3, Pi 4 oder auf ein virtuelles RaspberryMatic System „plötzlich“ umziehen, kann ich ja wohl mein aktuelles Backup vom Tinker Board nicht einfach einspielen. Wäre es daher sinnvoll und angezeigt wie folgt vorzugehen:
- Normales Backup unter Tinker Board
- Backup ohne Zusatzsoftware, also alle Addons vorher deinstallieren (dieses Reservebackup könnte dann die Grundlage für den Umzug sein, oder?)

Vielen Dank für Eure Unterstützung und Ratschläge!

Beste Grüße
HP

[Ukle]

Optimal wäre ja ein Asus Tinkerboard S oder auch ohne "S".
Leider sind sie nur noch selten zu haben und oft sehr teuer.
Auf ebay-Kleinanzeigen gibt es aber immer mal wieder welche zu erträglichen Preisen.

[drhwpot]

Hallo Uwe,

vielen Dank, wahrscheinlich ist der Weg über Ebay die schnellste und einfachste Lösung, das einzige Problem ist, dass diese Teile zurzeit nur aus China oder England kommen und keine Rückgabe möglich ist, wenn es nicht funktioniert – No Risk no fun…

Deiner Signatur habe ich entnommen, dass Du den HB-RF-ETH im Einsatz hast. Wie groß war der Aufwand für den Aufbau? Ist das Löten eine große Herausforderung?

Du hast das Tinker Board und die VM im Einsatz – welches System bevorzugst Du?

Beste Grüße
HP

[Ukle]

Ich persönlich bevorzuge mittlerweile die virtuelle Lösung, weil sie sehr viel flexibler ist und nicht von der Hardware abhängig ist.

Im Moment läuft meine produktive VM (HyperV (Windows Server 2019 Essentials) auf meinem eh 24/7 laufendem Server.
Als Ersatzsystem ist auf einem Intel NUC Proxmox als VM Server installiert und darauf eine RasppberryMatic VM als Host installiert.

Gerade gestern habe ich einmal einen Notfall-Schwenk-Versuch durchgeführt:

• RaspberryMatic auf dem HyperV-Server stoppen (herunterfahren)

• Intel NUC proxmox hochfahren und dort die RaspberryMatic-VM starten, aktuelles Firmware-Update einspielen und das letzte Backup einspielen

• fertg

Da beide Installationen auf das gleiche Funkmodul RPI-RF-MOD auf dem HB-RF-ETH (I-Adresse) konfiguriert ist, wird nicht einmal das Keying gestartet.
Zeitbedarf ca. 15 Minuten und der Rückschwenk in umgekehrter Richtung ca. 10 Minuten (Backup muss nich eingespielt werden!)

Das HB-RF-ETH-Modul ist relativ einfach zu löten, wenn man etwas Erfahrung hat. Die größte Lötarbeit ist die Pfostenleiste.

[Xel66]

Bei der ganzen Virtualisierung ist und bleibt auch immer das Funkmodul und seine Anbindung über Ethernet oder USB der gemeinsame Pferdefuß. Geht dort was "kaputt", steht man mit einer virtualiserten CCU genau so da, wie mit anderen Lösungen. Orientiert man sich am Originaldesign (CCU3), kann man irgendeinen Pi einsetzen, auf den das jeweilige Funkmodul passt.

Aber auch hier steht man bei einem Tausch des Funkmoduls vor dem Rekeying. Und wenn ich von 10 bis 15 Minuten lese, dann muss ich sagen, bin ich mit meinem Pi aus der Grabbelkiste incl. Umstecken des Funkmoduls, Download eines frischen Images und Einspielen eines Backups genau so schnell. Und ich habe eine single-Lösung, die unabhängig von anderer Infrastruktur ist. Irgendwie schaffen es die Virtualisierungslösungen im Falle einer Ersatz-CCU mich nicht zu überzeugen. Für andere Zwecke setze ich sowas gern ein, aber bei einer CCU ergibt es einfach keinen Sinn.

Das ist für mich ein Gerät, welches 24/7 durchlaufen muss und im Falle eines Ausfall des Admins (in dem Falle mir) auch mal wochen- und monatelang ohne weitere Wartung durchlaufen können muss. Bei den ganzen eierlegenden-Wollmilchsau-Lösungen muss man zwangsweise Updates einspielen, weil sie ja auch meist so nebenbei andere Aufgaben wahrnehmen. Da sind Sicherheitsupdates wichtig. Im Falle einer CCU nicht zwingend. Den Trend zur Virtualisierung sehe ich bei einem solchen Gerät kritisch.

Gruß Xel66

[Ukle]

Ich gebe Dir da schon recht, dass die virtuelle Lösung komplexer ist.

"Keep it simple" ist schon ein gutes Argument, aber ganz einfach ist in unserer Welt leider nichts mehr

Die Anbindung des Ethernet-Moduls ist eben nicht am Gerät sondern per LAN und somit immer ein potenteller Störfaktor - ebenso wie USB.

Ich habe das Funkmodul im CCU3-Gehäuse (HB-RF-ETH anstatt Rpi3 eingesetzt und in etwa 1m LAN-Kabel an der Fritzbox angeschlossen.

Die Fritzbox selbst ist - wie das CCU3-Gehäuse an ener kompakten USV angeschlossen und kann somit auch bei Stromausfall einige Stunden weiterlaufen.
Die LAN-Verbindung zwischen der Fritzbox zu meinem Serverschrank ist direkt und auch der ist per USV abgesichert.
Sicherheitsrelevante Updates meines Windows-Servers - meist wöchentlich - werden automatisch eingespielt und der Durchstart erfolgt geplant morgens um 3:45 automatisch.
Dabei werden alle laufenden VMs quasi "eingefroren" und nach dem Neustart im gleichen Status fortgesetzt.

Wenn ich statt des MS-Servers auf mein Intel-NUC mit Proxmox und RM-VM wechseln würde, denke ich, dass dieses Gespann auch ohne Proxmox-Updates jahrelang durchlaufen würde.

Übrigens wäre ein Ausfall der Fritzbox (fehlendes Internet und kein Telefon mehr) und dieses Windows-Servers für meine Frau in meiner Abwesenheit wegen des Ausfalls der Aufnahmen unserer Dreambox deutlich härter als die Nichtfunktion der RaspberryMatic, weil sie die Rolladen und die Heizungen weiterhin manuell steuern kann.

Sogar der Austausch einer defekten SD-Karte wäre für sie ebenso nicht durchführbar wie der Austausch der physikalischen Raspi-Platine im Störungsfall.

[drhwpot]

Hallo Mitstreiter,

vielen Dank für Eure Hinweise, sehr hilfreich.

Kurzes Update: ich habe nun ein Tinker Board als Backup bei Ebay bestellt, der Preis ist wohl in Hinblick auf die allgemeine Marktlage + mein Bedarf ok. Was zahlt man nicht alles, damit man es nie braucht. Ich betrachte es als Versicherungsprämie….

Eventuell lege ich mir noch eine HB-RF-ETH Platine zu, wobei ich hier noch nicht sicher bin, ob ich wirklich die HM / RM auf die Synology packen will. Eigentlich bin ich ein großer Freund der Systemtrennung.

Aktuell betreibe ich den Historian auf der RM / dem Tinker Board – würdet Ihr den dort lassen oder auf einen PI auslagern?

Beste Grüße
HP

[Xel66]

Aktuell betreibe ich den Historian auf der RM / dem Tinker Board – würdet Ihr den dort lassen oder auf einen PI auslagern?

Da habe ich eine ganz einfache Meinung und eine genau so Platte Begründung für. Einfach so nah wie möglich an der Originalimplementation bleiben, wenn es nicht wirklich einen zwingenden Grund für Alternativlösungen gäbe. Mir fällt nur keiner ein, denn alle "Begründungen" für den Einsatz virtualisierter Systeme wurden mit sich selbst begründet. Es gibt im Falle einer Hausautomationszentrale keinen wirklichen Vorteil für den Anwender (außer für Entwickler, die mal schnell den kompletten Unterbau wechseln können/müssen). Für mich ist eine CCU ein Gerät, welches unabhängig vom Updatebedarf eines Hostsystems 24/7 laufen muss. Und wenn ich sowieso ein abgesetzte Funkschnittstelle betreiben muss, dann kann ich anstelle des Ethernet/USB-Adapters gleich einen PI mit ins Gehäuse packen.

Der Grund für diese Empfehlung ist, dass z.B. das Raspberrymatic ein Ein-Mann-Projekt ist. Wenn jmaus aus irgendeinem Grund mal als Maintainer ausfallen sollte, hat man immer noch die Möglichkeit, auf das Originalsystem zurückzuschwenken. Bei den ganzen herumgeisternden Virtualisierungslösungen hat man diese Möglichkeit nicht so einfach (OK, Neusystem aufsetzen und Backup einspielen sollte irgendwie gehen). Ich will den Einsatz der Entwickler keinesfalls schmälern, aber ich habe schon so einige one men shows kommen und gehen sehen.

Gruß Xel66

[jmaus]

Aktuell betreibe ich den Historian auf der RM / dem Tinker Board – würdet Ihr den dort lassen oder auf einen PI auslagern?

Da habe ich eine ganz einfache Meinung und eine genau so Platte Begründung für. Einfach so nah wie möglich an der Originalimplementation bleiben, wenn es nicht wirklich einen zwingenden Grund für Alternativlösungen gäbe. Mir fällt nur keiner ein, denn alle "Begründungen" für den Einsatz virtualisierter Systeme wurden mit sich selbst begründet. [...]

Ganz ehrlich!? Es wird langsam Zeit, das du dich bitte einfach in Zukunft zu diesem Thema bzw. deinen "Glaubensantworten" bzgl. virtuell vs. real-Hardware – statt das immer wieder aufs neue gebetsmühlenartig zu wiederholen – entsprechend selbst verlinkst/referenzierst! Ich finde es inzwischen recht anstrengend bzw. ermüdend das jeder zweite/dritte Post von dir nur zu diesem Thema rausgehauen wird und du dir anscheinend nicht zu schade bist dich dauernd neu zu diesem Thema zu erklären bzw. zu äußern.

Geh doch bitte hin, schreib das einmal geordnet in einem einzelnen Beitrag nieder und dann mach in deine Signatur ein Link zu deiner Meinung zum Thema "Virtualisierung ja/nein". Bei anderen Dingen machen das andere Nutzer ja auch so und referenzieren dann diesen Beitrag inzwischen. Aber jedesmal aufs neue jeden neu aufkommenden Nutzer mit langen Beiträgen bekehren zu wollen geht mir inzwischen ein Stück zu weit und ermüdet sicherlich nicht nur mich inzwischen!

[Xel66]

Ganz ehrlich!? Es wird langsam Zeit, das du dich bitte einfach in Zukunft zu diesem Thema bzw. deinen "Glaubensantworten" bzgl. virtuell vs. real-Hardware –

Ganz ehrlich, ich schätze Deine Arbeit sehr. Aber noch ehrlicher sehe ich Dich nicht in der Position und Berechtigung, mir hier das Maul zu verbieten. Mich zu einem Thema zu äußern, wie ich das tue oder auch lasse obliegt immer noch mir. Dieses muss man in einem demokratischen System aushalten. Wir sind hier weder in einer Diktatur, noch in einer Monarchie. Und freie Meinungsäußerung beteachte ich immer noch als ein unveräußerbares Grundrecht (solange es sich im Rechtsrahmen bewegt).

Und ich persönlich halte es für einen absoluten Irrweg, Einsteigern, die teilweise schon mit schlichter Netzwerkkonfiguration überfordert sind, eine hochkomplexe Lösung anzudienen und als Optimum darzustellen. Das ist es definitiv nicht! Es macht die Bastellösung "Homematic" nur komplexer und im Endeffekt zu einem Pflegefall. Es ist nämlich genau so ermüdend, in dem Zusammenhang immer wieder Posts zu lesen, in denen selbst einfachste Probleme trotz vorhandener Dokumentation und vielfachen Lösungsbeispielen im Forum vom Anwender nicht gelöst werden können. Und das sind noch diejenigen, die ihr System selbst aufbauen. Fallen diese mal aus und das System kommt ins Stocken, kann niemand mehr helfen, wenn das System so weit von Dokumentationen entfernt ist. Diese Leute wissen gar nicht, was sie ihren Angehörigen antun. Beispiele gibt es auch hier im Forum. Und bezüglich des Topics ist nun mal sicher, dass die originale Firmware darauf nicht läuft.

Und die Wahrscheinlichkeit, dass Du als Maintainer ausfällst (auch wenn Du es nicht willst, aber nicht alles im Leben unterliegt dem eigenen Willen) und niemand das System weiterentwickelt ist nun mal auch gegeben. Davor darf man nicht die Augen verschließen. Ich sehe Hausautomation zwar auch als mein Hobby, aber eben nicht als Selbstzweck wie eine Spielzeugeisenbahn. Es ist ein integraler Bestandteil der Lebensführung, der einfach 24/7 laufen muss. Und je komplexer man dieses gestaltet, umso höher ist die Ausfallwahrscheinlichkeit. Und ich schreibe meine Statements aus diesem Grund, die Anwender für genau diesen Gedanken zu sensibilisieren, ob sie sich wirklich bei nur sehr begrenzt vorhandenen Vorteilen, diese Komplexität antun, nur weil sie mal einen Rechner rumstehen haben, der virtualisieren kann. Für Virtualisierung gibt es viele Gründe und Anwendungen, aber eine CCU (wenn ihre Programmierung geeignet ist, die Automation autark zu betreiben), ist in meinen Augen nicht geeignet dazu. Den ganzen anderen umgebenden Spielkram (Visualisierung, Datenaufzeichnung, externe Kommunikation) kann man durchaus virtualisieren. Benutzt man die CCU nur noch als Gateway zu HM(IP)-Geräten und eine überlagerte Automation als Zentralinstanz, ist der Komplexitätsgrad sowieso schon so weit "im Eimer", dass es darauf nicht mehr ankommt.

Gruß Xel66