(FHEM) Allgemeines
Inhaltsverzeichnis
Wozu noch weitere Wikiseiten zu FHEM?
Ich will auf keinen Fall alle Informationen der Original-Dokumentation noch einmal neu schreiben. Deshalb verweise ich i.d.R. auf Quellen zum weiteren Studium. Viel mehr dienen die Seiten in diesem Wiki, hier speziell zu Thema FHEM, mir als eine Zusammenfassung der Informationen, die ich aus verschiedenen Quellen zusammengetragen habe, um dann mit Hilfe der Zusammenfassung meinen eigenen FHEM-Server zu bereichern. Mit dieser Aussage habe ich, nach meiner Einschätzung, auch den größten Nachteil von FHEM geschildert. Keine Frage: FHEM ist super! Die Dokumentation dagegen bringt mich doch oft zur Verzweiflung.
Typischer Fall
Ich hätte gerne, dass (FHEM) ....
* Also Recherche. * Meine Bücher treffen das Problem nicht. * Das Internet gibt 1,3 Millionen Treffer. * Nach dem Motto 'Keep it simpel', oder noch besser 'Keep all simpel', werden die brauchbaren Treffer weniger. * Viele Lösungen scheiden aufgrund des Komplexitätsgrades, der nicht kongruenten Infrastruktur oder noch einfacher der Kosten aus. * FHEM bleibt als eine Lösungsvariante, die zur weiteren Betrachtung lohnenswert erscheint. * Suche auf FHEM Artikel einschränken (Stand 20201227: 700.000 Treffer bei google.de) * Startpunkt: FHEM-Dokumentation in Englisch und Deutsch vergleichen. * Weder in Englisch, noch in Deutsch, eine Lösung für mein Problem herauslesen können. * Dann beginnt die FHEM-Foren-Rallye. * Die Verwirrung steigt. * Viele Aussagen in den Foren sind oft missverständlich. Einige auch einfach falsch. * Irgendwann dann vielleicht ein Beitrag eines Hero Members. * Ich komme der Sache näher. * Ich werfe einen Blick in den Source-Code. * Das Bild der Funktionsweise verdichtet sich. * Was war eigentlich nochmal mein Problem? * Alles nochmal zusammenfassen und eine allgemeine Anleitung schreiben. * Aha, WikiSeite. * Nach dieser Anleitung kann ich nun endlich mein Problem systematisch lösen.
FHEM hat nach eigener Angabe auf der Statistikseite eine Verbreitung von knapp über 5000 Installationen.
Siehe hierzu FHEM Statistik.
Von diesen befinden sich weit mehr als 4000 in Deutschland. Warum also eine englische Dokumentation oft als die verbindliche in den Vordergrund stellen.
Bei den Informationen zum FHEM e.V. findet man die Aussage:
"Durch den Verein sichern wir nachhaltig den Fortbestand der Software für den weltweiten Kreis von mehr als 20.000 Anwendern.“, erläutert Rudolf König, geschäftsführender Vorstand und Initiator von FHEM.
Irgendwo dazwischen liegt wohl die Wahrheit.
Fehlerprotokolle
Ausfall 2021-12-18
Der Perl-Task steht bei 100% und FHEM hat seine eigentliche Funktion eingestellt.
Test 1:
strace -d -p <PID> gibt eine Endlosschleife aus 'select' und 'read' aus.
Test 2:
sysdig zeigt das gleich Phaenomen, aber noch ein wenig mehr drumherum.
Der Zugriff auf /dev/ttyACM2 geht ins Leere.
Test 3:
dmesg -T
[Sa Dez 18 23:55:03 2021] usb usb2-port1: disabled by hub (EMI?), re-enabling...
[Sa Dez 18 23:55:03 2021] usb 2-1: USB disconnect, device number 8
[Sa Dez 18 23:55:03 2021] cdc_acm 2-1:1.0: failed to set dtr/rts
[Sa Dez 18 23:55:03 2021] usb 2-1: new full-speed USB device number 9 using ohci-pci
[Sa Dez 18 23:55:04 2021] usb 2-1: New USB device found, idVendor=03eb, idProduct=204b, bcdDevice= 0.01
[Sa Dez 18 23:55:04 2021] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[Sa Dez 18 23:55:04 2021] usb 2-1: Product: TPUART
[Sa Dez 18 23:55:04 2021] usb 2-1: Manufacturer: busware.de
[Sa Dez 18 23:55:04 2021] usb 2-1: SerialNumber: 8543934393935160B1C1
[Sa Dez 18 23:55:04 2021] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
Obwohl ich in fhem.cfg das USB-Device bei 'path' angelegt habe, erfolgte der Zugriff auf /dev/ttyACM2
define EIB TUL tul:/dev/serial/by-id/usb-busware.de_TPUART_XXXXXXXXXXXXXXXXX0B1C1-if00 1.1.251
An meinem FHEM-Rechner ist eine Fanfare als Tuerklingel angebracht. Aus dem Schalltrichter hoert man ab und zu ein deutliches Knacken. Dieser 'Schaltknack' von einigen Verbrauchern im Haus fuehrt durch Übersprechen, Transienten, Bursts oder Spikes zu Spannungsschwankungen, die nicht nur diesen hörbar machen, sondern auch die angeschlossenen USB-Geräte kurzzeitig "disconnecten". Den Reconnect unter einem anderen Namen werde ich demnaechst unterbinden. Warum aber FHEM nicht auf das Pfad-Device zugreift kann ich nicht nachvollziehen. Der FHEM-Rechner ist ueber eine USV im Betrieb, die eigentlich die Stoerungen abblocken sollte. Eine weitere Stoerquelle wäre evtl auch noch der EIBus. Die EIBus-Kabel liegen dicht an dicht an den stromfuehrenden Leitungen. Ich werde im Auge behalten, ob immer der TPUART der Uebeltaeter ist.
Ausfall 2022-02-13
Der Perl-Task steht bei 100% und FHEM hat seine eigentliche Funktion eingestellt.
Wie das letzte Mal (s.o.) erst mal mit strace -p <fhem-pid> nachgeschaut was das Perl-Script denn gerade so tut:
select(16, [12], NULL, [12], {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
read(12, "", 8) = 0
select(16, [12], NULL, [12], {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
read(12, "", 8) = 0
select(16, [12], NULL, [12], {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
read(12, "", 8) = 0
select(16, [12], NULL, [12], {tv_sec=0, tv_usec=0}) = 1 (in [12], left {tv_sec=0, tv_usec=0})
read(12, "", 8) = 0
Fhem versucht auf den Filedescriptor 12 zuzugreifen, was offensichtlich nicht gelingt.
ls -l /proc/<fhem-pid>/fd
zeigt
lr-x------ 1 root root 64 13. Feb 08:56 0 -> /dev/null
l-wx------ 1 root root 64 13. Feb 08:56 1 -> /var/log/fhem/fhem-2022-02.log
lrwx------ 1 root root 64 13. Feb 08:56 10 -> /dev/ttyACM1
lrwx------ 1 root root 64 13. Feb 08:56 11 -> /dev/ttyS4
lrwx------ 1 root root 64 13. Feb 08:56 12 -> /dev/ttyACM0 (deleted)
lrwx------ 1 root root 64 13. Feb 08:56 13 -> socket:[43347423]
lrwx------ 1 root root 64 13. Feb 08:56 18 -> /dev/ttyUSB0
l-wx------ 1 root root 64 13. Feb 08:56 2 -> /var/log/fhem/fhem-2022-02.log
lrwx------ 1 root root 64 13. Feb 08:56 23 -> socket:[65592936]
l-wx------ 1 root root 64 13. Feb 08:56 3 -> /var/log/fhem/fhem-2022-02.log
lrwx------ 1 root root 64 13. Feb 08:56 4 -> socket:[43347429]
lrwx------ 1 root root 64 13. Feb 08:56 5 -> socket:[43347419]
l-wx------ 1 root root 64 13. Feb 08:56 6 -> /var/log/fhem/fhem-2022-01.log
lrwx------ 1 root root 64 13. Feb 08:56 7 -> socket:[43347420]
Bei 12 sieht man auch schon den Uebeltaeter (/dev/ttyACM0 (deleted)).
lsof -i -a -p 28676
zeigt /dev/ttyACM0 auch nicht als LISTEN.
ttyACM0 gibt es nicht mehr. Dafuer ein ttyACM2.
fhem:/dev # ll /dev/ttyACM*
crw-rw---- 1 root dialout 166, 1 9. Jan 17:26 /dev/ttyACM1
crw-rw---- 1 root dialout 166, 2 12. Feb 21:52 /dev/ttyACM2
ll /dev/serial/by-id/usb-*
lrwxrwxrwx 1 root root 13 29. Okt 07:48 /dev/serial/by-id/usb-busware.de_CUL868-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 12. Feb 21:52 /dev/serial/by-id/usb-busware.de_TPUART_XXXXXXXXXXXXXXXXXXXXXXXXXXX-if00 -> ../../ttyACM2
lrwxrwxrwx 1 root root 13 9. Nov 20:04 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0
Also schon wieder der TPUART!
Feb 12 21:52:12 fhem kernel: usb usb2-port1: disabled by hub (EMI?), re-enabling...
Feb 12 21:52:12 fhem kernel: usb 2-1: USB disconnect, device number 9
Feb 12 21:52:12 fhem kernel: cdc_acm 2-1:1.0: failed to set dtr/rts
Feb 12 21:52:13 fhem kernel: usb 2-1: new full-speed USB device number 10 using ohci-pci
Feb 12 21:52:13 fhem kernel: usb 2-1: New USB device found, idVendor=03eb, idProduct=204b, bcdDevice= 0.01
Feb 12 21:52:13 fhem kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 12 21:52:13 fhem kernel: usb 2-1: Product: TPUART
Feb 12 21:52:13 fhem kernel: usb 2-1: Manufacturer: busware.de
Feb 12 21:52:13 fhem kernel: usb 2-1: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXXXXX
Feb 12 21:52:13 fhem kernel: cdc_acm 2-1:1.0: ttyACM2: USB ACM device
Feb 12 21:52:13 fhem snapd[2856]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug
Fundstueck aus dem Internet:
udevadm test -a -p $(udevadm info -q path -n /dev/your_device_name)
Die Optionen -a und -p fuehrten bei mir zum Fehler!
Ausfall 2022-10-01
Heute erneut ein Ausfall mit (fast) den gleichen Symptomen. Der Webbrowser antwortet mit einem TimeOut
strace zeigt allerdings etwas anderes.
strace: [wait(0x00857f) = 21225] WIFSTOPPED,sig=133
strace: next_event: queued pid 21225
strace: next_event: dequeued pid 21225
ioctl(4, TIOCOUTQstrace: [wait(0x00857f) = 21225] WIFSTOPPED,sig=133
strace: next_event: queued pid 21225
strace: next_event: dequeued pid 21225
, [0]) = 0
strace: [wait(0x00857f) = 21225] WIFSTOPPED,sig=133
strace: next_event: queued pid 21225
strace: next_event: dequeued pid 21225
select(24, [4 5 7 8 9 10 11 12 13 14 16 17 18 19 21 22], NULL, NULL, {tv_sec=0, tv_usec=408834}strace: [wait(0x00857f) = 21225] WIFSTOPPED,sig=133
strace: next_event: queued pid 21225
strace: next_event: dequeued pid 21225
) = 0 (Timeout)
Mit dem Makro WIFSTOPPED kann ein Prozess zwischen einem angehaltenen und einem beendeten Prozess unterscheiden.
Interessant dieses Mal. Der Webzugriff Port 8083 fuehrte zwar zum TimeOut, aber ein Zugriff per telnet Port 7072 gelang und ein 'fheminfo' und 'list' zeigten eine normale Aktivitaet. Einzig die Zeit bis zum fhem-Prompt war ungewoehnlich lang.
GRRRRR! S.. dummer Fehler. FHEM war schuldlos. Das Zertifikat war abeglaufen und der Zugriff per https daher blockiert. Der Zugriff per http war in Ordnung.
Die automatische Aktualisierung der Kommentare aktivieren.