[GELÖST] Remote CUL per DOIF überwachen und ggf. neu starten

[fast-eddy]

Moin,

aufgrund von Reichweitenproblemen habe ich meine Gateways CUL(FS20), CUL(HM), JeeLink etc. jetzt via ser2net im Haus verteilt.
Klappt soweit auch ganz gut. Jetzt wollte ich die Verfügbarkeit der CUL über ein DOIF prüfen und falls einer auf "disconnected" steht
via "reopen" alle 60 Sekunden einen Neustart erzwingen. Auch das funktioniert im Prinzip!

Nur habe ich jetzt das Problem, dass mein DOIF alle 60 Sekunden ein "reopen" auslöst, auch wenn der Status des CUL mittlerweile
wieder auf "initialized" steht.
Anscheinend stehe ich bei dem Attribut "repeatcmd " irgendwie auf dem Schlauch.

Mein DOIF sieht folgendermassen aus:

Code Auswählen Erweitern

define REOPEN_CUL DOIF ([CUL_0:state] eq "disconnected") (set CUL_0 reopen)
attr REOPEN_CUL group Watchdog
attr REOPEN_CUL repeatcmd 60
attr REOPEN_CUL room STEUERUNG

Mein CUL_0 hat den state = "Initialized"
Und der Event Monitor gibt mir folgendes aus:

Code Auswählen Erweitern

2016-06-14 16:32:04 DOIF doif_watchdog_REOPEN_CUL cmd_event: CUL_0
2016-06-14 16:32:04 DOIF doif_watchdog_REOPEN_CUL cmd_1
2016-06-14 16:32:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: 14.06.2016 16:33:04 cmd_1 CUL_0
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: no timer
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL cmd_nr: 1
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL cmd: 1
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL cmd_event: CUL_0
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL cmd_1
2016-06-14 16:33:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: 14.06.2016 16:34:04 cmd_1 CUL_0
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: no timer
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL cmd_nr: 1
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL cmd: 1
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL cmd_event: CUL_0
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL cmd_1
2016-06-14 16:34:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: 14.06.2016 16:35:04 cmd_1 CUL_0
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: no timer
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL cmd_nr: 1
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL cmd: 1
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL cmd_event: CUL_0
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL cmd_1
2016-06-14 16:35:04 DOIF doif_watchdog_REOPEN_CUL wait_timer: 14.06.2016 16:36:04 cmd_1 CUL_0

Kann mir jemand sagen wo mein Denkfehler liegt?

Danke und Grüße,
Ralf

[Ellert]

Ergänze das DOIF mit

Code Auswählen Erweitern

DOELSEIF ([CUL_0] eq "initialized")

[fast-eddy]

Hi Ellert,

danke für Deinen Vorschlag. Hat aber leider nichts gebracht.
Hätte mich aber auch gewundert denn laut commandref sind DOELSEIF und DOELSE optional
und die Idee dahinter nur die condition ohne command einzufügen habe ich eh nicht verstanden ...?

Folgendes ist mir aber aufgefallen:
Geht CUL_0 auf "disconnected" schlägt das DOIF sofort an und feuert "set CUL_0 reopen" ab.

Setze ich CUL_0 manuell auf "reopen" wechselt der state von CUL_0 auf "initialized"

Im DOIF steht in den Readings aber weiterhin

Code Auswählen Erweitern

e_CUL_0_STATE  disconnected

D.h. das DOIF bekommt die Änderung von intitialized -> disconnected mit aber nicht aber disconnected -> initialized.
Aus diesem Grund ist die condition immer erfüllt und das Command wird alle 60 Sekunden ausgeführt.

Nur warum ?

Hat jemand eine Erklärung dafür ?

CU,
Ralf

[fast-eddy]

Geht CUL_0 auf "disconnected" schlägt das DOIF sofort an und feuert "set CUL_0 reopen" ab.

Wie ich gerade festgestellt habe wird durch das DOIF auch das "reopen" sauber ausgeführt und der CUL geht wie gewünscht wieder in den Status "initialized"
Das DOIF Reading bleibt aber wie zuvor beschrieben: e_CUL_0_STATE  disconnected

[fast-eddy]

... hat keiner eine Idee wie ich DOIF beibiege das state Reading meines CUL korrekt zu lesen bzw. zu aktualisieren?

CU.
Ralf

[Per]

Wie lange ist CUL_0 in reopen?
Ein paar Ideeen dazu:
- versuch mal wait 1:0
- probier mal ein selftrigger wait (dazu muss o.a. wait aber gesetzt sein)
- tausch mal die Reihenfolge der DOIF-Zweige (dann aber mit wait 0:1)
- statt DOELSEIF ([CUL_0] eq "initialized") probier DOELSEIF ([CUL_0] ne "disconnected")

Noch ne Idee (Hardcore!):
Probier ein separates DOIF ([CUL_0] eq "initialized"), um zu sehen, ob der Trigger überhaupt was auslöst.

[fast-eddy]

Hi Per,

danke für Dein Feedback.
<<< Wie lange ist CUL_0 in reopen?>>>
...meintest Du diconnected? Das hängt davon ab was das Problem war bspw. temporärer Stromausfall oder wie in den letzten Tagen Spannungsschwankungen durch Blitzschlag....

Das Auslösen des cmd ist nicht mein Problem das tut genau das was es soll: Auslösen wenn state=disconnected (Condition = TRUE) und cmd alle 60 Sekunden wiederholen.

Code Auswählen Erweitern

define REOPEN_CUL DOIF ([CUL_0:state] eq "disconnected") (set CUL_0 reopen)
attr REOPEN_CUL repeatcmd 60

Mein Problem ist das Stoppen der Wiederholung bei Condition = FALSE (state!=disconnected). Das DOIF bekommt die Änderung des Readings state nicht! Selbst nach manuellem reopen steht im Reading des DOIF weiterhin  e_CUL_0_STATE  disconnected. D.h. der Stopptriger kann nicht auslösen und die Wiederholungen laufen immer weiter...

Habe die Condition auch schon generalisiert indem ich die Bedingung umgedreht habe:

Code Auswählen Erweitern

define REOPEN_CUL DOIF ([CUL_0:state] ne "initialized") (set CUL_0 reopen)
attr REOPEN_CUL repeatcmd 60
Auch hier gleicher Effekt: Start-Trigger funktioniert aber Statuswechsel kommt im DOIF nicht an d.h. der Stopp-Ttrigger funktioniert nicht (...auch hier im DOIF Reading statisch e_CUL_0_STATE  disconnected).

... hmmm! Habe mittlerweile bei mir fast alle Logiken auf DOIF umgestellt und dachte ich hätte das Modul verstanden!
Aber vielleicht ist das ja auch ein Bug - was ich mir bei Damians Modul fast nicht vorstellen kann. 

CU,
Ralf

[Per]

Und wo ist der DOELSEIF-Pfad?!

[fast-eddy]

Und wo ist der DOELSEIF-Pfad?!

...brauche ich den? Es ist doch nur eine monokausale Condition?

Es soll ja keine zweite Aktion ausgelöst werden - Ich wüsst auch nicht welche (reziprok zu reopen)
Ich dachte das ganze funktioniert analog zu den DOIF Anwendungen bei denen nur eine Push Message versendet wird, dort definiere ich ja auch keine DOELSEIF oder DOELSE Konstruktionen, oder?

Auszug Commandref:

Code Auswählen Erweitern

define di_washer DOIF ([power:watt]<2) ({system("wmail washer finished")})
attr di_washer wait 300

Ich bin bisher davon ausgegangen, dass DOELSEIF / DOELSE Zweige nur dann benötigt werden, wenn es mehr als eine Aktion ausgelöst werden soll.
Aber vielleicht stehe ich da ja auch auf irgendwie auf dem Schlauch  ...
Werde jetzt auf jeden Fall mal einen DOELSE ohne CMD Zweig ergänzen - mal sehen was passiert

[fast-eddy]

FUNKTIONIERT!!!!

@Ellert @Per:
IHR SEIT DIE GRÖSSTEN! Danke für Eure Hilfestellung!

...kaum liest man richtig schon klappts auch mit dem Nachbarn 
Stand irgendwie total auf dem Schlauch und hatte nicht verstanden,
was ich als zweite Aktion definieren sollte - dass man die auch weglassen
kann hatt ich total verdrängt.

Warum das dann beim Versenden der Pushmessages auch ohne DOELSE
funktionier bleibt mir aber ein Rätsel...

[Per]

Du brauchst das DOELSEIF, um die Aktion (repeatcmd !) wieder zu beenden. Woher soll das DOIF, welches ja nur einschaltet, das sonst wissen.

[RaspiLED]

Hi,
und wie ist Deine Lösung jerzt final?
Gruß Arnd