Zyklische Überprüfung ob CUL vrefügbar

[gloob]

Gibt es eine Möglichkeit um zu Prüfen, ob ein CUL im Netzwerk verfügbar ist?

Hintergrund ist, dass ich jetzt 2 CULs habe, die über WLAN angebunden sind und ich würde gerne ein reopen ausführen, wenn der CUL mal weg war.

[HCS]

Ich habe am LaCrosseGateway einen NanoCUL dran, den es auf einem Port transparent bereitstellt und da das gleiche Problem.
Ich habe es mit diesem at gemacht.

Code Auswählen Erweitern

define cul211Reconnector at +*00:00:30 {\
my $deviceName = "cul211";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
  fhem("set " . $deviceName . " reopen");;\
}\
\
}

Eventuell wäre es sinnvoll, sich eine Lösung im CUL-Modul zu überlegen, um dieses oder ein ähnliches Verhalten direkt im Modul zu implementieren.

Nachtrag 1: man muss in Zeile 2 den Name des CUL entsprechend anpassen.

Nachtrag 2: Vereinfachung
Aus der weiteren Diskussion hat sich ergeben, dass dieser einfache at ausreicht und sinnvoller ist:

Code Auswählen Erweitern

define cul211_Reconnect at +*00:00:30 get cul211 version

[rudolfkoenig]

Das ein USB-CUL abgesteckt ist, kriegt FHEM sofort mit. Bei einem Netzwerk-CUL dauert das 2 Stunden (TCP/IP default timeout), das kann man mit einem regelmaessig abgesetzten "get CUL uptime" (oder version/etc) beschleunigen.
Falls das Modul die Abwesenheit festgestellt hat, dann versucht es alle 5 Sekunden (USB) bzw 60 Sekunden (TCP) das Geraet neu zu initialisieren. Falls ein USB-CUL sich aufhaengt, dann sollte man das Firmware fixen, und keine Workarounds in das FHEM-Modul einbauen.

[HCS]

Falls ein USB-CUL sich aufhaengt, dann sollte man das Firmware fixen, und keine Workarounds in das FHEM-Modul einbauen.

So ist es. Aber hier geht es ja explizit um CUL im Netzwerk und zwei Stunden sind schon lange.

Bei einem Netzwerk-CUL dauert das 2 Stunden (TCP/IP default timeout), das kann man mit einem regelmaessig abgesetzten "get CUL uptime" (oder version/etc) beschleunigen.

Und genau das war die Idee, es im Modul direkt zu ermöglichen, anstatt dass man sich einen at dazu bauen muss.
Aber mit einem at geht es ja auch.

Verstehe ich das richtig, dass man sich den "set ... reopen" in meinem at-Vorschlag sparen kann, weil nach einem "get version" dann 60 Sekunden später eh ein connect versucht würde?

[rudolfkoenig]

Und genau das war die Idee, es im Modul direkt zu ermöglichen, anstatt dass man sich einen at dazu bauen muss.

Ich bin fuer Loesungen ohne Nebeneffekte immer offen.

Bin nicht sicher, ob die manuelle "set ... reopen" Loesung in allen Faellen mit dem eingebeuten equivalent ist, aber im Prinzip ja, so ist es gedacht, dass man das "set ... reopen" sparen kann.

[HCS]

Habe es ausprobiert. Das geht auch ohne den "set ... reopen"

Code Auswählen Erweitern

2016.04.24 22:33:57 1: 192.168.31.211:85 disconnected, waiting to reappear (cul211)
2016.04.24 22:34:02 1: 192.168.31.211:85 reappeared (cul211)
2016.04.24 22:34:09 3: cul211: Possible commands: BCFiAZEkGMKUYRTVWXefltx

Dann wäre die Idee folgendes:
Ein Attribut "timeout", das nur gesetzt werden darf, wenn es ein TCPDev ist (set cul211 timeout 60)
Das lässt dann einen Timer laufen, der im angegebenen Interval die version abruft (also wie der at)

Falls das so OK wäre, würde ich mich an einem Patch versuchen.
Es sei denn, das möchte gerne jemand machen, der mehr Erfahrung mit dem CUL-Modul hat.
Kann man davon ausgehen, dass jegliche CUL-firmware ein V versteht?

[gloob]

Ich habe es jetzt bei mir wie folgt eingerichtet:

Code Auswählen Erweitern

##############
# CUL 866MHz
##############
define miniCUL868 CUL 192.168.1.35:23@38400 0000
attr miniCUL868 icon cul_cul
attr miniCUL868 rfmode SlowRF
attr miniCUL868 room CUL

##############
# CUL reconnect
##############
define miniCUL868_Reconnect at +*00:00:30 {\
my $deviceName = "miniCUL868";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
  fhem("set " . $deviceName . " reopen");;\
}\
\
}
attr miniCUL868_Reconnect room CUL
attr miniCUL868_Reconnect verbose 5

Passt das so?
Leider sehe ich im Logfile nicht ob es funktioniert.

[rudolfkoenig]

Normalerweise optimiere ich nicht die von Benutzern vorgeschlagene Loesungen, hier sind aber zu viele "Fehltritte", die sich nicht verbreiten sollten:
- "<IP>:23@3840" ist falsch: entweder <ip>:<port> ODER <devicename>@<baudrate>
- 23 ist der telnet-port, und den sollte man fuer telnet lassen. Vermutlich richtig ist die Voreinstellung 2323
- CommandGet sollte man in Benutzer-Programmen nicht verwenden, fuer sowas ist fhem("get XXX YYY") da.
- wie vorhin geschrieben (und von HCS bestaetigt): das Modul versucht selbststaendig ein reconnect in 60 Sekunden-Rhythmus. Das laeuft dann parallel mit dem hier abgesetzten reopen, was wiederum zu Problemen fuehren kann.

Ich meine folgendes reicht aus:

Code Auswählen Erweitern

define miniCUL868_Reconnect at +*00:00:30 get miniCUL868 version

[Wzut]

das kann man mit einem regelmaessig abgesetzten "get CUL uptime" (oder version/etc) beschleunigen.

demnach auch mit get CUL credit10ms ?
( das läuft bei mir in einem 5 Minuten at für einen Plot der Credits )

[rudolfkoenig]

Befehl/Inhalt ist egal, Hauptsache Kommunikation mit dem CUL.

[HCS]

Ein (kleines) Problem ist, dass alle <interval> Sekunden ein

Code Auswählen Erweitern

2016.04.25 10:13:51 3: cul211Reconnector: cul211 version => V 1.66 nanoCUL868
ins Log geschrieben wird. Bekommt man mit verbose 2 oder sonstwie weg.

Was auch noch vorkommen kann ist, dass man auf "opened" stecken bleibt.

Code Auswählen Erweitern

2016.04.25 13:47:32 1: 192.168.31.211:85 disconnected, waiting to reappear (cul211)
2016.04.25 13:47:38 1: 192.168.31.211:85 reappeared (cul211)
2016.04.25 13:47:47 1: Cannot init 192.168.31.211:85, ignoring it (cul211)
Danach baut ein "get cul211 version" keine neue Verbindung mehr auf.
Dann hilft dann nur noch ein "set cul211 reopen"
Das könnte aber daran liegen, dass man mein Gateway zu einem Zeitpunkt, zu dem es gerade hoch fährt, mit dem connect auf dem linken Fuß erwischen könnte und der connect auf den port zwar schon geht, mit dem CUL aber noch nicht gesprochen werden kann.
Muss ich mal genauer untersuchen. Das wäre aber ein Fehler im Gateway und kein issue hier.

Meinen Beitrag oben passe ich mal an, dass zukünftige Leser direkt auf den richtigen Pfad geschickt werden.

[bjoernh]

Probiert man das angehängte Modul aus.
Ist aber nicht ausgiebig getestet.

Im CUL kann man dann das Attribut timeout einstellen:

timeout
     format: timeout, checkInterval;
      Checks every 'checkInterval' seconds if the last data reception is longer than 'timout' seconds ago.
      If this is the case, a reset is done for the IO-Device.

@Rudi, was hältst Du von so einer Lösung?

[rudolfkoenig]

1. Funktioniert nicht "out of the box", weil nicht jeder sein CUL myCUL nennt.
2. Die Funktion loest auch bei Funkstille aus
3. Bei einem radikalen Netzwerkabbruch (CUNO-Reset, Telekom-Zwangstrennung, etc) ist die von mir vorgeschlagene Methode einfacher und zuverlaessiger.

Ich tu mich schwer Workarounds in CUL.pm einzubauen, ohne zu wissen, was das eigentliche Problem ist.

[HCS]

Das ist die Strategie aus dem JeeLink Modul. Ich glaube auch, dass die hier nicht gut passt. Beim JeeLink kann man davon ausgehen, dass mehrere Sensoren jeweils alle vier Sekunden etwas senden und wenn nichts mehr kommt, dann ist von einem Problem auf der Empfängerseite auszugehen.

Hier ist aber (zumindest bei mir, habe nur Handsender, die selten betätigt werden) teils stundenlang Sendepause, was dann fälschlicherweise als Problem interpretiert werden würde und zu einem Reset führt.

Allerdings könnte man das zu dem umbauen, was der von Rudi vorgeschlagene at macht, nur halt Modul-intern.
Wenn der CUL auf ein Version nicht mehr antwortet, ist definitiv etwas nicht OK und wenn er an einer LAN bridge hängt, kann man recht sicher davon ausgehen, dass die weggebrochen war.

Eigentlich geht es darum, von dem zwei Stunden timeout auf eine akzeptable Zeit zu kommen, bis ein reconnect gemacht wird.