Verständnisfrage: Umzug von RPi3 auf NUC10 bzw. DS720+

[deimos]

Hi,

es gibt USB over IP Extender, die brauchen Treiber und mir ist keiner bekannt, welcher auch Linux Kernel Module anbietet, sind alle nur für Windows.
Und es gibt USB over CAT Extender, die dürfen nicht über aktive Komponenten laufen, sondern nutzen das Netzwerkkabel als Art Verlängerungskabel. Die brauchen keine Treiber, weil sie genau so transparent in der USB Kommunikation sind, wie eine USB Verlängerung.

Letzere habe ich sowohl mit der HB-RF-USB, als auch mit der HB-RF-USB-2 getestet. Lief vollkommen problemlos, aber das kommt sehr stark darauf an, welches Netzwerkkabel man hat. Die Reichweite in den Werbeaussagen stimmt aber definitiv nicht, deutlich mehr als 10-15m darf man da nicht erwarten.

Die HB-RF-ETH kann als echtes Netzwerkgerät dann deutlich weiter, ich habe es noch nicht getestet, aber eigentlich müssten da mehrere hundert Meter drin sein bei Nutzung meherer Switche.

Viele Grüße
Alex

[jmaus]

Bist du sicher, dass Treiber benötigt werden?

Na ich denke schon, denn ein USB Extender wird ja via USB an das RaspberryMatic System irgendwie angesteckt. Da müsste ja dann irgendein device dabei via udev entstehen, das man dann wiederum erst einmal der RaspberryMatic als Device zum Funkmodul beibringen müsste. Und mir ist nicht bekannt das es USB extender gibt die ohne Treibersoftware funktionieren die man vor Nutzung dieses Extenders (z.B. auf einem Windows System) installieren muss.

[Josh]

OK, das mit den Treibern macht Sinn, wenn RM das nicht von Hause aus implementiert hat.

Welche Treiber würden denn benötigt. Wenn ich das richtig sehe, basiert RM auf Aarch64-Linux. Kann da "jeder" Linux-Treiber für das USB2LAN-Interface genutzt werden? Oder muss da ein Aarch64 spezieller Treiber genutzt werden? Sorry für die vielleicht blöde Frage, aber bei Linux bin ich nicht sooo tief drin...

[Xel66]

... aufgrund besserer Ausfallsicherheit und Backup von meinem RPi3 auf einen Intel NUC mit Proxmox oder eine DS720+ umziehen.

Diese Logik muss man sich mal auf der Zunge zergehen lassen. Man hat ein einfaches dediziertes kostengünstiges "einfaches" System Pi, SD, Funkmodul, Netzteil, welches man auf Grund der Baugröße und des lüfterlosen Betriebes auch flexibler positionieren kann. Steigt eine der Komponenten aus, besorgt man sich ein Ersatzteil (zur Not bis auf das Funkmodul aus der Grabbelkiste) und weiter geht es. Wem ein Mal irgendwas Relevantes an einem Wochenende oder Feiertag kaputt gegangen ist, weiß was ich meine. Dieses überschaubare Gerätekonglomerat wird ersetzt, durch eine physikalisch größere und lautere Hardware, auf der auch prinzipbedingt mehrere Dienste parallel laufen und die gegebenenfalls auch aus dem Internet erreichbar ist (ja, ich weiß, dass man eine eigene IP zuweisen kann). Steigt dort mal was aus, ist die kurzfristige Ersatzteilbeschaffung ungleich schwerer, man hat um Dimensionen mehr Administrationsaufwand (OS des NAS, Virtualisierungsumgebung, Raspberrymatic), um eine lauffähige Installation wiederherzustellen, man hat mehr Geräte, man hat mehr funktechnischen Störnebel, man hat zusätzliche Kabelverbindungen. Meine Hausautomation als nicht sicherheitsrelevantes Gerät kann ich auch mal mehrere Monate ohne ein einziges Update oder einen einzigen Reboot betreiben. Ein NAS, welches ggf. auch "von außen" erreichbar ist, sollte man schon up to date halten, was je nach Update-Kategorie auch mal einen kompletten Reboot benötigt. Die Hausautomation ist dann zwangsweise down.

Inwiefern ein solch technisch komplizierterer Lösungsansatz gegenüber einem "einfachen" System eine bessere Ausfallsicherheit bieten soll, bleibt zu klären. Und mit einer 08/15 USV kann man einen Pi auch weitaus länger betreiben (um Probleme durch temporäre Stromausfälle zu umgehen). Die einzige Steigerung der Ausfallsicherheit betrifft das zugrundeliegende Speichermedium. Da im Allgemeinen aber auf der SD nicht permanent rumgeschrubbt wird, sind bei Verwendung hochwertiger Karten und gelegentlichem Wechselbetrieb bei Systemupdates, die Ausfallwahrscheinlichkeit auch anders zu bewerten. Und im Fall der Fälle ist bei vorhandenem Backup ein laufendes System in wenigen Minuten wiederhergestellt (definitiv unter einer viertel Stunde). Und für "ausfallsicheres" Backups kann man problemlos ein Verzeichnis eines NAS in der RM mounten und die Backups dahin wegschreiben. Meines Erachtens verglichen mit einer Virtualisierung ein verschwindend geringer Administrationsaufwand.

Ich behaupte mal, bezüglich der Ausfallsicherheit gewinnt man durch ein solches Konstrukt gar nichts, bzw. erkauft sich diese (ausschließlich bzgl. des Speichermediums) mit massiv erhöhtem Administrationsaufwand. Ob einem das wert ist, soll jeder für sich bewerten. Ich wollte nur mal einen Denkanstoß bezüglich der immer wieder vorgetragenen pauschalen Behauptung der Vorteile eines solchen Lösungsansatzes hinterlassen. Meines Erachtens versprechen die Anwender sich zu viel davon. Solche eierlegenden Wollmilchsäue vereinen zwar viel Vorteile in einem Gerät, sind aber trotzdem immer eine Kompromisslösung gegenüber dedizierten Systemen. In technischen Systemen wird zur Steigerung der Ausfallsicherheit auf Diversität und Redundanz gesetzt. Solche eierlegenden Wollmilchsäue als single points of failure bringen es eher nicht. Auf mein (ggf. ausgefallenes) NAS kann ich als Privatanwender locker mal mehrere Tage bis Wochen verzichten, auf meine Hausautomation möchte ich es aus Komfortgründen eher nicht (obwohl es auch gänzlich ohne geht). Noch dazu kommt immer noch der Fall der Fälle, dass der Admin ausfällt. In einem solchen Konstrukt hat kein noch so ambitionierter Helfer eine Chance. Eine Raspberrymatic aufzusetzen ist eine eher überschaubare Aufgabe. Normal so als Denkanstoß.

Gruß Xel66

[onliner]

Hallo Xel66,

Ich stimme deinen Ausführungen zu mehr als 100 % zu. Ich betreibe seit Jahren zwei Raspberrymatic-Systeme, eins auf einem Tinkerboard und eins im Fernbedienung auf einem Raspi 3b. Ausfallsicherer und minimalistische geht es nicht und das bei den vielen Möglichkeiten die das System bietet. Bisher habe ich noch keine SD-Karte ersetzen müssen. Auch die Einrichtung bzw. die Pflege beider Systeme ist mit sehr geringem Zeitaufwand nötig. Ich käme eigentlich nie auf den Gedanken das Zeitsystem im Ferienhaus durch einen Intel Nuc oder ähnlichem zu ersetzen.

Gruß Onliner

[Josh]

hmmm... stimmt eigentlich, wenn man nur die Ausfallsicherheit und das Backup sieht. So hatte ich es ja auch geschrieben.

Es gibt aber auch noch andere, bisher nicht genannte Aspekte. Der RPi mit RM steht bei meiner Schwester in der Wohnung, weil diese zentral im Haus steht. Da will ich nicht immer rein, wenn man was mit dem Update via WebGUI nicht klappt. Hatte ich in letzter Zeit immer wieder Probleme. Deshalb tausche ich lieber die SD-Karte. Da könnte ich zur Not die alte wieder reinstecken. Mit einer VM wäre es komfortabler. Und wenn ein via LAN angestecktes Funkmodul möglich wäre, könnte ich sowohl auf dem NAS als auch auf dem NUC eine VM mit RM vorinstalliert haben. Fällt ein Gerät aus, wäre das andere sofort bereit.
Außerdem habe ich im Haus ein halbes Duzend RPis stehen. Die wollte ich sukzessive in VMs verbannen, wenn's klappt. Da das NAS immer läuft wäre hier eine Stromersparnis zu erwarten.

Ich bin aber noch in der Findungsphase. Vielleicht lasse ich es auch... Mal sehen. Ich warte jetzt erst Mal auf die Implementierung des ETH-Moduls.

Danke für Deine Eingebung

[jmaus]

... aufgrund besserer Ausfallsicherheit und Backup von meinem RPi3 auf einen Intel NUC mit Proxmox oder eine DS720+ umziehen.

Diese Logik muss man sich mal auf der Zunge zergehen lassen.
[...]
Inwiefern ein solch technisch komplizierterer Lösungsansatz gegenüber einem "einfachen" System eine bessere Ausfallsicherheit bieten soll, bleibt zu klären.
[...]
Meines Erachtens verglichen mit einer Virtualisierung ein verschwindend geringer Administrationsaufwand.
[...]
Eine Raspberrymatic aufzusetzen ist eine eher überschaubare Aufgabe. Normal so als Denkanstoß.

Auch wenn ich deinen Ausführung natürlich folgende kann und prinzipiell auch verstehe worauf du hinaus willst (Ein einzelner RaspberryPi ist schnell mal gegen einen Ersatz im Schrank tauschbar), so gibt es bei all diesen Dingen doch wie immer eine große Bandbreite bzgl. aller Für- und Wieder. Und meiner Meinung nach sollte man schon genau auf den einzelnen Anwendungsfall/Nutzungfall schauen und auch darauf welches KnowHow ein einzelner Nutzer so mit sich bringt. Und so gibt es IMHO sehr wohl sehr gute Gründe, statt auf einen einfachen RaspberryPi zu setzen, auf Virtualisierungslösungen wie OVA auch bzgl. einer Hausautomation zu setzen. Und genau aus diesem Grund bringt RaspberryMatic ja genau diese Bandbreite an unterstützten Platformen mit sich und wird wohl (so wie es aussieht) mit der nächsten kommenden Version um eine virtuelle Platform reicher werden. Nämlich um die Möglichkeit RaspberryMatic auch als Docker-Container auf seinem existieren x86 bzw. RaspberryPiOS betriebenem System parallel zu anderen Anwendungen zu starten (siehe viewtopic.php?f=65&t=64314). Und auch da kann man natürlich wieder Argumente dagegen vorbringen, doch man bedenke auch dabei, dass auch hier es mindestens genausoviele Gründe gibt darüber nachzudenken vielleicht in seinem speziellen Anwendungsfall doch auf eine Docker Variante zu setzen. Und persönlich bin ich froh, dass RaspberryMatic inzwischen (vor allem durch die Unterstützung verschiedenster Entwickler ohne die das nicht in dem Maße möglich wäre) so breit aufgestellt ist, sodass sich jeder für seinen Anwendungs/Nutzungfall die für sich beste Lösung herauspicken kann!

[Xel66]

...doch man bedenke auch dabei, dass auch hier es mindestens genausoviele Gründe gibt darüber nachzudenken vielleicht in seinem speziellen Anwendungsfall doch auf eine Docker Variante zu setzen.

Es gibt definitv Gründe, RM in einer virtualisierten Umgebung zu betreiben. Entwicklungsarbeit ist ein solcher. Leider werden aber durch die omnipräsenten Varianten auch Anwender dazu animiert, ihr System ohne jegliche Not und jeglichen wirklichen Gewinn zu virtualisieren, nur weil sie ein NAS haben, welches 24/7 durchläuft. Diese Anwender setzen das dann mit Hilfe der Anleitungen aus Foren und Internetseiten durch reines Nachklicken um (im Lowlevel finden wir das hier schon in der ganz normalen WebUI).

Diese Anwender sind dann aber meistens bei den kleinsten Problemen massivst überfordert und können sich nicht mehr selbst behelfen, wenn mal was aufgrund von Weiterentwicklungen oder Änderungen nicht mehr exakt so läuft wie ehedem dokumentiert. Vor diesem Problem stehen hier Forenmitglieder tagtäglich, die irgendeine ihrer Lösungen als Nachklickanleitung der Comunity zur Verfügung gestellt haben. Hier entsteht dann Supportaufwand, weil die Anwender die zugrundeliegenden Funktionen nicht verstanden haben und somit die vorgestellte Lösung nicht auf die eigenen Bedüfnisse anpassen können.

Aber ich schrieb ja schon, soll jeder machen wie er will, solange er sich über die Konsequenzen im Klaren ist. Ich gebe hier auch regelmäßig den einsamen Rufer in der Wüste, wenn Anwender ihr System durch die Integration eines bunten Hersteller-Potpourrie maximal bis zur Unwartbarkeit verkomplizieren. Fallen diese Anwender dann mal als Maintainer aus, dann steht der Rest der Familie bei Problemen auf verlorenem Posten. Aber das will so richtig niemand wahr haben. Smarthome benötigt Pflege, umso mehr, wenn es kompliziert aufgebaut ist.

Gruß Xel66

[onliner]

Deshalb auch meine mehr als 100 % Zustimmung, ich habe auch ein NAS auf dem ich locker Raspberrymatic laufen lassen könnte, aber ich lebe nicht alleine auch wenn das System sehr zuverlässig läuft möchte wenn es mal ein Problem geben sollte mein Ehefrau nicht im Regen stehen lassen. Sie kann wie ich ja schrieb diese minimalistische Installation ohne große Eigenkenntnis wieder in Betrieb nehmen sollte ich mal nicht da sein oder zu erreichen sein. Das heißt nicht das ich andere Installationen schlecht reden möchte. Aber ich habe zu Hause einige Geräte, Programme und verbaute Wandtablets am Start, dass ist für nicht eingeweihte bzw. Außenstehende schon kompliziert genug, käme dann noch eine komplizierte Installation des gesamten Systems dazu wird das nicht klappen, so ist es einfach geht was schief SD-Karte raus neue liegt immer bereit, SD-Karte rein und läuft.

[Xel66]

Aufgrund negativer Erfahrungen (meine CCU hat wegen einer fehlerhaften Einrichtung die Programme teilweise nur noch mehreren Minuten Verzögerung abgearbeitet), hatte ich zu CCU2-Zeiten dann immer eine Reseve-CCU im Regal. Diese hatte immer die Vorversion der Firmware und einen stabilen Programmzustand drauf und konnte alternativ beim Ausfall der produktiven CCU angeschlossen werden. Dazu waren meine Frau und mein Sohn in der Lage.

Kam eine neue Firmware raus, wurde ein Backup gezogen, die CCU ins Regal gelegt, die aus dem Regal angeschlossen, geupdatet und das Backup eingespielt. Hat sich ein Systemzustand als langzeitstabil herausgestellt, wurde auch mal zwischendurch getauscht, wenn lange keine neue Firmware erschienen ist. Jetzt mache ich den Tausch wechselweise mit der SD und identischer Hardware.

Gruß Xel66