FHEM auf QNAP TS-453D

Gear · 30 Januar 2022, 17:50:30

Guten Abend Zusammen,

ich habe seit 2 Monaten ein QNAP TS-453D (16GB RAM) und habe darauf einige Dinge im Docker laufen.
Mein FHEM läuft auf einem RPI 4 mit 2GB und ich überlege auf das QNAP umzuziehen.

Gibt es bei dem Betrieb auf einem QNAP was zu beachten?
Im Docker laufen lasse oder über Ubuntu LXD (mit Installation über die Konsole)?

Wie viel RAM und CPU Leistung möchte FHEM denn gerne haben?

Vielen Dank
Beste Grüße
Gear

Wernieman · 31 Januar 2022, 11:22:27

Unabhängig von Deinem System:
Wenn Du am Pi direkt angeschlossene Hardware hast (USB-Stick u.Ä.), hast Du bei Virtuallisierung (Egal ob VM, Docker oder sonstiges) ein Problem. Bei reiner Netzwerkhardware dagegen kein Problem.

Mann kann USB-Geräte "durchreichen", aber dieses macht es komplizierter.

marvin78 · 31 Januar 2022, 13:11:33

Zudem denke ich, dass man mit einer Hausautomation auch einiges überwacht und wenn man bedenkt, für was man eine HA in der Regel verwendet (ohne ins Detail zu gehen), ist die einzige logische Schlussfolgerung, wo man sie installiert: ein dediziertes System im eigenen Heim.

Ich verwende Docker für FHEM-Testsysteme und eine per MQTT angebundene FHEM Installation auf der Dinge laufen, die das Haupt-FHEM nicht blockieren sollen. Hier ist nichts wichtiges dabei.

joelinux · 10 Februar 2022, 11:29:26

Hallo,

das Durchreichen von USB Adaptern ist auf einem QNAP NAS ein echtes Ärgernis. Dem Linux des QNAP fehlt die Unterstützung von /dev/serial/by-id/...
Mit mehreren USB to Serial Adaptern ist nach jedem Neustart des QNAP die Belegung von /dev/ttyUSB0 oder /dev/ttyUSB1 ein Lotteriespiel. In meinem Fall ist es sowohl der Zigbee Adapter als auch der ZWave Adapter die nach jedem QNAP Neustart entweder auf /dev/ttyUSB0 oder /dev/ttyUSB1 zugeordnet werden. Meinen Rademacher Duofern USB Stick habe ich erst garnicht auf QNAP umgezogen. Der bleibt auf dem Raspberry.

Mit freundlichem Gruß

joelinux

CoolTux · 10 Februar 2022, 11:32:58

Zitat von: joelinux am 10 Februar 2022, 11:29:26
Hallo,

das Durchreichen von USB Adaptern ist auf einem QNAP NAS ein echtes Ärgernis. Dem Linux des QNAP fehlt die Unterstützung von /dev/serial/by-id/...
Mit mehreren USB to Serial Adaptern ist nach jedem Neustart des QNAP die Belegung von /dev/ttyUSB0 oder /dev/ttyUSB1 ein Lotteriespiel. In meinem Fall ist es sowohl der Zigbee Adapter als auch der ZWave Adapter die nach jedem QNAP Neustart entweder auf /dev/ttyUSB0 oder /dev/ttyUSB1 zugeordnet werden. Meinen Rademacher Duofern USB Stick habe ich erst garnicht auf QNAP umgezogen. Der bleibt auf dem Raspberry.

Mit freundlichem Gruß

joelinux

Schau mal ob Du eventuell udev auf der Kiste installiert hast.

t1me2die · 14 April 2022, 09:51:17

Moin zusammen,

bei mir läuft FHEM und div. Instanzen auf einem QNAP TVS682, Leistungstechnisch ist das 453D aber sicherlich vollkommen ausreichend.
Nach meinem Kenntnisstand sollte es auf dem 453D auch die Virtualization Station (QNAP's eigene VM Software) laufen.
In dieser VM laufen bei mir mittlerweile seit Jahren (problemlos) div. Linux Maschinen.
Alle Kisten können einfach in der VM gesichert werden und via HBS3 auch nach Extern (externe HDD, anderes RAID o.ä.) gesichert werden.
Ein Recover einer VM funktioniert reibungslos (kam bei mir schon mehrfach zum Einsatz).

Bzgl. des Durchreichens von USB Stick gebe ich Euch recht!
Gerade wenn ihr mehrere Sticks mit identischer vendor-id / product-id habt, wird es kniffelig!
Ich habe z.B. zwei BT-USB Sticks im Einsatz, der Erste wird normal für die Anwesenheitserkennung via Bluetooth verwendet, der zweite Stick wird via Bluetooth Low Energy benötigt um z.B. Beacons zu erkennen.

Damit ich bei einem Restart des QNAP nicht jedes Device händisch durchreichen muss, habe ich mir ein Shell Script geschrieben(Stichwort: "autorun.sh").
In diesem Script muss man folgende Dinge tun:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/
export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/
virsh attach-device ID-von-der-VM XML-Datei-mit-Mount-Informationen

Zu Beginn muss man zwei Export Befehle ausführen, damit man den Mount-Befehl "virsh attach-device" verwenden kann.
Anschließend sucht man sich in der Virtualization Station die ID der jeweiligen VM raus und notiert sich diese.
Anschließend erstellt man sich eine XML Datei die wie folgt aufgebaut ist:

Code Auswählen


	<hostdev mode='subsystem' type='usb'>
	   <source startupPolicy='optional'>
	      <vendor id='0xAAAA'/>
	      <product id='0xBBBB'/>
	      <adress bus='X' device='Y'/>	
	   </source>
	</hostdev>

"AAAA" und "BBBB" muss auch hier angepasst werden, außerdem muss auch noch "X" und "Y" durch Bus-Nummer und Device-Nummer aus "lsusb" angepasst werden, identische Geräte gibt (ansonsten ist diese Angabe OPTIONAL!)

Ich habe dazu eine Anleitung mal für mich selbst geschrieben, diese hänge ich gerne als PDF an, wenn Interesse besteht.

Bei Fragen, kann ich auch gerne per PN helfen.

Gruß
Mathze

Schafy · 20 Oktober 2022, 22:09:09

Hi,

ich habe das Problem, dass der FHEM Container manchmal zu hohen IO Wait Werten (~80%) auf der TS-453D führt und das komplette System ausbremst.
Logging erfolgt über DBLog auf die MariaDB. Jemand eine Idee, woran das liegen könnte?

NASVMFHEM · 22 April 2023, 09:17:10

Zitat von: Gear am 30 Januar 2022, 17:50:30... ich habe seit 2 Monaten ein QNAP TS-453D (16GB RAM) und habe darauf einige Dinge im Docker laufen.
Mein FHEM läuft auf einem RPI 4 mit 2GB und ich überlege auf das QNAP umzuziehen ...

Moin,

hast Du Dein Vorhaben erfolgreich umgesetzt?

Ich selbst habe als blutiger Laie nach ein paar anfänglichen Schwierigkeiten, die aufgrund eines Hardwaredefektes (der neu gekaufte 16 GB RAM Riegel war defekt) resultierten, dann doch endlich hinbekommen eine VM mit Debian 11 in der Virtualization Station 4 auf meinem Qnap TS 453d aufzusetzen. Auf dieser VM habe ich das FHEM mit 1-Wire-Bus an einem der 4 USB-Ports vom NAS per DS9490R und OWFS einigermaßen akzeptabel am Laufen.

Bisher habe ich aber unter anderen auch aus Zeitgründen noch nicht herausfinden können warum bei Neustart vom Qnap FHEM und OWFS nicht automatisch aktiv werden.

Gruß
NASVMFHEM

Gear · 23 April 2023, 08:07:40

@NASVMFHEM
Da mein NAS leider viel zu viel Leistung verbraucht hatte, bin ich auf einen ODroid H3 umgestiegen und das NAS wird nur wenn es benötigt wird gestartet.

NAS mit 4 HDDs (IDLE) = ~36 Watt
ODroid mit 1x NVMe + 2x SSD (IDLE) = ~8 Watt
RPi 4 (2GB RAM) mit 1x SSD (IDLE) = ~5 Watt

Hatte bedauerlicherweise die ein oder anderen Probleme mit QNAP NAS + Docker Station + FHEM.
Zudem der oben genannte Stromverbrauch...
Nachdem ich mir Homematic Geräte geholt hatte, hatte ich Probleme am NAS das vernünftig umzusetzen, dann zurück zum RPi und eine Weile überlegt bis ich auf den ODroid H3 gestoßen bin.

Auf dem ODroid läuft Debian + OpenMediaVault und ich konnte mit ein paar Schwierigkeiten dann auch RaspberryMatic in Docker zum Laufen bekommen.
https://forum.fhem.de/index.php?topic=131557.msg1257701#msg1257701

Schafy · 08 Juni 2023, 15:15:30

Hallo,

ich kämpfe gerade auch mit einem cp210x, der zwar von der QNAP erkannt und als /dev/ttyUSB0 angelegt wird, aber auf dem Container nur unter lsusb sichtbar ist. Hat da noch jemand einen Tipp für mich?

Alternativ hätte ich noch einen RasPi, der mir als N4H-Gateway dient. Dort läuft kein FHEM, aber OBIS lässt als device ja auch ein remote target zu. Da bräuchte ich nur einen Dienst serial2ip, ähnliches wie es auch der N4H-Gateway macht.

UPDATA: Habe mir mit socat auf dem Raspi beholfen