FB_CALLMONITOR: seit ein paar Tagen werden keine angehende Anrufe mehr erkannt

CQuadrat · 14 März 2014, 16:27:16

Hallo Zusammen,

wurde in FB_CALLMONITOR etwas geändert?
Seit ein paar Tagen werden bei mir keine ankommenden Anrufe mehr erkannt: z.B. Reading external_number. Ich habe (zumindest nicht bewusst) nichts an der Konfiguration geändert.

Kann ich ggf. mit Logs weiterhelfen?

Danke und Gruß

Christoph

Markus Bloch · 14 März 2014, 18:37:55

Gerade ausprobiert, bei mir funktioniert es perfekt. Es gab keinerlei Änderungen am Callmonitor.

Hilfreich währen hier detaillierte Beschreibungen was genau du machst, was dabei für Events in FHEM auftauchen, wie du den Callmonitor in FHEM definiert hast, Logauszüge, etc.

Gruß
Markus

CQuadrat · 15 März 2014, 14:49:53

Ich habe gerade ein Update gemacht und den RasPi neu gestartet. Jetzt funzt es wieder.

Rince · 15 März 2014, 17:53:22

Freu dich nicht zu früh.
Das Update dürfte nicht geholfen haben, sondern das Neustarten vom RasPi.

Ich hab das gleiche Problem nämlich auch seit etwa 1/2 Jahr (also seit ich den Callmonitor nutze).

Hin und wieder verabschiedet er sich, und ein Neustart vom RasPi löst das Problem.

Allerdings war ich immer viel zu faul um Ursachenforschung zu betreiben. Meines Erachtens nach gibt es auch keine Meldungen diesbezüglich im Logfile.

Demnach haben wir jetzt mehrere Möglichkeiten:
1. Ignorieren, und hin und wieder RasPi neu starten
2. Wir tun uns zusammen, suchen vielleicht noch mehr Leute mit dem Problem, vielleicht finden wir den Fehler
3. Wir basteln uns einen Watchdog für den Callmonitor, der den RasPi neu startet, wenn der Callmonitor sich verabschiedet hat

zu 3. hätte ich eine Idee mit sipcmd. Wir könnten uns damit selber anrufen, demnach müsste anschließend unser Anruf im Callmonitor gemeldet werden. Wenn das nicht passiert ist, geht er wohl nimmer. Dann wäre es Zeit für einen Neustart.
Ist aber halt nur eine Bastelei an den Symptomen, Ursachenforschung wäre zweifellos schlauer.

CQuadrat · 15 März 2014, 18:43:22

Zitat von: Rince am 15 März 2014, 17:53:22
(...)
Das Update dürfte nicht geholfen haben, sondern das Neustarten vom RasPi.
(...)
1. Ignorieren, und hin und wieder RasPi neu starten
2. Wir tun uns zusammen, suchen vielleicht noch mehr Leute mit dem Problem, vielleicht finden wir den Fehler
3. Wir basteln uns einen Watchdog für den Callmonitor, der den RasPi neu startet, wenn der Callmonitor sich verabschiedet hat
(...)

Meine Vermutung war auch, dass das Problem nur durch den Neustart des RasPi behoben wurde. Da ich gerade wegen des Updates, FHEM sowieso hätte neustarten müssen, hatte ich daher dann gleich den ganzen RasPi neugestartet.

Ich wäre eindeutig für Variante 2. Ich sehe, dass Du auch einen HMLAN benutzt. Hast Du da gelegentlich auch Disconnects? Ich habe so "das Gefühl" dass der RasPi da Probleme macht. Gelegentlich liest man hier im Forum auch Ähnliches mit dem MAXLAN.

Viele Grüße

Christoph

Rince · 15 März 2014, 21:28:40

Ja, habe ich.
Disconnects. Ein Grund dafür ist relativ zweifellos meine Fritzbox-TV-Pause Bastelei.
Sobald der Callmonitor sich meldet, schickt sie einen Pause Befehl an den Fernseher. Das führt, wenn der Fernseher aus ist, zu einem Disconnect vom HM LAN. Ich müsste, denke ich, noch eine Presence Abfrage einbauen, war dazu nur bisher zu faul.

Obgleich sich mir der Zusammenhang mit HM LAN Disconnects und dem Callmonitor nicht erschließt. Außer, ja außer es wäre so, dass das, was bei einem HM LAN einen Disconnect verursacht, im Falle des Callmonitors einen Ausfall nach sich zieht.
Das also quasi auch der Callmonitor einen Disconnect haben kann, der aber anschließend keinen neuen Connect mehr aufbaut.

Rince · 15 März 2014, 21:43:32

Markus, hast du diesbezüglich eine Idee?
Wenn der Callmonitor auf der Fritte Daten an fhem sendet, und diese nicht alle bei fhem ankommen, weil etwas anderes fhem gerade zum Stillstand gebracht hat, kann es dann passieren, dass das Modul ewig auf die restlichen Daten wartet, die aber nicht mehr kommen, weil fhem sie quasi verpasst hat?
Vielleicht könnte man einen Timeout implementieren im Modul, nach dessen Ablauf der Callmonitor abbricht mit dem warten und wieder neu anfängt?

Auffällig ist auf jeden Fall, dass ein Neustart vom RasPi das Problem löst, und nicht ein Neustart der Fritte.deshalb denke ich, dass hier etwas unglückliches im FB Modul passiert, nicht auf der Fritte.

Markus Bloch · 16 März 2014, 14:02:17

Hallo zusammen,

ich habe bei mir den Callmonitor direkt auf der Fritzbox laufen und das schon eine ganze weile ohne FHEM oder die FritzBox neustarten zu müssen.

Zu deiner Vermutung, Rince: Wenn FHEM gerade stillsteht (aufgrund von sleeps oder anderen langwierigen sachen), dann werden die Daten via TCP nachwievor empfangen und durch den TCP-Stack angenommen. Sie landen dann im Socket, wo sie bereitstehen durch FHEM abgefragt zu werden. FHEM ist ja aber gerade anderweitig beschäftigt, so dass es erst nach mehreren Sekunden dazu kommt, den Socket auf Daten zu prüfen und sie dann einzulesen.

Es gehen also keine Daten im Falle eines Stillstands von FHEM verloren, sondern werden nur zeitversetzt verarbeitet. Bei HMLAN führt das allerdings zum Disconnect, weil FHEM sich aller 30 Sekunden beim HMLAN melden muss, dass es noch da ist. Dazu gibt es einen Timer, der alle 25 Sekunden ein keepalive schickt. Nun wird aber FHEM durch eine Funktion für mehr als 5 Sekunden zum Stillstand gebracht. Da ein keepalive nicht innerhalb von 30 Sekunden eintraf, schließt der HMLAN die Verbindung. FHEM bekommt das später über den Socket wieder mit und baut neu auf. Deswegen sieht man immer HMLAN Disconnects, wenn eine Funktion länger als 5 Sekunden läuft.

Der Callmonitor der Fritzbox ist, was das angeht, nicht so pingelig. Dort sind keine keepalive durch FHEM notwendig. Desweiteren kann man auch keine Befehle an den Callmonitor auf der FritzBox senden. Dieser gibt nur stuhr die Events heraus. Eingehende Kommandos oder Daten werden dabei ignoriert.

Der FB_CALLMONITOR hat einen Reconnect Mechanismus. Dieser greift, sobald die Verbindung geschlossen wird (TCP Reset, Neustart der FritzBox). Wo er allerdings nicht greift, ist, wenn die Verbindung offen in der Luft hängen bleibt (bsp. Stromziehen der FritzBox), weil es dort keine Indikation für ein Beenden der Verbindung gibt. Womit man sich hier behelfen kann, ist dass man zyklisch Daten an den Callmonitor durch FB_CALLMONITOR senden lässt, dann liesen sich solche hängenden Verbindungen als "geschlossen" erkennen, da ja kein Bestätigung durch die FritzBox mehr kommt usw.

Diese Änderung würde ich allerdings erst einmal testen wollen, da ich nicht weis, wie die FritzBox langfristig damit klar kommt (Speicheranstieg, Stabilität, usw.)

Viele Grüße

Markus

Markus Bloch · 16 März 2014, 15:04:01

Vielleicht sollten wir erst einmal warten was hier rauskommt: http://forum.fhem.de/index.php/topic,21022.msg149788.html#new

Da es sich hier genau um das von mir genannte Problem handelt.

Rince · 16 März 2014, 16:45:15

Hm,
das macht Sinn. Ich kann nicht ausschließen, dass meine Fritte manchmal hard resettet wird. Hat was mit Schaltern an Mehrfachsteckdosen und Kindern zu tun

CQadrat,
wie sieht das denn bei dir aus?

Kannst du mal bei dir prüfen, ob da ein Zusammenhang besteht?

Für meinen Teil würde ich mich damit soweit abfinden. Was Markus schreibt, macht Sinn. Wenn der Mechanismus um offene TCP/IP Verbindungen zu erkennen mal funktioniert, könnten wir uns ja wieder hier treffen.
Ich denke, das könnte auf jeden Fall eine Lösung sein.

CQuadrat · 16 März 2014, 19:31:21

Zitat von: Rince am 16 März 2014, 16:45:15
Hm,
das macht Sinn. Ich kann nicht ausschließen, dass meine Fritte manchmal hard resettet wird. Hat was mit Schaltern an Mehrfachsteckdosen und Kindern zu tun

CQadrat,
wie sieht das denn bei dir aus?

Kannst du mal bei dir prüfen, ob da ein Zusammenhang besteht?

Bingo! Ich schalte meine FritzBox durchaus gelegentlich mal aus. Verbraucher die nicht benötigt werden, müssen auch nicht an sein. Mein Heimnetz ist autark von der FritzBox

Gut, dann geht in der Zeit auch kein Callmonitor, aber damit kann ich dann leben.