FHEM stürzt ab (?)

[erwin]

...könnte man ggf. alternativ auch checken, ob es nicht sinnvoll wäre, den aufgerufenen Code zu überarbeiten...?

Ich hab keine idee dazu, wie man  devices vom probing ausschließen könnte, die ANDEREN daemons gehören... Genau diese Situation führt zu z.b. "FHEM hängt", daemon restarts durch systemd, usw.... - Alles relativ schwierig zu debuggen....
Beispiel: knxd, owserver, gibts da noch weitere ?
m.M. sollte man das während fhem init nicht machen, entweder sind die richigen devices bereits (richtig) definiert, oder es wird im laufenden Betrieb was neues angesteckt, da könnte man allerdings erwarten, dass der User weiß was er tut! - bzw. in der doku prominent darauf hinweisen...
l.g. erwin

[Beta-User]

Hmm, dieses zusätzliche Problem war mir nicht in der Form bewußt, das Grundproblem des eher ineffizienten Ablaufs führt aber nach meinem Verständnis dann dazu, dass das insgesamt "rätselhaft" (aus Usersicht) wird.

Nach meinen eigenen Erfahrungen hängt Rudi halt ziemlich an initialUsbCheck, meine grundsätzliche (fast unveränderte) Meinung hatte ich ja schon kundgetan.

Aber wenn man an dem ganzen festhalten will, sollte man m.E.
- erst alle Schnittstellen in ein Array schreiben,
- da rauswerfen, was man schon kennt,
- dann mit @9600 (?) starten und dabei auch "modem-type" Geräte in einer "Negativliste" abchecken (und so z.B. ConBee II, CC253x, ...) und direkt aus dem array werfen?

Vielleicht würde es mehr Sinn machen, den alten Thread aufzuwärmen und direkt auf Rudi zuzugehen.

[erwin]

Muss mich selbst zitieren: 

ch hab keine idee dazu, wie man  devices vom probing ausschließen könnte,

Ein:

Code Auswählen Erweitern

sudo lsof /dev/ttyUSB0
bringt u.a den daemon namen, wenn opened, sonst nix!
bin allerdings nicht sicher, ob lsof in den distris vorhanden ist....
erwin

[Beta-User]

Na ja, der Check macht ja v.a. auf dem Pi Probleme, und da dürfte es da sein? (habe grade keinen Pi im Einsatz).
Man müßte halt den Fall abfangen, dass es nicht da ist (dann halt keine Einschränkung des Checks), aber das sollte eigentlich nicht so schwierig sein.

Aber wie gesagt: Das hier ist eigentlich der falsche Ort für diese Diskussion...

[erwin]

ja, sicher falscher Ort, aber die History ist nicht zu vernachlässigen...
Es hat mir keine Ruhe gelassen: lsof ist tatsächlich NICHT in der RASPI distr. enthalten!.
Ein paar Recherchen später, die Lösung:

Code Auswählen Erweitern

#!/usr/bin/perl
use strict;
use warnings;

my $res = qx(sudo /bin/fuser -v /dev/tty* 2>&1);

foreach my $line (split("\n",$res)) {
        next if $line !~ /^\/dev/ix;
        my @lineitems = split(/[\s]+/ix,$line);
        (my $dev = $lineitems[0]) =~ s/(.+)[:]$/$1/ix;
        print $dev . "\t" . $lineitems[4] . "\n";
}
exit;
... funktioniert ab wheezy! (was älteres hab ich nicht mehr  )
Und schon hat man eine negativ-Liste!

[Beta-User]

...schon, aber fhem sollte doch kein sudoer sein, oder...?

Eine der Lösungen aus https://www.perlmonks.org/?node_id=1187026 sieht mir auf den ersten Blick auch ganz universell aus:
https://www.perlmonks.org/?displaytype=displaycode;abspart=1;part=1;node_id=1187055

Nachtrag noch: Nach dem Blick in autocreate.pm (#638ff) und DevIo.pm bin ich nicht sicher, ob es FHEM bei belegten "USB"-Schnittstellen (eher wohl: lokalen?) dabei beläßt, das einmalig zu versuchen. Ist es so, dass dadurch allzugroße Verwirrung entsteht?

[Bartimaus]

Hast Du ggfls. das FHEM-Widget mit PushSync-Client installiert ? Das hatte bei mir in den letzten Tagen zum gleichen Verhalten von FHEM geführt.
Wurde aber heute Abend vom Entwickler gefixt.

[wolliballa73]

Hallo zusammen,

erstmal vielen Dank für die rege Teilnahme und die vielen Ansätze.
Ich habe mich jetzt entschlossen (nachdem das Backup-Image heute erfolgreich erstellt wurde), alles nochmal komplett neu zu installieren und dann die FHEM-Konfig zu übernehmen - glücklicherweise hab ich letzte Woche fleißig mitgeschrieben, was ich alles brauche

Mal schauen, was dabei rauskommt...

Das hier will ich aber erstmal noch beantworten:

Code Auswählen Erweitern

3. Bitte um Info
- Was für USB-Geräte hast Du?
- Was für eine Distri hast Du installiert, bitte incl. Version?
- Auf was für einer Hardwareplatform?

- 2x TPUART für 1-Wire, 1x KNX-TUL
- Raspberry 3B mit 32GB-SD
- Installiert mit Image für Raspi-OS lite Buster, aktualisiert auf Bullseye

Interessant ist, dass es (gefühlt!) mit den Problemen angefangen hat, als ich den KNX-TUL mit hingehängt habe. Davor lief das alles schon ein paar Tage mit den 1wire-Geräten. Aber garantieren kann ich das nicht...

[MadMax-FHEM]

Hast du Module mit Anmeldedaten?
Willst du auch die aktuellen Zustände der Devices mit übernehmen?

Dann ist das "nur" Übertragen der fhem.cfg nicht ausreichend...

Warum den "Umweg" : Buster upgrade auf Bullseye und nicht gleich Blseye?

Viel Erfolg, Joachim

[Beta-User]

Wie sind die USB-Geräte definiert? "by-id"? Wenn nicht, bitte im Wiki nach "mehrere USB-Geräte..." suchen.

[wolliballa73]

Hallo zusammen,

Warum den "Umweg" : Buster upgrade auf Bullseye und nicht gleich Blseye?

Das war das Image, das ich von raspberrypi.com heruntergeladen hab. Ein aktuelleres hab ich nicht gefunden (was nix heißen muss)

Die Neu-Installation hab ich jetzt mal auf Buster gelassen (natürlich mit apt upgrade)

Wie sind die USB-Geräte definiert? "by-id"? Wenn nicht, bitte im Wiki nach "mehrere USB-Geräte..." suchen

Der KNX-TUL ist über nen Symlink /dev/knx eingebunden, die beiden TPUARTs werden in der /etc/owfs.conf mit server: usb = all angesprochen.


Ich bin das dieses Mal anders herum angegangen:
- knxd installiert und getestet (problemlos, Zugriff mit ETS4 sofort möglich)
- owfs installiert und getestet (auch problemlos, Zugriff über http://fhem:2121 zeigt mir die Sensoren und Werte)

Erst dann ging's weiter mit FHEM:
- Installation aus Repository
- Dienst stoppen
- /opt/fhem aus dem Backup kopiert
- Dienst gestartet

Bisher läuft alles, was ich momentan erwarte. Die ggf. notwendigen Abhängigkeiten, die noch für weitere Device-Typen in der fhem.cfg vorhanden sind, muss ich noch nachinstallieren; die sind aber momentan nicht sooo wichtig (ENIGMA2, FritzBox, MQTT, ALEXA)

Schau'mer mal, ob das jetzt so passt...

[wolliballa73]

Update:
ähnliche Probleme wie vor der Neu-Installation
Nach einiger Zeit geht über http://fhem:8083 nix mehr. Im Log sehe ich noch, dass weitere Einträge hinzukommen.

ich hab jetzt mal initialUsbCheck deaktiviert und beobachte, ob das schon was ändert. Wenn nicht, schalte ich den OWserver ab.

[wolliballa73]

... noch 'n Update:

initialUsbCheck hat nixgebracht - nach einiger Zeit wurde wieder nix mehr in's fhem.log geschrieben und die fhem:8083 war nicht mehr erreichbar.

Ich hab jetzt das OWserver-Device aus FHEM gelöscht; bisher läuft der Rest.

Jetzt weiß ich nur noch nicht, was ich mit dieser Erkenntnis machen soll

[Wernieman]

Code Auswählen Erweitern

server: usb = all
Könnte ee sein,d as OWServer und KNX sich ins gehege kommen? Nicht das OWServer sich den USB von KNX schnappen will ...

[wolliballa73]

Könnte ee sein,d as OWServer und KNX sich ins gehege kommen? Nicht das OWServer sich den USB von KNX schnappen will ...

Meine Vermutung geht auch gerade in diese Richtung. Ich vermute die Probleme auf der owfs-Seite:
- Nach einem Neustart bekomme ich aktuelle Werte vom 1-wire-Bus, die Sensoren und TPUARTs werden mir unter http://xxxx:2121 auch angezeigt und können mit aktuellen Werten abgefragt werden
- Nach einiger Zeit sehe ich da dann je nach Tagesform entweder gar keine Sensoren mehr (nur noch die Default-Directories) oder Hunderte - die meisten mit derselben ID

Code Auswählen Erweitern

Wie sind die USB-Geräte definiert? "by-id"? Wenn nicht, bitte im Wiki nach "mehrere USB-Geräte..." suchen.
Wäre auch meine Idee gewesen, dass ich nicht auf usb=all gehen muss. Allerdings finde ich dazu nur Hinweise, wie das über 99-usb-serial.rules mit Kenntnis der Seriennummern der Devices geht. Leider sehe ich zwar meine beiden Devices:

Code Auswählen Erweitern

pi@fhem:~ $ lsusb
Bus 001 Device 007: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 006: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project


... bekomme dafür aber keine Seriennummern heraus, sondern nur die von meinem KNX-TUL:

Code Auswählen Erweitern

pi@fhem:~ $ ls -la /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Nov  9 19:32 .
drwxr-xr-x 4 root root 80 Nov  9 19:32 ..
lrwxrwxrwx 1 root root 13 Nov  9 19:32 usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00 -> ../../ttyACM0


Für sachdienliche Hinweise bin ich also nach wie vor offen

Parallel versuche ich jetzt mal, den knxd auf einen anderen Raspi auszulagern....