Autor Thema: [patch] 11_OWX_FRM.pm & FHEM-Crash  (Gelesen 1554 mal)

Offline jensb

  • Developer
  • Full Member
  • ****
  • Beiträge: 498
    • GitHub Projekte
[patch] 11_OWX_FRM.pm & FHEM-Crash
« am: 02 Januar 2018, 14:19:14 »
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 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.
« Letzte Änderung: 15 Januar 2018, 22:54:24 von jensb »
FHEM 5.8 - RPi 2.0 Raspbian 4.1 + PiTFT - OPi Zero Armbian 5.35
RPi/I2C: MMA845X - CUL/FS20 - RTL2882/SDR: Oregon, Alecto - EnOcean - LAN/Firmata: BMP180, TSL2561, Heatronic 3, Stromzähler (ES-Fer), Gaszähler - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - Bluetooth

Offline jensb

  • Developer
  • Full Member
  • ****
  • Beiträge: 498
    • GitHub Projekte
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #1 am: 15 Januar 2018, 23:08:23 »
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). Besser wäre es aber "reopen" in die Klassendefinition aufzunehmen und schnittstellenspezifisch zu implementieren.

Grüße,
Jens
FHEM 5.8 - RPi 2.0 Raspbian 4.1 + PiTFT - OPi Zero Armbian 5.35
RPi/I2C: MMA845X - CUL/FS20 - RTL2882/SDR: Oregon, Alecto - EnOcean - LAN/Firmata: BMP180, TSL2561, Heatronic 3, Stromzähler (ES-Fer), Gaszähler - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - Bluetooth

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5722
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #2 am: 23 Januar 2018, 06:44:22 »
OK, kann ich das dann so übernehmen ?

LG

pah

Offline jensb

  • Developer
  • Full Member
  • ****
  • Beiträge: 498
    • GitHub Projekte
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #3 am: 23 Januar 2018, 20:04:37 »
Hallo pah,

du kannst das so übernehmen, habe keine weiteren Änderungen gemacht. Die Rückmeldungen waren zuletzt positiv (z.B. hier, hier und hier).

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
FHEM 5.8 - RPi 2.0 Raspbian 4.1 + PiTFT - OPi Zero Armbian 5.35
RPi/I2C: MMA845X - CUL/FS20 - RTL2882/SDR: Oregon, Alecto - EnOcean - LAN/Firmata: BMP180, TSL2561, Heatronic 3, Stromzähler (ES-Fer), Gaszähler - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - Bluetooth

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5722
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #4 am: 24 Januar 2018, 08:24:29 »
OK, habe den Patch übernommen, wird umgehend eingecheckt. Danke für die Mitwirkung.

Reopen wird eine Weile dauern.

LG

pah
Gefällt mir Gefällt mir x 3 Liste anzeigen

Offline dirigent

  • Full Member
  • ***
  • Beiträge: 479
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #5 am: 24 Januar 2018, 17:02:56 »
Läuft.  :)

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten

Offline dirigent

  • Full Member
  • ***
  • Beiträge: 479
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #6 am: 14 Februar 2018, 11:34:03 »
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
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten

Offline stefan-dd

  • Full Member
  • ***
  • Beiträge: 185
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #7 am: 14 Februar 2018, 21:38:07 »
Dort gibt es noch ein Problem, aber keine Abhilfe.

Offline dirigent

  • Full Member
  • ***
  • Beiträge: 479
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #8 am: 15 Februar 2018, 11:36:30 »
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
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten

Offline jensb

  • Developer
  • Full Member
  • ****
  • Beiträge: 498
    • GitHub Projekte
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #9 am: 15 Februar 2018, 20:17:27 »
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
FHEM 5.8 - RPi 2.0 Raspbian 4.1 + PiTFT - OPi Zero Armbian 5.35
RPi/I2C: MMA845X - CUL/FS20 - RTL2882/SDR: Oregon, Alecto - EnOcean - LAN/Firmata: BMP180, TSL2561, Heatronic 3, Stromzähler (ES-Fer), Gaszähler - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - Bluetooth
Informativ Informativ x 1 Liste anzeigen

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5722
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #10 am: 16 Februar 2018, 10:38:57 »
Macht er bei Gelegenheit.

LG

pah
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline stefan-dd

  • Full Member
  • ***
  • Beiträge: 185
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #11 am: 16 Februar 2018, 10:57:14 »
Wenn es mal länger dauert...

Zitat
Unsinn, aber hoch drei.

11_OWX_FRM wurde gepatcht, siehe den entsprechenden Thread.

pah

Mit der vorgeschlagenen Änderung ist die Meldung weg.

Offline dirigent

  • Full Member
  • ***
  • Beiträge: 479
Antw:[patch] 11_OWX_FRM.pm & FHEM-Crash
« Antwort #12 am: 18 Februar 2018, 17:47:37 »
@pah

Danke für's Einchecken. Die Meldung ist nun weg.  :)

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten

 

decade-submarginal