FB_CALLMONITOR disconnected

Begonnen von elektrikpe2, 03 April 2018, 21:38:34

Vorheriges Thema - Nächstes Thema

elektrikpe2

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 ei2018.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

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.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

elektrikpe2

Hallo,

hatte leider keine Wirkung.

VG Peter

MadMax-FHEM

#3
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

elektrikpe2

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

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Darrol

#7
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. 
IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

elektrikpe2

#8
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

frank

poste mal die zeile mit der fehlermeldung aus dem log.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

elektrikpe2

#10
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)

frank

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?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

elektrikpe2

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

#13
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

elektrikpe2

#14
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

elektrikpe2

#15
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

Darrol

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/

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

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.  ???
IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

Markus Bloch

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Darrol

IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

elektrikpe2

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

elektrikpe2

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