Probleme nach installatio: IO::Socket::SSL

[Smarti]

Guten Tag,

ich habe meine FHEM Installation auf einem Raspberry mit Raspian Jessy am laufen.

Nun wollte ich einen Kalender integrieren und laut Command Ref muss bei Zugriff auf https Servern das IO::Socket::SSL für Perl installiert werden.

Ich kann es nicht mit 100% Sicherheite sagen, aber seit diesem Zeitpunkt ist Sowohl mein SCC + JeeLink nicht mehr ansprechbar bzw. disconnected.

Kann dies sein? Weiß jemand wie ich das herausfinden kann.

Meine Sonoff über wifi und Flower Mate über Bluetooth sind weiterhin in Ordnung.

Wenn ich über minicom die die Kommunikation anschaue, sehe ich, dass vom JeeLink Daten kommen. In FHEM wird dieser jedoch mit "Disconnected" gelistet.

Diverse Resets haben mich nicht weitergebracht...

Also um ein paar Tips wäre ich echt dankbar.

[Smarti]

Also ich bin einen Schritt weiter, beim neustarten ist mir aufgefallen. Dass FHEM wohl keine Rechte mehr besitzt um auf die Schnittstelle zuzugreifen:

Code Auswählen Erweitern


2017.10.08 18:12:37 3: Opening myJeeLink device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014JMC-if00-port0
2017.10.08 18:12:37 3: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014JMC-if00-port0: Permission denied
2017.10.08 18:12:37 3: Opening SCC device /dev/ttyAMA0
2017.10.08 18:12:37 3: Can't open /dev/ttyAMA0: Permission denied


Für mein Verstädnis kann ich hiermit die notwendigen Rechte vergeben:

Code Auswählen Erweitern


sudo usermod -a -G tty pi && sudo usermod -a -G tty fhem


Allerdings hat mich das auch nicht weitergebracht...

[Otto123]

Hi,

Du bist eventuell auf dem Holzweg, ttyAMA0 ist doch die interne UART. Siehe z.B. hier -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Vorbereitung_serielle_Schnittstelle_unter_Jessie

Ist von der Sache her sicher das gleiche Thema. Wenn nicht, sorry dann liege ich falsch.

Gruß Otto

[Smarti]

Ok, hat mich weitergebracht...

der user "fhem" war in der gruppe "dialout" nicht mehr vorhanden... jetzt läuft das wieder.

Hat jemand eine Idee wie es passieren kann?

[Gunther]

Ich kann z. B. meinen Jeelink nicht nutzen.
Dieser hängt am Nuc unter Proxmox und FHEM läuft auf einem LXC Container.
Den Stick habe ich durchgereicht.

Kann mein Problem mit den im verlinkten Wikieintrag stehenden Punkten zusammenhängen?

Komischerweise läuft mein 868MHz CUL perfekt und ist genauso eingebunden.

[Otto123]

Hallo Gunther,
kannst Du etwas mehr ins Detail gehen? In dem Wiki Artikel geht es um die Spezialität UART Schnittstelle GPIO des Pi ?

Gruß Otto

[Gunther]

Ich beziehe mich darauf, dass der Jeelink Dongle auf disconnected steht.
Im Wiki Artikel habe ich verstanden, dass der Host, an dem das Gerät primär angeschlossen ist keine Kommunikation laufen darf. Zumindest habe ich das beim Lesen so verstanden:

Die Remoteanbindung ist kein Sharing des Moduls! Es darf an dem Remote Pi (wo das Modul sitzt) keinerlei Zugriff auf das Modul seitens einer etwaigen lokalen FHEM Instanz erfolgen.

Da bei mir der Jeelink ja am Proxmox hängt und an den LXC-Container durchgereicht wird, war nun eine Vermutung, dass dort "Kommunikation" läuft.

Andere Container/ virtuelle Maschinen sind nicht aktiv.

Edit: Hintergrund war dieses Problem, das ich nun halbwegs gelöst habe, eben bis auf den Jeelink Dongle und mein Viessmann Optokoppler

Diese beiden Devices sind problematisch:

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 13 Jan 20 01:18 usb-FTDI_FT232R_USB_UART_A900WVZZ-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 20 01:18 usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -> ../../ttyUSB1

Kann das ein Berechtigungsthema sein? Allerdings sieht das bei den funktionierenden USB-Geräten genauso aus, nur dass diese sich unterscheiden und nicht den gleichen Chipsatz haben.

[Otto123]

Ich denke, das ist genauso wie Du es beim Lesen verstanden hast. 

[Gunther]

Wie kann ich denn verhindern, dass USB-Geräte am Proxmox kommunizieren?

Ich habe nun mal die Berechtigungen auf dem Container geändert:

Code Auswählen Erweitern

root@fhem-container:/boot# chown -R fhem:dialout /dev/serial/by-id         
root@fhem-container:/boot# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 fhem dialout 13 Jan 20 01:18 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 fhem dialout 13 Jan 20 01:18 usb-FTDI_FT232R_USB_UART_A900WVZZ-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 fhem dialout 13 Jan 20 01:18 usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 fhem dialout 13 Jan 20 01:18 usb-Silicon_Labs_Owl_Wireless_Electricity_Monitor_USB_version_connected_0077CF1A-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 fhem dialout 13 Jan 20 01:18 usb-busware.de_CUL868-if00 -> ../../ttyACM1


und für meinen Jeelink testweise:

Code Auswählen Erweitern

root@fhem-container:/boot# chown -R fhem:dialout /dev/ttyUSB1             
root@fhem-container:/boot# ls -l /dev
total 0
lrwxrwxrwx 1 root root        11 Jan 20 01:23 console -> lxc/console
lrwxrwxrwx 1 root root        11 Jan 20 01:23 core -> /proc/kcore
lrwxrwxrwx 1 root root        13 Jan 20 01:23 fd -> /proc/self/fd
crw-rw-rw- 1 root root      1, 7 Jan 20 01:23 full
drwxr-xr-x 2 root root         0 Jan 20 01:23 hugepages
lrwxrwxrwx 1 root root        25 Jan 20 01:23 initctl -> /run/systemd/initctl/fifo
lrwxrwxrwx 1 root root        28 Jan 20 01:23 log -> /run/systemd/journal/dev-log
drwxr-xr-x 2 root root       100 Jan 20 01:23 lxc
drwxrwxrwt 2 root root        40 Jan 20 01:23 mqueue
crw-rw-rw- 1 root root      1, 3 Jan 20 01:23 null
crw-rw-rw- 1 root root      5, 2 Jan 20 21:09 ptmx
drwxr-xr-x 2 root root         0 Jan 20 01:23 pts
crw-rw-rw- 1 root root      1, 8 Jan 20 01:23 random
drwxr-xr-x 3 root root        60 Jan 20 01:23 serial
drwxrwxrwt 2 root root        40 Jan 20 01:23 shm
lrwxrwxrwx 1 root root        15 Jan 20 01:23 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root        15 Jan 20 01:23 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root        15 Jan 20 01:23 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root      5, 0 Jan 20 01:23 tty
lrwxrwxrwx 1 root root         8 Jan 20 01:23 tty1 -> lxc/tty1
lrwxrwxrwx 1 root root         8 Jan 20 01:23 tty2 -> lxc/tty2
crw-rw---- 1 root dialout 166, 0 Jan 20 21:02 ttyACM0
crw-rw---- 1 root dialout 166, 1 Jan 20 21:02 ttyACM1
crw-rw---- 1 root dialout 188, 0 Jan 20 01:18 ttyUSB0
crw-rw---- 1 fhem dialout 188, 1 Jan 20 01:18 ttyUSB1
crw-rw---- 1 root dialout 188, 2 Jan 20 01:18 ttyUSB2
-rw-r--r-- 1 root root         0 Jan 20 01:23 ttyUSB3
crw-rw-rw- 1 root root      1, 9 Jan 20 01:23 urandom
crw-rw-rw- 1 root root      1, 5 Jan 20 01:23 zero

Kann ich per Berechtigung auf dem proxmox host verhindern, dass die Dongels da "verwendet" werden?

[Otto123]

Sorry ich habe es nicht verstanden, hast Du jetzt eine Remoteanbindung oder nicht? Laufen da jetzt zwei Maschinen mit Zugriff auf dem gleichen Stick, oder nicht?
Nach meiner Erfahrung bringt die vermeintliche Veränderung von Rechten auf den Schnittstellen nichts. Das ist nur ein Symptom und nicht die Ursache.
Allerdings kann ich zu der Konstellation proxmox und Container nix sagen, also hör nicht auf mich wenn ich das falsch verstanden habe 

Gruß Otto

[Gunther]

Ich habe physisch eine Maschine: Intel Nuc
Daran hängen per USB meine IOs.

Grundlage ist Proxmox als "Virtualisierungsumgebung". Proxmox läuft auf einem Linuxsystem.
Derzeit läuft als einzige Virtualisierung darunter ein Container mit Ubuntu.

Die USB Geräte vom Proxmox-Linux habe ich an den Container weitergereicht.

Ob das nun als Remoteanbindung zählt...?
Aber: Im Grunde "nutzen" zwei Linuxsysteme die gleichen Sticks. Z. B. beim 868Cul klappt das beim Jeelink nicht.