FB_CALLMONITOR disconnected

elektrikpe2 · 03 April 2018, 21:38:34

Hallo,

es gibt dazu schon einige Thread die alle älter sind, aber die scheinen irgendwie noch in der Luft zu hängen und ich ein ähnliches Problem habe. Im Log kommt laufend ei

Code Auswählen

2018.03.30 15:35:24 1: xx.xx.xx.xx:1012 disconnected, waiting to reappear (CallMonitor)
2018.03.30 15:35:25 1: xx.xx.xx.xx:1012 reappeared (CallMonitor)

und der Callmonitor reagiert anschließend auf keine Telefonaktion auf der FB. STATE ist noch opened. Nach set reopen funktioniert wieder alles bis zum nächsten disconnected. Sehe ich das richtig, dass ich mir dann mit einem at der set reopen setzt helfen kann? Und für einen Anfänger (naja 3 Monate Intensivtraining mit Hilfe des Forums) könnte ich das aus der Logfile abfangen? oder soll ich blind den at einfach setzen? Alternativ die Lösung:

Zitattca am 31 Januar 2017, 14:34:23

... stimmt, die Verbindung wird ohne Shell von FHEM bereitgestellt; mit telnet konnte ich das manuell 'schön' reproduzieren und hab's im Eifer so formuliert...

Mir ist jetzt gerade aufgefallen: schaltet man mit
Code: [Auswählen]

attr callmonitor disable 1; attr callmonitor disable 0;

klappt es; die neue listen-Verbindung wird sofort aufgebaut, die alte listen-Verbindung wird lokal nach 60s geschlossen;

Bedeutet aber auch, durch eine Aktion zu reagieren. Ach so, habe eine Cable 6490 von Unitymedia. Callmonitor ist aktiviert und es kommen auch über Calllist die Werte, wenn kein disconnect. Danke.

VG Peter

Invers · 03 April 2018, 22:27:25

Ich weiss nicht, ob das hilft, aber ich sags trotzdem mal:
Wenn man ein Update der FB, oder einen Neustart der FB gemacht hat, scheint es meistens erforderlich zu sein, auch den Pi neu zu starten. Dann geht wieder alles. Ich kann nicht genau sagen, ob es reicht, nur fhem neu zu starten.
Leider sagt deine Signatur nichts aus.

elektrikpe2 · 04 April 2018, 17:10:59

Hallo,

hatte leider keine Wirkung.

VG Peter

MadMax-FHEM · 04 April 2018, 20:03:14

Ich habe/hatte auch hin und wieder disconnects.

Habe daher ein Notify auf disconnected angelegt was einen Reconnect ausführt.

Nicht schön aber bei mir hilft das, dass der CallMonitor so arbeitet wie ich es brauche.

Hier das Notify:

Code Auswählen

defmod nReconnectFBCallMonitor notify FBCallMonitor:event:.disconnect {fhem("set FBCallMonitor reopen");; Log3(undef,3,"FBCallMonitor reconnected");;}

(raw definition)

EDIT: hab grad mal "gezählt" wie oft der Logeintrag kommt/kam. Im März waren es 62 Einträge...

Ich hab nichts davon gemerkt...

Gruß, Joachim

elektrikpe2 · 05 April 2018, 15:43:53

Habe ich eingebaut, allerdings reagiert der notify immer dann, wenn ein Gespräch beendet wird. Ich will ja nicht klüger sein als die "Henne"; aber wird das CallMonitor:event:.disconnect nicht tatsächlich bei Gesprächsende gesetzt? Während eines Gesprächs ist das nämnlich opened. Ich lass den trotzdem mal drin und beobachte weiter. Das blöde ist ja, dass der STATE vom CallMonitor opened bleibt obwohl das log etwas anderes sagt und erst nach reopen der Callmonitor wieder reagiert. Daher meinte ich ja, ob man das Ereignis nicht über das logfile abfangen könnte; dann wäre es sauberer. Aber dazu bin ich noch zu sehr Küken

VG Peter

MadMax-FHEM · 05 April 2018, 15:48:42

Hmmm, das mit dem Auflegen kann schon sein.

Hatte vorher halt "Probleme" bei 2 Anrufen hintereinander...
...und ich habe auf jeden Fall Reaktionen des Notify OHNE dass ich telefoniere

Könnte sein, dass ein anderes Event besser passt aber bei mir tut das für das was ich brauche daher lasse ich es erst mal...
...bzw. nach einem "echten/richtigerem" Event zu suchen habe/hatte ich keine Lust

Wenn du ein besseres findest: einfach posten

Gruß, Joachim

frank · 05 April 2018, 15:59:46

ZitatDaher meinte ich ja, ob man das Ereignis nicht über das logfile abfangen könnte;

mit attr readLog kann ein notify auch auf fhem.log messages reagieren.

Darrol · 05 April 2018, 21:49:44

Zitat von: elektrikpe2 am 05 April 2018, 15:43:53
... und erst nach reopen der Callmonitor wieder reagiert. Daher meinte ich ja, ob man das Ereignis nicht über das logfile abfangen könnte; dann wäre es sauberer. Aber dazu bin ich noch zu sehr Küken

VG Peter

Ich konnte das gleiche Problem bei mir darauf zurückführen, dass die Session an der Fritzbox nach 20 Minuten Inaktivität abläuft ohne das das von Fhem registriert wurde.
Ich hab mir daraufhin, wie von dir schon erwähnt, ein at-device angelegt, dass die Verbindung erneuert. Seitdem läuft der Callmonitor bei mir absolut zuverlässig.

Code Auswählen

define Callmonitor_Reopen at +*00:20:00 set Callmonitor reopen

Vielleicht hilft dir das ja auch weiter.

elektrikpe2 · 06 April 2018, 13:25:19

Hallo,

die Lösungen helfen tatsächlich alle, haben aber den Nachteil, dass sie ziemlich viel Traffic bringen. Eigentlich brauche ich ja den reopen nur, wenn der Fehler in der Log gemeldet wird. Ich habe noch einmal alles beobachtet. In keine der Devices mit Call... bewegt sich dabei etwas. Deshalb habe ich mich mal an einem readLog versucht

Code Auswählen

Internals:
   DEF        n_ReconnectCallMonitor:xx.xx.xx.xx:1012.*disconnected set CallMonitor reopen
   NAME       n_ReconnectCallMonitor
   NOTIFYDEV  n_ReconnectCallMonitor
   NR         187
   NTFY_ORDER 50-n_ReconnectCallMonitor
   REGEXP     n_ReconnectCallMonitor:xx.xx.xx.xx:1012.*disconnected
   STATE      active
   TYPE       notify
   READINGS:
     2018-04-05 20:33:03   state           active
Attributes:
   group      Fritzbox
   readLog    1
   room       91_Geraete

Die raw-Deifnition

Code Auswählen

defmod n_ReconnectCallMonitor notify n_ReconnectCallMonitor:xx.xx.xx.xx:1012.*disconnected set CallMonitor reopen
attr n_ReconnectCallMonitor group Fritzbox
attr n_ReconnectCallMonitor readLog 1
attr n_ReconnectCallMonitor room 91_Geraete

Fehler ist auch so wieder aufgetreten. Das notify hat aber nicht gepackt. Der Test des regulären Ausdrucks in regex101 kommt auf einen Treffer. Bin also doch nur ein Küken und brauche Hilfe.

VG Peter

frank · 06 April 2018, 13:30:34

poste mal die zeile mit der fehlermeldung aus dem log.

elektrikpe2 · 06 April 2018, 13:51:48

s. oben

aber gerne nochmal hier:

Code Auswählen

2018.03.30 15:35:24 1: xx.xx.xx.xx:1012 disconnected, waiting to reappear (CallMonitor)
2018.03.30 15:35:25 1: xx.xx.xx.xx:1012 reappeared (CallMonitor)

frank · 06 April 2018, 14:42:34

im regex des notify darf nur text der message stehen. in der message steht ja nicht das notify-device. ausserdem ist die message länger, daher noch ".*" hinten dran. zb so:

Code Auswählen

defmod n_ReconnectCallMonitor notify 78\.94\.52\.61:1012.disconnected.* set CallMonitor reopen

die reappeared message wurde durch das at ausgelöst?

elektrikpe2 · 06 April 2018, 15:37:36

nein, die Meldungen kommen immer zusammen. Aber Auswirkungen hat die "reappeared" keine. Ich glaube es ist besser auf diesen Logeintrag zu reagieren. Ist ja jetzt einfach für mich abzuändern. Ich werde die Wirkung berichten. Danke

VG Peter

elektrikpe2 · 08 April 2018, 18:27:00

Hallo,

leider packt der notify so auch nicht, obwohl der reg.Ausdruck bei Überprüfung auf regexe101 auf einen Treffer läuft.

Code Auswählen

defmod n_reopenCallMonitor notify xx\.xx\.xx\.xx:1012.*reappeared.* set CallMonitor reopen
attr n_reopenCallMonitor group Fritzbox
attr n_reopenCallMonitor readLog 1
attr n_reopenCallMonitor room 91_Geraete

Ich habe jetzt auf den 2. Teil der Meldung den regexe abgeändert. Bitte nochmal um Hilfe.

VG Peter

elektrikpe2 · 10 April 2018, 16:16:39

Hallo,

bin nicht gewöhnt, dass man mich hier so hängen lässt

Wenn ich so lange auf eine Antwort warten muss, spornt mich das immer dazu an, eine Lösung mit Trail and Error selber zu erzielen. Die Lösung ist ganz einfach; vor dem regAusdruck steht ja noch der Timestamp. Den muss man natürlich auch auskillern also:

Code Auswählen

.*xx\.xx\.xx\.xx:1012.reappeared.* {fhem("set CallMonitor reopen"); Log3(undef,3,"notify CallMonitor reconnected");}. Ich konnte die Situationen nachvollziehen. Es handelt sich tatsächlich um den gleichen Zustand, als ob ich den Callmonitor mit #96*4* auf der FB ausschalte und mit #96*5* wieder einschalte. In dem einen Fall kommt ...disconnected und dann ....reappeared. Warum der Callmonitor nicht reagiert, wenn die Fallkonstellation eintritt wenn es von der FB "automatisiert" kommt, kann ich nicht nachvollziehen. Ich werde es weiter beobachten und dann noch berichten, ob der reopen auch wirklich den Callmonitor wieder zum Leben erweckt. Jetzt funkioniert ja erstmal der notify. Melde mich wieder.

VG Peter