Erkennung des Ausfalls von FS20 Interfaces und Warnung.

[tomleitner]

Hallo,

Ich benutzen folgenden Code um mir Whatsapp Meldungen zu schicken wenn ein FS20 Interface ausgefallen ist.
Das ist bei mir notwendig weil zwei der Interfaces über TCP/IP angebunden sind:

Code Auswählen Erweitern

# --------------------------------------------------------------------------------------------------------------------------
# Warnung bei Ausfall von FS20 Interfaces

define DoWarningCOCAusfall DOIF ([COC:state] ne "Initialized") \
        (set TomHandy send COC Interface ausgefallen !!!) \
    DOELSE () \
        (set TomHandy send COC Interface wieder OK !!!)

define DoWarningCUL1Ausfall DOIF ([CUL1:state] ne "Initialized") \
        (set TomHandy send CUL1 Interface ausgefallen !!!) \
    DOELSE () \
        (set TomHandy send CUL1 Interface wieder OK !!!)

define DoWarningCUL433Ausfall DOIF ([CUL433:state] ne "Initialized") \
        (set TomHandy send CUL433 Interface ausgefallen !!!) \
    DOELSE () \
        (set TomHandy send CUL433 Interface wieder OK !!!)

Mein FHEM läuft auf einem Raspberry Pi. Nun habe ich gestern durch diverse Umsteckarbeiten den Raspberry Pi einfach ausgeschaltet und nach dem Einschalten war das CUL1 Interface offline -- habe ich erst in der Früh gemerkt weil diverse
Dinge nicht geschalten wurden. Analyse des Logfiles ergab folgendes:

Code Auswählen Erweitern

2016.06.17 17:33:23 3: Opening CUL1 device 192.168.1.17:2003
2016.06.17 17:33:24 3: CUL1 device opened
2016.06.17 17:33:24 1: 192.168.1.17:2003 disconnected, waiting to reappear (CUL1)
2016.06.17 17:33:24 1: Cannot init 192.168.1.17:2003, ignoring it (CUL1)

Ich habe auch KEINE Whatsapp Meldung bekommen. Was mich stört ist "Cannot init .... IGNORING IT!!!"  Wie kann das sein? Er darf ja das Interface nicht einfach ignorieren. Er sollte in regelmäßigen Abständen versuchen es wieder zu öffnen? Wie kann man das erreichen?

Danke & Ciao // Tom

[rudolfkoenig]

Falls ein CUL ueber USB definiert ist, und beim Start nicht eingesteckt ist (oder spaeter ausgesteckt wird), dann versucht das Modul 00_CUL.pm es alle 5 Sekunden zu oeffnen, d.h. nach dem Wiedereinstecken sollten hoechsten 5 Sekunden vergehen.
Falls das CUL ueber TCP/IP angebunden ist, dann ist diese Zeitspanne 60 Sekunden.

Ich habe es gerade getestet: dieser Mechnismus funktioniert fuer USB und TCP, egal ob das CUL vor dem FHEM-Start oder im Betrieb abgesteckt und spaeter wieder eingesteckt wird.

Falls das CUL verfuegbar ist (via TCP/IP oder USB), dann wird es initialisiert, wobei unter anderem geprueft wird, ob es sich um ein CUL handelt. Wenn das Modul der Ansicht ist, dass das nicht der Fall ist, dann wird die Meldung "ignoring it" ausgegeben. Status bleibt auf "opened", was nicht ganz korrekt ist. Ich bin z.Zt. nicht ueberzeugt, dass diese Pruefung bei "falschen" Geraeten regelmaessig erfolgen soll.

Falls du mir eine Methode beschreibst, wie ich dein Problem reproduzieren kann (d.h. mit einem "richtigen" CUL ein "ignoring it" provozieren kann), bin ich bereit das Modul anzupassen.

[tomleitner]

Vielen Dank. Also so sollte man es reproduzieren können. Habe das CUL wie folgt definiert:

Code Auswählen Erweitern

define CUL1 CUL 192.168.1.17:2003 1334
attr CUL1 rfmode slowRF
attr CUL1 showtime 1

Auf dem Remote Raspi läuft ser2net mit folgender Konfiguration:

Code Auswählen Erweitern

2003:raw:0:/dev/serial/by-id/usb-busware.de_CUL868-if00:115200 NONE 1STOPBIT 8DATABITS

Passiert ist es, wie ich den Raspi auf dem FHEM läuft einfach abgesteckt habe und neu eingeschaltet habe.

Kannst Du nicht auch im Code nachsehen unter welchen Bedingungen das "IGNORING IT" kommt?

Danke und Ciao // Tom

[rudolfkoenig]

Auf dem Remote Raspi läuft ser2net mit folgender Konfiguration:

Ich habe ser2net installiert, Problem nachgestellt, und gefixt. Bei Abwesenheit kommt weiterhin die "waiting to reappear" Meldung einmal die Minute (ser2net Spezial), das bleibt erstmal auch so.

Kannst Du nicht auch im Code nachsehen unter welchen Bedingungen das "IGNORING IT" kommt?

Vielen Dank fuer den bestimmt nett gemeinten Ratschlag, aber erstens habe ich den Grund weiter oben schon geschrieben (lese: ich habe schon nachgeschaut), und zweitens ist aus dem FHEM-Code alleine nicht abzuleiten, wie die andere Seite (ser2net/socat/etc) sich im Fehlerfall verhaelt. Im Code steht auch nicht drin, was die Benutzer in welcher Reihenfolge veranstalten.

[tomleitner]

Super --- danke fürs Nachstellen & fixen ...

Ciao // Tom

[fast-eddy]

@Rudi:
In deinem Post weiter oben schreibst du:

Falls ein CUL ueber USB definiert ist, und beim Start nicht eingesteckt ist (oder spaeter ausgesteckt wird), dann versucht das Modul 00_CUL.pm es alle 5 Sekunden zu oeffnen, d.h. nach dem Wiedereinstecken sollten hoechsten 5 Sekunden vergehen.
Falls das CUL ueber TCP/IP angebunden ist, dann ist diese Zeitspanne 60 Sekunden.

Das tut bei mir nicht
Nach Abziehen meines Remote CUL geht dieser in den state:disconnected - Stecke ich den CUL wieder ein passiert nichts.
Habe mir daher mit einem DOIF beholfen um diese Funktion nachzustellen. Würde mich aber schon interessieren warum das bei mir nicht out-of-the-box funktioniert???
Mein Remote CUL steckt via ser2net an einem Raspi Host. Abgesehen davon funzt alles wie es soll.

CU,
Ralf

[rudolfkoenig]

Kannst du bitte in 00_CUL.pm, Funktion CUL_Ready, DevIo_OpenDev Aufruf zweiten Parameter von 1 auf 0 aendern, Problem reproduzieren, und Log hier posten?