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
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
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.
Hallo,
hatte leider keine Wirkung.
VG Peter
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:
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
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
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
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.
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.
define Callmonitor_Reopen at +*00:20:00 set Callmonitor reopen Vielleicht hilft dir das ja auch weiter.
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
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
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
poste mal die zeile mit der fehlermeldung aus dem log.
s. oben ;) aber gerne nochmal hier:
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)
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:
defmod n_ReconnectCallMonitor notify 78\.94\.52\.61:1012.disconnected.* set CallMonitor reopen
die reappeared message wurde durch das at ausgelöst?
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
Hallo,
leider packt der notify so auch nicht, obwohl der reg.Ausdruck bei Überprüfung auf regexe101 auf einen Treffer läuft.
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
Hallo,
bin nicht gewöhnt, dass man mich hier so hängen lässt :D 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:
.*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
Hallo,
Ergebnis meiner Recherchen: Ich kann die Beobachtung von Darrol bestätigen. Es gibt nicht nur einen Logeintrag, wenn die FB den Callmonitor schließt sondern auch ungeloggte Schließungen des Callmonitors auf der FB. Das wurde auch schon in einem anderen Thread (https://forum.fhem.de/index.php/topic,41195.msg572276.html#msg572276) beschrieben. Insofern halte ich eine Kombination aus dem beschriebenen at und dem readlog für die Lösung des Problems, wenn nicht jemand noch eine elegantere findet. Ich habe das jetzt so eingebaut und beobachte mal die Funktionsweise. Also für Faule:
define Callmonitor_Reopen at +*00:20:00 set Callmonitor reopen und
defmod n_reopenCallMonitor notify .*xx\.xx\.xx\.xx:1012.reappeared.* {fhem("set CallMonitor reopen");; Log3(undef,3,"notify CallMonitor reopen");;}
attr n_reopenCallMonitor readLog 1
Gut, den zusätzlichen Log kann man sich irgendwann sparen.
VG Peter
Hi elektrikpe2,
ich habe eben auch nochmal etwas bei avm recherchiert und bin dabei hierauf gestoßen:
https://avm.de/service/fritzbox/fritzbox-7270/wissensdatenbank/publication/show/907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/ (https://avm.de/service/fritzbox/fritzbox-7270/wissensdatenbank/publication/show/907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/)
Dort heißt es:
ZitatUm die Sicherheit der Geräte im FRITZ!Box-Heimnetz zu gewährleisten ..., löscht die FRITZ!Box automatisch alle TCP-Verbindungen nach 15 Minuten und alle UDP-Verbindungen nach 5 Minuten ohne Datenaustausch aus ihrer NAT-Tabelle ("NAT-Timeout")...
...Um zu verhindern, dass die FRITZ!Box Verbindungsinformationen aus ihrer NAT-Tabelle löscht, richten Sie die Internetanwendung so ein, dass sie regelmäßig Datenpakete ins Internet sendet.
Dieser Beitrag dort ist zwar für die FB7270 hinterlegt (ich selbst besitze das 1&1-Konstrukt FB7412) aber das klingt schon sehr verdächtig nach dem hier beschriebenen Verhalten.
Zudem schreibt Markus Bloch in dem von dir verlinkten Forenthread:
ZitatFHEM sendet aber keinerlei Daten an die FritzBox. Somit kann FHEM nicht erkennen, ob eine Verbindung "tot" ist, da keinerlei Daten ausgetauscht werden, wenn keine Anrufe stattfinden. Es gibt im TCP-Protokoll einen Keep-Alive Mechanismus den FHEM aktiviert um solche toten Verbindungen ohne regelmäßige Datenübertragungen zu erkennen und automatisch neu aufzubauen (so wie es bei dir passiert ist).
Und hier noch etwas Literatur zum TCP-KeepAlive:
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html (http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html)
Darin lese ich(man korrigiere mich falls ich irgendwo voll daneben liege), dass
- die TCP-KeepAlive- Funktion bei mir und auch anderswo nicht funktioniert wie sie soll
- das KeepAlive im Zweifelsfall genau das gleiche leistet wie das "reopen" per notify oder at
- durch die Verwendung von at/notify somit kein zusätzlicher traffic entsteht
Bleibt die Frage was mit dem KeepAlive nicht stimmt, dass es nur starkt verzögert bis gar nicht greift. ???
Hallo Darrol,
kleine Anmerkung zum Thema KeepAlive. Bei Perl ist der Standardinterval für ein TCP-KeepAlive 2 Stunden. Aus den Aussagen von AVM werden Verbindungen nach 15 Minuten Inaktivität bereits aus der NAT-Tabelle gelöscht.
Ich würde daher anbieten, einen optionalen KeepAlive-Mechanismus aller 10 Minuten direkt in FB_CALLMONITOR zu implementieren um die Verbindung offenzuhalten (Senden eines Newlines).
Viele Grüße
Markus
Hallo zusammen,
ab morgen gibt es ein neues Attribut "sendKeepAlives". Ich würde in eurem Falle empfehlen dies mal auf 5m oder 10m zu stellen. Damit sollten die Disconnects verschwinden ohne, das man mit einer at-Definition nachhelfen muss.
Viele Grüße
Markus
Sehr cool, danke. :)
och manno, war gerade so stolz, dass ich das Problem im Griff hatte :) nee Spaß. Schon eingebaut, beobachte und berichte. Krasse Arbeit. Danke.
VG Peter
Hallo,
bis zum 16.04. lief Callmonitor und Calllist wie gewünscht. Nach Update vom 16.04. bekomme ich wieder disconnect. Weiß natürlich nicht, ob das damit zusammenhängt. Hatte bis dahin auf 10m danach auf 5m gestellt. Leider immer wieder (fast schon regelmäßig 2x am Tag) disonnect. Hab den at wieder eingebaut.
VG Peter