Ich brauche mal Unterstützung oder Tipps von Euch. Wahrscheinlich ist es nur eine Kleinigkeit.
Ich bekomme meine USB-Dongels nicht durchgeschliffen.(Meine Fragen habe ich unten formuliert. Ich bin Linux Anfänger.)
Ich zeige mal was ich bisher gemacht habe. Das ist bewußt schon als Anleitung formuliert (aber leider noch nicht fertig...) Vielleicht hilft das später dem ein oder anderen auch und ermuntert zu Proxmox.
Sobald das klappt und rund ist, bereite ich gerne eine Anleitung für das Wiki vor.
Ich habe einen Nuc 7. Generation mit I3 Prozessor
Darauf läuft Proxmox und in einem LCX Container läuft Ubuntu 16.04 LTS.
Die FHEM Installation habe ich gemäß dieses schönen Tutorials gemacht:
https://debian.fhem.de/ (https://debian.fhem.de/)
Vielen Dank an betateilchen!
FHEM läuft schonmal und ich kann z. B. mit meinen HMLANs meine Homematic-Geräte schalten.
FTP läuft, Samba läuft
Backups vom proxmox zu meinem Synology NAS gehen ebenfalls.
Jetzt habe ich die Herausforderung, dass ich die USB-Dongels nicht sauber vom Host zum Gastsystem (Container) durchgeschleust bekomme.
Ich habe nun zwei Tage erfolglos gefühlt das ganze Internet leergelesen. ::)
Vielleicht vorab, nicht, dass es daran schon scheitert.
Auf dem proxmox arbeite ich mit dem User root.
Auf dem Container arbeite ich mit dem User pi.
Meine folgenden Ausführungen halten sich generell an dieses Vorgehen:
https://deviantengineer.com/2016/11/lxc-passthrough/ (https://deviantengineer.com/2016/11/lxc-passthrough/)
1. Erkennung meiner USB-Geräte auf dem proxmox Host und notieren der wichtigsten InformationenFolgendes per Konsole auf dem Proxmox Host
lsusb Ausgabe merken
ls -la /dev/ttyACM*
und
ls -la /dev/ttyUSB*Ausgabe merken
Gerät anstecken und alle Befehle wiederholen.
Jeweils den alten Stand mit der neuen Ausgabe vergleichen.
Das neu dazugekommene Gerät können wir nun so identifizieren
lsusbdas Gerät was dazugekommen ist (hier mein ZWAVE Stick)
Bus 001 Device 020: ID 0658:0200 Sigma Designs, Inc. (notieren!) Wichtig sind hier die 0658 (=Vendor ID) und die 0200 (=Produkt ID)
ls -la /dev/ttyACM*
und
ls -la /dev/ttyUSB*neues Gerät:
crw-rw---- 1 root dialout 166, 0 Jan 13 11:55 /dev/ttyACM0(notieren!)
die 166 benötigen wir am Ende um das Mouten des USB Gerätes im Container Config File vorzunehmen
Den Pfad /dev/ttyACM0 u.a. für die Identifikation der Seriennummer (gleich mehr dazu)
Nach User und Gruppe ... vor dem Datum stehen 166 und 0 (=major und minor device IDs)
Problem, wenn man mal neu verbindet oder umsteckt kommt ggf. ein neues Gerät, z. B. mit 166 und 1
D.h. bei einem Reboot wechelt unter Umständen die Minor ID von 0 auf 1.
also von
/dev/ttyACM0 auf
/dev/ttyACM1Um das zu verhindern legen wir später einen Alias an, bevor wie das USB-Passthrough Richtung LXC Container einrichten
Da Geräte mit gleichem Chipsatz die gleiche Vendor ID und Produkt ID haben, brauchen wir noch einen Identifier, der eindeutig ist. Dazu nehmen wir die Seriennummer.
Nur die Seriennummer reicht anscheinend nicht (ich habe z.B. an /dev/ttyACM0 und /dev/ttyACM1 zwei identische)
Vgl. auch dazu folgende Quelle:
http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/ (http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/)
Diese bekommen wir heraus, indem wir wie folgt (je Gerät natürlich auf den Pfad angepasst) abfragen:
udevadm info -a -n /dev/ttyACM0 | grep '{serial}' | head -n1Die Serial notieren wir uns bei unserem Gerät
ATTRS{serial}=="0000:00:14.0"Die
0000:00:14.0 ist unsere Seriennummer (Nachtrag: beim ZWAVE Dongle sieht die Seiennummer komisch aus im Vergleich zu anderen Geräten - dort z. B. AL01MZ4B)
Nun legen wir ein neues File mit den USB Regeln an:
sudo nano /etc/udev/rules.d./99-usb-serial.rulesDort tragen wir alle USB Geräte mit der foolgenden Logik ein:
SUBSYSTEM=="tty", ATTRS{idVendor}==,,<Vendor ID>", ATTRS{idProduct}=="<Produkt ID>", ATTRS{serial}==,,<Seriennummer>", SYMLINK+=,,<Bezeichnung>"
Im folgenden Befehl legen wir z. B. /dev/zwave als Alias an:
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", ATTRS{serial}=="0000:00:14.0", SYMLINK+="zwave"Nun speichern wir die Datei (Control X, Y(es) und ENTER)
Nun den proxmox host rebooten:
rebootoder den Dienst neu starten:
/etc/init.d/udev restartdamit sollte es nach dem reboot egal sein, ob das USB Gerät auf
/dev/ttyACM0 oder
/dev/ttyACM1erkannt wird:
ls -la /dev/zwavenun sollte die Zuordnung autoamtisch klappen:
lrwxrwxrwx 1 root root 7 Jan 13 13:49 /dev/zwave -> ttyACM0Das ist ein "Symlink"
Hier die Informationen zu meinen Sticks:ZWAVE
crw-rw---- 1 root dialout 166, 0 Jan 13 11:55 /dev/ttyACM0
Bus 001 Device 020: ID 0658:0200 Sigma Designs, Inc. Viessmann Optokoppler
crw-rw---- 1 root dialout 188, 0 Jan 13 12:01 /dev/ttyUSB0
Bus 001 Device 021: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Lacrosse Jeelink
crw-rw---- 1 root dialout 188, 1 Jan 13 12:03 /dev/ttyUSB1
Bus 001 Device 022: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) ICmit Cul868 (
ACHTUNG: an LAN-USB-LAN Verkängerung)
crw-rw---- 1 root dialout 166, 1 Jan 13 12:05 /dev/ttyACM1
Bus 001 Device 023: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project(
ACHTUNG: Cul an LAN-USB-LAN Verkängerung)
mit OWL Strommesser
crw-rw---- 1 root dialout 188, 2 Jan 13 12:14 /dev/ttyUSB2
Bus 001 Device 025: ID 0fde:ca05 Oregon Scientific CM160meine komplette /etc/udev/rules.d./99-usb-serial.rules sieht so aus:
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", ATTRS{serial}=="0000:00:14.0", SYMLINK+="zwave"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A900WVZZ", SYMLINK+="viesmann"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AL01MZ4B", SYMLINK+="jeelink"
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="0000:00:14.0", SYMLINK+="cul868"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0fde", ATTRS{idProduct}=="ca05", ATTRS{serial}=="0077CF1A", SYMLINK+="owl160"Leider wird hier mein Cul868 nicht als Alias (Symlink) angelegt. Kann das an der LAN-USB-LAN Verlängerung liegen?
2. Dieser Symlink muss nun im Configfile des entsprechenden LXC-Containers gemounted werden.Ab hier bin ich unsicher, da noch nicht von Erfolg gekrönt:Wenn der Container die ID <number> hat ist das File hier:
/etc/pve/nodes/proxmox/lxc/<number>.conf oder (???) hier
/etc/pve/lxc/<number>.confalso in meinem Beispiel für Container 100:
sudo nano /etc/pve/nodes/proxmox/lxc/100.confFolgende Zeilen müssen eingetragen werden:
lxc.aa_profile: unconfinedkeine Ahnung wofür...
lxc.cgroup.devices.allow: c 166:* rwmdie 166 ist die major ID, das * steht für alle dazugehörigen minor IDs.
Falls noch eine weitere major ID da ist, dann einen oder mehrere weitere Einträge (vgl. meine 100.con unten)
lxc.mount.entry: /dev/zwave dev/zwave none bind,optional,create=filejetzt wird das Verzeichnis /dev/zwave vom host auf dem Container gemounted (?)
Hier mal der Original-Text dazu aus meinem Link von ganz oben:
ZitatThe first line, lxc.aa_profile is to not confine this container to any AppArmor profile. The default AppArmor profile will not allow mounted devices, and I prefer to just unconfine for simplicity. Obviously this isn't as secure as creating a proper profile, but I'm not going to cover that. Research into AppArmor policies if that tickles your fancy.
The second line, lxc.cgroup.devices.allow tells this container that they have access to any device with a major ID of 166 and a minor ID of *, or any device. We could set it to 166:0 rwm to only allow our one specific device, but if it was to change on a host reboot, our LXC would break as well. From my understanding, a major ID of 166 is for USB devices so I prefer to tell my LXC that it's allowed to access any USB device from the host. The rwm at the end stands for "read, write, mount" which are permissions that it can have. The third line, lxc.mount.entry is the actual mounting process. So even though the second line allows a (or multiple) devices to be accessed, we have to mount them in the LXC before that can happen. What we are doing with this third line is mounted the /dev/zwave device from the host to dev/zwave (with / as our working dir), and setting the options of none bind,optional,create=file.
Save this conf file, restart the LXC and now we should see /dev/zwave inside our LXC. If the minor ID or original device name changes on our host, we shouldn't have to worry about it because of our symlink/alias.
Meine aktuelle 100.conf schaut so aus:
arch: amd64
cores: 4
hostname: fhem-container
memory: 4192
net0: name=eth0,bridge=vmbr0,gw=192.168.0.1,hwaddr=52:7E:2B:F2:EE:2A,ip=192.168.0.25/24,ip6=dhcp,type=veth
onboot: 1
ostype: ubuntu
parent: passthroughunfertig
rootfs: local-lvm:vm-100-disk-1,size=40G
swap: 2048
tty: 6
[passthroughunfertig]
#5 USB Ger%C3%A4te gehen noch nicht
#fhem.cfg alt (ohne versch. Anwendungen)
arch: amd64
cores: 4
hostname: fhem-container
memory: 4192
net0: name=eth0,bridge=vmbr0,gw=192.168.0.1,hwaddr=52:7E:2B:F2:EE:2A,ip=192.168.0.25/24,ip6=dhcp,type=veth
onboot: 1
ostype: ubuntu
parent: rohinstallation
rootfs: local-lvm:vm-100-disk-1,size=40G
snaptime: 1515888829
swap: 2048
tty: 6
[rohinstallation]
#Ubuntu, User PI mit sudo
#FTP
#Samba
#FHEM
# lxc.aa_profile%3A unconfined
arch: amd64
cores: 4
hostname: fhem-container
memory: 4192
net0: name=eth0,bridge=vmbr0,gw=192.168.0.1,hwaddr=52:7E:2B:F2:EE:2A,ip=192.168.0.25/24,ip6=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-lvm:vm-100-disk-1,size=40G
snaptime: 1515795543
swap: 2048
lxc.mount.entry: /dev/serial/by-id/ dev/serial/by-id none bind,optional,create=dir
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 188:* rwm
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/zwave dev/zwave none bind,optional,create=file
lxc.mount.entry: /dev/viessmann dev/viessmann none bind,optional,create=file
lxc.mount.entry: /dev/jeelink dev/jeelink none bind,optional,create=file
lxc.mount.entry: /dev/cul dev/cul none bind,optional,create=file
lxc.mount.entry: /dev/owl160 dev/owl160 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry = /dev/bus/usb/001/ dev/bus/usb/001/ none bind,optional,create=dir
lxc.mount.entry = /dev/bus/usb/002/ dev/bus/usb/002/ none bind,optional,create=dir
lxc.mount.entry = /dev/bus/usb/003/ dev/bus/usb/003/ none bind,optional,create=dir
Den unteren Bereich habe ich nach diversen erfolglosen Tests dazugepackt, da ich nicht sicher war, ob meine Alias-Sachen (Symlinks) zu Problemen führen. Bringt leider auch nichts.
Nun habe ich alles rebooted.
Was ich komischerweise sehe:
pi@fhem-container:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 009: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 008: ID 0fde:ca05 Oregon Scientific CM160
Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubLeider sehe ich die Ordner, wie z. B. /dev/zwave auf dem Container nicht.
pi@fhem-container:~$ ls -la /dev
total 4
drwxr-xr-x 7 root root 560 Jan 14 18:51 .
drwxr-xr-x 22 root root 4096 Jan 14 18:51 ..
lrwxrwxrwx 1 root root 11 Jan 14 18:51 console -> lxc/console
lrwxrwxrwx 1 root root 11 Jan 14 18:51 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Jan 14 18:51 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Jan 14 18:51 full
drwxr-xr-x 2 root root 0 Jan 14 18:51 hugepages
lrwxrwxrwx 1 root root 25 Jan 14 18:51 initctl -> /run/systemd/initctl/fifo
lrwxrwxrwx 1 root root 28 Jan 14 18:51 log -> /run/systemd/journal/dev-log
drwxr-xr-x 2 root root 180 Jan 14 18:51 lxc
drwxrwxrwt 2 root root 40 Jan 14 18:51 mqueue
crw-rw-rw- 1 root root 1, 3 Jan 14 18:51 null
crw-rw-rw- 1 root root 5, 2 Jan 14 19:41 ptmx
drwxr-xr-x 2 root root 0 Jan 14 18:51 pts
crw-rw-rw- 1 root root 1, 8 Jan 14 18:51 random
drwxrwxrwt 2 root root 40 Jan 14 18:51 shm
lrwxrwxrwx 1 root root 15 Jan 14 18:51 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Jan 14 18:51 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Jan 14 18:51 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Jan 14 18:51 tty
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty1 -> lxc/tty1
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty2 -> lxc/tty2
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty3 -> lxc/tty3
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty4 -> lxc/tty4
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty5 -> lxc/tty5
lrwxrwxrwx 1 root root 8 Jan 14 18:51 tty6 -> lxc/tty6
crw-rw-rw- 1 root root 1, 9 Jan 14 18:51 urandom
crw-rw-rw- 1 root root 1, 5 Jan 14 18:51 zeroMeine Fragen:a) Macht es ein Problem, wenn ich mit dem User PI (Gruppe dialout) auf dem Container arbeite, also scheitert es an Berechtigungen.
b) Wenn ich die Ordner auf dem Container manuell anlege, sind diese nach dem Neustart des Containers wieder weg. Wie kann ich das vermeiden?
c) seht Ihr generelle Fehler bei meinem Vorgehen, bzw. habe ich etwas vergessen? Muss ich ggf. noch mount-Befehle nutzend) Kann ich, damit ich zumindest mein FHEM in Betrieb nehmen kann meine USB Devices mit dem jetzigen Stand in FHEM einbinden? (vgl. lsusb auf dem Container) Wenn ja, wie?
Freue mich über Hilfe!
falls noch jemand das Problem hat. Mit meinem Container auf ID100 funktioniert das Lesen des Config-Files nicht.
In IDs größer 100 geht das. Warum auch immer...
so habe ich nun eingebunden:
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Wichtig: In Proxmox gibt es einen Bereich Übersicht des Containers einen Bereich "Hinweise". Dort sehr Ihr (leider nicht immer) das was in der conf-Datei steht.
Aber nicht den Fehler machen, dort etwas einzutragen und zu glauben, dass es damit in der conf-Datei landet. Hat bei mir nicht funktioniert.
Also bei meinem Container mit der ID 104:
nano /etc/pve/nodes/proxmox/lxc/104.conf
Vielen Danke für die "Anleitung". Das funzt bei mir auch bestens.
Mit der ContainerID 100 habe ich jetzt kein Problem, da klappt das direkt mit.
Btw. mache das ganze auf einem NUC7i3BNH mit Proxmox VE und nanoCUL 443 MHz. Weitere Geräte folgen noch.
Danke für die ausführliche Doku.
Da mein Mainboard nur mit manchen Proxmox Versionen funktioniert, nutze ich LXC direkt auf Ubuntu.
(Und zumindest vor dem BIOS Update hattte ich auch Sorgen mit VM-Ware ESXi...)
Ich mache das ganze viel plumper, ... Ich reiche einfach die ersten Paar USB-Devices durch in den FHEM Container. (Genauer: Die Devices die beim Container-Start existieren)
Hier beschrieben: https://forum.fhem.de/index.php/topic,78738.0.html
In FHEM definiere ich dann einfach wie gewohnt /dev/serial/by-id/*XYZ* ...
PS: Und zusätzlich vermeide ich USB Devices und versuche immer mal wieder alle IOs ans LAN zu bekommen...
Da ich hier gerade drüber stolpere, ein kleines Update:
Ich habe alle IOs nun per ser2net über einen RPI angebunden.
Das hat den Charme, dass ich einen FHEM-Klon aufrufen kann und alle Sticks zur Verfügung habe.
Klingt interessant. Ich habe mangels Zeit Proxmox bisher nur nebenbei zum testen verwendet. Ohne IOs
Habe nun Lust bei Gelegenheit komplett um zu steigen. Ich habe einen Cluster mit 4 Nodes und CEPH. Werde mich die nächsten Wochen etwas mehr mit fhem und Proxmox beschäftigen.
Update:
https://forum.fhem.de/index.php/topic,88249.0.html
Ist es jemandem bereits gelungen ein USB Bluetooth Dongle an einen Container durchzureichen? ???
Wollte zum testen von Snips (lokale Spracherkennung) ein USB-Micro an einen Container durchreichen.
Mein Zwave Stick und der Jeelink funktionieren auf diesem Weg einwandfrei:
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Habe das nun mit dem USB-Micro so versucht:
lxc.cgroup.devices.allow: c 189:6 rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
arecord -l im Container bringt mir aber ein "no soundcard found".
Bin mir halt nicht sicher ob /dev/bus/usb/001/007 weiterreichen ausreicht, oder was hier richtig wäre.
Mit Audio allgemein habe ich unter Linux bisher wenig am Hut gehabt.
Hat da jemand evtl. eine Idee wie man das zum Laufen bekommt?
Oder wären meine Chance mit einer VM besser? Muss ja nicht zwingend LXC sein..
Zitat von: Thyraz am 11 Juli 2018, 08:08:31
Wollte zum testen von Snips (lokale Spracherkennung) ein USB-Micro an einen Container durchreichen.
Mein Zwave Stick und der Jeelink funktionieren auf diesem Weg einwandfrei:
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Habe das nun mit dem USB-Micro so versucht:
lxc.cgroup.devices.allow: c 189:6 rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
arecord -l im Container bringt mir aber ein "no soundcard found".
Bin mir halt nicht sicher ob /dev/bus/usb/001/007 weiterreichen ausreicht, oder was hier richtig wäre.
Mit Audio allgemein habe ich unter Linux bisher wenig am Hut gehabt.
Hat da jemand evtl. eine Idee wie man das zum Laufen bekommt?
Oder wären meine Chance mit einer VM besser? Muss ja nicht zwingend LXC sein..
Micro weiß ich nicht, aber ich habe die interne Soundkarte vom Rock64 durchgereicht bekommen. Für TTS Sprachausgaben.
Vielleicht fehlt dir noch snd? und wichtig sind auch die cgroup Einträge... die bekommst du mit ein ls -l heraus, siehe unten.
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir 0 0
lxc.cgroup.devices.allow = c 280:* rwm
lxc.cgroup.devices.allow = c 116:* rwmroot@rocki:/var/lib/lxc/fhem# ls -l /dev | grep snd
drwxr-xr-x 3 root root 280 Jul 3 17:38 sndroot@rocki:/var/lib/lxc/fhem# ls -l /dev/snd
total 0
drwxr-xr-x 2 root root 100 Jul 3 17:38 by-path
crw-rw---- 1 root audio 116, 2 Jul 3 17:38 controlC0
crw-rw---- 1 root audio 116, 7 Jul 3 17:38 controlC1
crw-rw---- 1 root audio 116, 9 Jul 3 17:38 controlC2
crw-rw---- 1 root audio 116, 4 Jul 3 17:38 pcmC0D0c
crw-rw---- 1 root audio 116, 3 Jul 3 17:38 pcmC0D0p
crw-rw---- 1 root audio 116, 6 Jul 3 17:38 pcmC0D1c
crw-rw---- 1 root audio 116, 5 Jul 3 17:38 pcmC0D1p
crw-rw---- 1 root audio 116, 8 Jul 3 17:38 pcmC1D0p
crw-rw---- 1 root audio 116, 10 Jul 3 17:38 pcmC2D0p
crw-rw---- 1 root audio 116, 1 Jul 3 17:38 seq
crw-rw---- 1 root audio 116, 33 Jul 3 17:38 timer
Genial, das funktioniert. :)
Hatte eher den Gedanken, dass man nur das USB-Device durchreichen muss und das Gastsystem erkennt das dann schon.
Denke mal das klappt nicht, da die LXC Container ja keine eigenständigen VMs sind.
Hab jetzt sogar meine ursprünglichen Einträge für das USB-Device wieder aus der Config nehmen können und nur die für /dev/snd + groups drin lassen müssen.
Freut mich das es klappt! :)
Snips wollte ich auch schon mal anschauen.. weiß du zufällig wie man mit Snips über Fhem etwas schalten kann?
Läuft das lokal ab, oder muss man wie bei Alexa einen Port nach außen hin freigeben?
Snips sollte komplett lokal laufen.
Sowohl Hotword Erkennung als auch Texterkennung und herausziehen der Infos mit den Intents.
Ebenso auch dann das TTS in die andere Richtung.
Mehrere Räume scheinen auch machbar zu sein.
Man kann also je nachdem welches Micro den Befehl einfängt bei "Deckenlampe einschalten" eine andere Lampe ansprechen.
Auch Rückfragen oder Antworten sollten machbar sein.
Hab das aber alles auch nur überflogen bisher.
Die Kommunikation läuft über MQTT Nachrichten mit JSON Inhalt ab,
hier über das FHEM MQTT Modul zu gehen wird aber wenig Freude bereiten,
da man spätestens bei einer Konversation mit Rückantwort etc. ja doch mehr machen muss als nur ein paar Werte in Readings zu wandeln.
Somit wäre mein Plan da ein kleines Modul dafür zu schreiben.
Im Moment ist aber erst das Micro da und der Lautsprecher noch nicht.
Aber hoffe in den nächsten Wochen meiner im Moment knappen Freizeit ein wenig damit rumspielen zu können... :)
Cool danke dir für die Infos. :) Das schaue ich mir die Tage dann mal an, mqtt habe ich ja schon am laufen.
Ich hatte überlegt, das erstmal einfach nur für den Flur zu verwenden, da mein Fhem Server dort steht.
Beim verlassen der Wohnung könnte man die Wohnung per Sprache ausschalten. Oder beim heimkommen, die Küche/Wohnzimmer anschalten... Sonst habe ich noch 2 Alexa`s mit ha-bridge, aber es stört mich ein wenig, das diese Lösung nur on/off + dimmen kann.
Wenn du ein Fhem Modul programmierst, sag bitte mal bescheid. :)
P.S. Ich habe hier im Forum gelesen, das die PS3 Eye Cam ein gutes Micro verbaut hat, soll wohl ein Geheimtipp sein, da auch Preislich günstig bei Ebay zu kaufen gibt:
https://forum.fhem.de/index.php/topic,87897.msg803555.html#msg803555
Viele Grüße
Mark
Hallo zusammen,
auch wenn es schon ein paar Tage her ist häng ich mich hier mal dran.
Ich steige auch gerade vom Raspy auf einen Nuc8i3. Dazu nutze ich Proxmox und LXC. Das hat soweit auch geklappt und fhem läuft bereits.
Jetzt habe versuche ich gerade den JeeLink vom Raspberry an den Nuc zu bekommen und bin dabei nach der Anleitung im ersten Post vorgegangen. Leider stoße ich hier aber schon relativ früh auf Probleme.
lsusb funktioniert noch und bringt folgende Antwort
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0aaa Intel Corp.
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Dabei ist der Future Technology Devices International der JeeLink
Bei ls -la /dev/ttyACM* treten dann aber schon Probleme auf und ich bekomme folgende Antwort:
ls: cannot access '/dev/ttyACM*': No such file or directory
ls -la /dev/ttyUSB* sieht dann wieder besser aus:
crw-rw---- 1 root dialout 188, 0 Feb 19 11:54 /dev/ttyUSB0
Laut Anleitung benötige ich aber auch die Werte der ttyACM abfrage.
Hat jemand eine Idee weshalb bei mir hier die Fehlermeldung kommt und wie ich das Problem lösen kann?
Vielen Dank für Eure Hilfe.
Hi, und vielen Dank für die super Anleitung!
Ich hänge leider bei dem Punkt nach dem Reboot und der SymLink Erstellung.
Hier meine Ausgaben:
lsusb
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
ls -la /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Mar 21 07:01 /dev/ttyUSB0
udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1
ATTRS{serial}=="AXXXXX"
Eintrag in "/etc/udev/rules.d./99-usb-serial.rules". (Diese Datei, und den Ordner rules.d gab es übrigens bei mir nicht und habe ich per mkdir erstellt.)
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AXXXX", SYMLINK+="USBxyz"
Hier mein Problem:
root@pve:~# ls -la /dev/USBxyz
ls: cannot access '/dev/USBxyz': No such file or directory
EDIT:
Ich habe noch ein anderes Tut (http://coldcorner.de/2018/07/12/proxmox-usb-passthrough-fuer-lxc-container-z-wave-uzb1/) gefunden, mit dem habe ich es nun hinbekommen.
Wenn auch nur mit /dev/TTyUSB0. nicht mit dem Namen...
Ich muss mich korrigieren.
Es hat nur bis zu einem Neustart gehalten.
jetzt bekomme ich immer Zugriffsfehler auf das Gerät.
Das Device was ich durchschleifen will hat folgende Attribute:
root@OSCam ~ > ls -la /dev/ttyUSB*
crw-rw---- 1 nobody nogroup 188, 0 Mar 26 18:53 /dev/ttyUSB0
Das nobody:nogroup wundert mich.
Ich vermute dass ich deswegen nicht gescheit darauf zugreifen kann.
Wenn ich das Gerät mit root übernehmen will, bekomme ich folgende Ausgabe:
root@OSCam ~ > sudo chown root:root /dev/ttyUSB0
chown: changing ownership of '/dev/ttyUSB0': Operation not permitted
Das soll angeblich an irgend einem Flag liegen, was man mittels
chattr -i /dev/ttyUSB0 entfernen kann.
Dann bekomme ich aber dieses zu lesen:
root@OSCam ~ > sudo chattr -i /dev/ttyUSB0
chattr: Operation not supported while reading flags on /dev/ttyUSB0
Irgendwie drehe ich mich im Kreis...
Gib dem Device als erstes doch einfach mal 777 Rechte. Das kann man später immer noch ordentlich machen. (chmod 777 /dev/xx)
chmod und chown wurden immer mit "permission denied" abgelehnt. (obwohl als root ausgeführt)
Bin gerade dabei das Debian als VM aufzusetzen anstatt als LXC.
Vielleicht hilft das.
Das chmod machst du schon auf dem Host?
Ja, auf dem Host.
Mit Debian als VM geht es jetzt.
Hast du den LXC wenigstens bestehen lassen oder gelöscht?
Ich könnte dir morgen meine Settings durchgeben.
Grüße
Habe ich gelöscht :P
Der LXC bestand sowieso nur für diese eine Aufgabe mit dem USB Device...
Als VM frisst er jetzt auch nicht viel mehr Hardware.
Danke für das Angebot.
Aber vielleicht interessiert es hier noch jemand anderen.
Ich häng mich mal dran.
Das Einbinden von JeeLink und SingnalDuino hat bei mir ohne Probleme funktioniert.
Danach habe ich zahlreiche Stunden für das Einbinden des HM-CFG-USB-2 benötigt. Warum ist mir im nachhinein schleierhaft ;) . Ich habe zunächst immer mit den falschen Devices getestet.
Daher hier gerne meine Lösung:
Proxmox Host:
Nach einstecken des USB-Devices gibt es drei neue Devices. Benötigt wird nur ein einziges!
root@proxmox:/dev/bus/usb/001# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0a2b Intel Corp.
Bus 001 Device 005: ID 1b1f:c00f
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
1. nicht benötigt
/dev/hidraw0
root@proxmox:/dev# ls -ls /dev/hidraw0
0 crw------- 1 root root 239, 0 Apr 21 10:01 /dev/hidraw0
2. nicht benötigt
/dev/usb
root@proxmox:/dev# ls -ls /dev/usb
total 0
0 crw------- 1 root root 180, 0 Apr 21 10:01 hiddev0
Hier bin ich lange über den anderen Namen gestolpert und dachte meine Probleme lägen daran.
3.
/dev/bus/usb/001/005
root@proxmox:/dev# ls -ls /dev/bus/usb/001/005
0 crw-rw-r-- 1 root root 189, 4 Apr 21 10:01 /dev/bus/usb/001/005
Demnach habe ich meine /etc/pve/lxc/100.conf folgendermaßen konfiguriert:
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/005 dev/bus/usb/001/005 none bind,optional,create=file
Rechte auf dem Host setzten:
root@proxmox:/dev# chmod o+rw /dev/bus/usb/001/005
Container testen
3.
user@fhem2:~$ ls -ls /dev/bus/usb/001/005
0 crw-rw-r-- 1 nobody nogroup 189, 4 Apr 21 10:01 /dev/bus/usb/001/005
Auf dem Client das hier präsentierte Script zur Installation von HMLAN ausführen (sofern noch nicht geschehen):
https://forum.fhem.de/index.php/topic,13071.msg190887.html#msg190887
Dann testen:
user@fhem2:~$ /opt/hmcfgusb/hmland -p 1234 -D
EDIT:
Um die chmod Rechte auch nach dem Neustart des Hosts zu erhalten habe ich dieses Lösung genommen:
http://ask.xmodulo.com/change-usb-device-permission-linux.html
Zitat von: mark79 am 11 Juli 2018, 09:58:24
Micro weiß ich nicht, aber ich habe die interne Soundkarte vom Rock64 durchgereicht bekommen. Für TTS Sprachausgaben.
Vielleicht fehlt dir noch snd? und wichtig sind auch die cgroup Einträge... die bekommst du mit ein ls -l heraus, siehe unten.
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir 0 0
lxc.cgroup.devices.allow = c 280:* rwm
lxc.cgroup.devices.allow = c 116:* rwm
root@rocki:/var/lib/lxc/fhem# ls -l /dev | grep snd
drwxr-xr-x 3 root root 280 Jul 3 17:38 snd
root@rocki:/var/lib/lxc/fhem# ls -l /dev/snd
total 0
drwxr-xr-x 2 root root 100 Jul 3 17:38 by-path
crw-rw---- 1 root audio 116, 2 Jul 3 17:38 controlC0
crw-rw---- 1 root audio 116, 7 Jul 3 17:38 controlC1
crw-rw---- 1 root audio 116, 9 Jul 3 17:38 controlC2
crw-rw---- 1 root audio 116, 4 Jul 3 17:38 pcmC0D0c
crw-rw---- 1 root audio 116, 3 Jul 3 17:38 pcmC0D0p
crw-rw---- 1 root audio 116, 6 Jul 3 17:38 pcmC0D1c
crw-rw---- 1 root audio 116, 5 Jul 3 17:38 pcmC0D1p
crw-rw---- 1 root audio 116, 8 Jul 3 17:38 pcmC1D0p
crw-rw---- 1 root audio 116, 10 Jul 3 17:38 pcmC2D0p
crw-rw---- 1 root audio 116, 1 Jul 3 17:38 seq
crw-rw---- 1 root audio 116, 33 Jul 3 17:38 timer
Moin, ich stehe grad vor dem gleichen Problem und versuche das PS3 Eye in eine Snips LXC einzubinden.
Leider scheitere ich.
Habe die cgroups, snd und den usb stick selbst in die Config eingebunden.
Hab es ohne USB mal versucht, aber leider ohne Erfolg.
HOST
ls -l /dev/bus/usb/001/005
crw-rw-r-- 1 root root 189, 4 Jun 3 14:27 /dev/bus/usb/001/005
ls -l /dev | grep snd
drwxr-xr-x 4 root root 380 Jun 3 14:27 snd
ls -l /dev/snd
total 0
drwxr-xr-x 2 root root 60 Jun 3 14:27 by-id
drwxr-xr-x 2 root root 80 Jun 3 14:27 by-path
crw-rw---- 1 root audio 116, 2 Jun 2 21:14 controlC0
crw-rw---- 1 root audio 116, 13 Jun 3 14:27 controlC1
crw-rw---- 1 root audio 116, 11 Jun 2 21:14 hwC0D0
crw-rw---- 1 root audio 116, 12 Jun 2 21:14 hwC0D2
crw-rw---- 1 root audio 116, 4 Jun 2 21:14 pcmC0D0c
crw-rw---- 1 root audio 116, 3 Jun 2 21:14 pcmC0D0p
crw-rw---- 1 root audio 116, 10 Jun 2 21:14 pcmC0D10p
crw-rw---- 1 root audio 116, 5 Jun 2 21:14 pcmC0D1p
crw-rw---- 1 root audio 116, 6 Jun 2 21:14 pcmC0D3p
crw-rw---- 1 root audio 116, 7 Jun 2 21:14 pcmC0D7p
crw-rw---- 1 root audio 116, 8 Jun 2 21:14 pcmC0D8p
crw-rw---- 1 root audio 116, 9 Jun 2 21:14 pcmC0D9p
crw-rw---- 1 root audio 116, 14 Jun 3 14:27 pcmC1D0c
crw-rw---- 1 root audio 116, 1 Jun 2 21:14 seq
crw-rw---- 1 root audio 116, 33 Jun 2 21:14 timer
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir 0 0
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/005 dev/bus/usb/001/005 none bind,optional,create=file
lxc.cgroup.devices.allow = c 380:* rwm
lxc.cgroup.devices.allow = c 116:* rwm
arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: CameraB409241 [USB Camera-B4.09.24.1], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
In dem LXC leider nicht.
maui@snips:~$ arecord -l
arecord: device_list:270: no soundcards found...
Gehen Aufnahmen/Abspielen im Host System? Dort muss auch alsa-utils installiert sein, oder was auch immer du zur Soundausgabe nutzt.
Hier mal was ich mir damals notiert hatte:
Zitat
Sowohl auf Host als auch im LXC Container:
sudo apt-get install alsa-utils
Audioaufnahmen müssten auf dem Host nun gehen:
arecord --device=hw:1,0 -f S16_LE -c 4 -r 16000 -d5 test.wav
Auf dem Hostsystem c-groups für /dev/snd und dessen Inhalt ermitteln:
ls -la /dev/ | grep snd
ls -la /dev/snd/
Ergibt z.B. 360 und 116
dann auf dem Host diese c-groups und /dev/snd durchreichen:
nano /etc/pve/nodes/pve/lxc/10<x>.conf
erweitern mit:
lxc.mount.entry: /dev/snd dev/snd none bind,create=dir,optional 0 0
lxc.cgroup.devices.allow: c 116:* rwm
lxc.cgroup.devices.allow: c 360:* rwm
Danach müssen auf dem Gastsystem Audioaufnahmen möglich sein:
sudo arecord --device=hw:1,0 -f S16_LE -c 4 -r 16000 -d5 test.wav
sudo nano /etc/asound.conf anpassen:
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "hw:2,0"
}
capture.pcm {
type plug
slave.pcm "hw:1,0"
}
}
Host geht. Hab den Sound an sich erstmal hinbekommen, indem ich den Container privileged (nicht non-privileged :) ) gemacht habe.
Nicht schön, aber da nur lokal erstmal verkraftbar.
Jetzt hänge ich allerdings bei snips allgemein, ich gehe erstmal wieder einen Schritt zurück und teste es am Pi 3. Wenn ich da dann Erfolge hatte, gehe ich wieder vorwärts Richtung Proxmox.
Gruß
Maui