Wenn OneWire-Devices an Firmata-Devices angeschlossen werden, kann es zu Fehlkonfigurationen kommen (z.B. nicht existierenden Pin konfiguriert oder der Verbindungsaufbau zwischen FHEM und Firmata-Device ist gestört - dann stehen die Metadaten des Firmata-Devices nicht zur Verfügung). Derartige Fehler führen derzeit zum Absturz von FHEM, da der Firmata-Treiber sich gegen unplausible Zugriffe wehrt (siehe z.B. Fehlerbeschreibung aus diesen (https://forum.fhem.de/index.php/topic,81104.msg738373.html#msg738373) Thread) und der Anwendungscode das Einfangen und Behandeln sollte .
Der beigefügte Patch führt die Fehlerbehandlung durch (eval) und wurde von @ThoTo und mir erfolgreich getestet. Als Ergebnis der Fehlerbehandlung steht dann im "state" reading des OWX-Devices z.B. "error initializing: pin 5".
Grüße,
Jens
UPDATE 07.01.2019: Patch aktualisiert, nun werden alle perl-firmata Aufrufe mit eval abgesichert.
Patch aktualisiert, nun erfolgt die OneWire-Initialisierung nach jedem Firmata-Connect.
@pah
Der Ansatz für den Reconnect ist Low-Level (siehe Define und Init), aber so können die vorhandenen Abläufe und das OWX-Modul unverändert bleiben.
Mit einer ähnlichen Vorgehensweise könnte man das "reopen" Kommando von OWX in der Weboberfläche bei Verwendung von FRM unsichtbar machen, damit es durch unbedachten Aufruf nicht zu Fehlern kommt (siehe hier (https://forum.fhem.de/index.php/topic,81815.msg749391.html#msg749391)). Besser wäre es aber "reopen" in die Klassendefinition aufzunehmen und schnittstellenspezifisch zu implementieren.
Grüße,
Jens
OK, kann ich das dann so übernehmen ?
LG
pah
Hallo pah,
du kannst das so übernehmen, habe keine weiteren Änderungen gemacht. Die Rückmeldungen waren zuletzt positiv (z.B. hier (https://forum.fhem.de/index.php/topic,81104.msg749466.html#msg749466), hier (https://forum.fhem.de/index.php/topic,81104.msg752624.html#msg752624) und hier (https://forum.fhem.de/index.php/topic,81815.msg751382.html#msg751382)).
Die Randproblematik mit dem "reopen" bin ich nicht angegangen, da dafür auch Anpassungen an OWX erforderlich wären (z.B. in der SetFn "reopen" blockieren, wenn OWX_FRM verwendet wird).
Grüße,
Jens
OK, habe den Patch übernommen, wird umgehend eingecheckt. Danke für die Mitwirkung.
Reopen wird eine Weile dauern.
LG
pah
Läuft. :)
Gruß Jens
Mir ist etwas seltsames aufgefallen. Wenn ich "/etc/init.d/fhem stop" ausführe, werden meinen FRM-OWX-Devices in der fhem.cfg wieder IODevs zugeordnet. Das passiert allerdings nur bei "stop", nicht bei "start" oder bei "shutdown restart". Die Module sind aktuell.00_OWX.pm 15904 2018-01-16 09:19:19Z phenning
11_OWX_FRM.pm 15978 2018-01-24 07:27:33Z phenning
Gruß Jens
Dort gibt es noch ein Problem, aber keine Abhilfe.
Mittlerweile habe ich neue Info's.
Das Attribut IODev wird nach dem Start von FHEM temporär angelegt. In der fhem.cfg erscheint kein Eintrag. Nach einem Neustart passiert das Gleiche. Sobald ich einmal "Save config" aufrufe, wird es in die fhem.cfg geschrieben und FHEM meckert korrekt beim Neustart, dass es ein solches Attribut nicht gibt. Ich vermute, es liegt am Aufruf von AssignIoPort in der 10_FRM.pm. Also werde ich mich vertrauensvoll an jensb wenden.
Gruß Jens
Hallo Jens,
danke für die Blumen, aber so merkwürdig dir das Verhalten vorkommen mag, es ist grundsätzlich richtig:
FRM ist das IODev für OWX (also die Schnittstelle, die OWX verwendet, um an die OneWire-Devices zu kommen). Zum Registrieren ruft das Modul OWX_FRM FRM_Init_Pin_Client auf und das wiederum ruft AssignIoPort auf. Letzteres ist eine Funktion des FHEM-Kerns und diese Funktion legt das Attribut an, wenn es fehlt. Es ist ein FHEM-Standard, dass das IODev beim Slave-Device (in diesem Fall OWX) als Attribut registriert wird.
Schau dir zum Vergleich mal ein OneWire-Device an (z.B. OWTHERM) - da ist das OWX-Modul als IODev-Attribut gesetzt.
Dass sich andererseits FHEM beim Starten über das Attribut beschwert, liegt wiederum daran, dass OWX_FRM kein eigenständiges Modul ist, sonder eine Klasse, die vom Modul OWX eingebunden wird. Das OWX Modul ist selbst IODev für andere Module, sieht aber aktuell nicht in vollem Umfang vor, dass es bei Verwendung von OWX_FRM selbst auf ein IODev angewiesen ist. Was fehlt, um die Fehlermeldung zu verhindern, ist in Zeile 131ff von 00_OWX.pm folgendes einzutragen:
$hash->{AttrList}= "asynchronous:0,1 dokick:0,1 ".
"interval timeout opendelay expert:0_def,1_detail ".
"IODev ".
$readingFnAttributes;
Diese Änderung müsste @pah integrieren.
Grüße,
Jens
Macht er bei Gelegenheit.
LG
pah
Wenn es mal länger dauert...
ZitatUnsinn, aber hoch drei.
11_OWX_FRM wurde gepatcht, siehe den entsprechenden Thread.
pah
Mit der vorgeschlagenen Änderung ist die Meldung weg.
@pah
Danke für's Einchecken. Die Meldung ist nun weg. :)
Gruß Jens