Callmonitor 1.13 und höher: Ankündigungen und Bedienung

[KBeng]

Funktioniert perfekt. Vielen Dank für die superschnelle Antwort. Und wie der Zufall es will, brauche ich jetzt auch genau die UUID, die Du vor kurzem eingebaut hast.

[Fred Edison]

Moin moin.

Ich habe ein Skript für Deinen Callmonitor erstellt und ich denke, Besitzer einer Squeezebox könnten ein Interesse daran habe.
Diese Skript kann eingesetzt werden, wenn man eine Squeezebox Touch mit eingeschalteten Squeezebox Server besitzt, an dem weitere Squeezebox Player wie Touch, Boom, Radio ... angemeldet sind. Ob es auch in anderen Konstellationen funktioniert, wie zum Beispiel SB Player sind an dem SB Server von Logitech oder an einem SB Server aufm PC angemeldet, kann ich nicht sagen, dass muss jemand anderes testen.

Das Skript verbindet sich mit dem Squeezebox Server (in meinem Fall die Touch) und sendet an alle angeschlossenen Squeezebox Player (in meinem Fall Touch, Radio und Boom) zwei Zeilen, die dann blinkend auf allen Squeezeboxen angezeigt werden.

Wenn Du magst, kannst Du gerne das Skript in das Callmonitor Paket aufnehmen, dann muss ich das nicht immer händisch patchen und andere haben auch etwas davon. Ich werde es sicherlich später auch noch warten.

Aufruf:
squeezebox.sh SB_SERVER SB_PLAYER_IDS LINE1 LINE2

Beispielregel:

in:request  ^       ^      /var/media/ftp/uStor12/squeezebox.sh "sb-wohn" "sb-wohn sb-bad sb-kueche sb-schlaf" "${SOURCE_NAME}" "${SOURCE}-->${DEST}"

Ach so, ich hätte da noch drei Fragen:
1. Ist es eigentlich irgendwie möglich, dass der Callmonitor default Werte wie z.B. Unbekannt/Unknown verwendet, wenn z.B. die Variablen ${SOURCE_NAME}, ${SOURCE} nicht gefüllt sind?
2. Irgendwie habe ich das Gefühl, dass die Variable ${ID} immer denselben Wert enthält. Im Moment benötige ich die Variable nicht, aber ich habe da die eine oder andere Idee, wo ich eine einzigartige id pro Anruf benötige. Oder ist die Variable ${ID} dafür nicht gedacht und es gibt eine andere Möglichkeit?
3. Ich brauche für mein kleines Paket ein paar Ideen und muss das Freetz cgi Framework etwas verstehen. An welcher Stelle im Callmonitor Paket generierst Du die Seiten der Freetz GUI "Rückwärtssuche" und "Wartung" ?


Vielen Dank und viele Grüsse
Fred

[buehmann]

Moin, Fred,

herzlichen Dank für die Ansteuerung der Squeezebox. Ich schaue gerne, ob sich das Skript für eine Aufnahme in das Callmonitor-Paket eignet. Wegen dem Thema Wartung, das du selbst schon ansprichst, dürfte es wahrscheinlich besser sein, wenn du es separat verteilst.

Zu deinen anderen Fragen:

1. Nein, der Callmonitor nutzt immer Leerstrings für unbekannte Werte. Du kannst aber bei der Verwendung der Variablen selbst für Default-Werte sorgen: z.B. ${SOURCE_NAME:-Unbekannt}
2. ID stammt direkt von der AVM-Schnittstelle und hilft lediglich, mehrere parallel ablaufende Anrufe auseinanderzuhalten. Für dich dürfte wahrscheinlich das kürzlich eingeführte UUID nützlich sein.
3. In /usr/lib/callmonitor/modules/modreg.sh werden die beiden Seiten via "modreg extra" unter den Namen "reverse" und "maint" bei Freetz registriert. Freetz ruft dann bei einem Seitenzugriff /usr/lib/cgi-bin/callmonitor/{reverse,maint}.cgi auf. (Diese Aufrufe landen nach einem Stückchen Callmonitor-eigenen Frameworks in /usr/lib/callmonitor/applets/{reverse,maint}.cgi.sh.)

Viele Grüße,

Andreas

[bolle]

Hi ich habe einen Crontab eingerichtet, welches Callminitor nach einer gewissen Zeit neu starten lässt.

* * * * * /var/tmp/infoframe/refresh.sh
00 02 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 04 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 06 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 08 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 10 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 12 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 14 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 16 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 18 * * * /var/mod/etc/init.d/rc.callmonitor restart
00  20 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 22 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 24 * * * /var/mod/etc/init.d/rc.callmonitor restart

Das Probelm ist, dass wenn jemand anruft das ganze dreimal signalisiert wird, d.h. dass ich bei einem verpassten Anruf drei Mails bekomme.
Kann das daran liegen, dass der Callmonitor mehrfach gestarte ist?

Vielleichht kann mir jemand sagen, wie ich den Crontab umschreiben muss.
Im Voraus schonmal ein herzliches DANKE!

[stan23]

Dein crontab lässt sich noch folgendermaßen vereinfachen:

0 */2 * * * /var/mod/etc/init.d/rc.callmonitor restart   # Befehl wird alle 2 Stunden aufgerufen (die Schrittweite wird durch */Schrittweite angegeben)

[olistudent]

Magst du uns vielleicht noch sagen warum du den Callmonitor alle 2h neu startest?

[bolle]

Klar,weil nach einer gewissen Zeit keine Anrufe etc. mehr signalisiert werden. Dr callmonitor läuft nicht auf der Master Bix sondern auf der SlaveBox. Wenn Callmonitor wieder gestartet wird geht es wieder.

[buehmann]

Guten Morgen,

eine deiner Strategie angepasste Lösung wäre wohl:

*/30 * * * * reboot

Kleiner Scherz. Im Ernst: Wir sollten doch eher die Ursachen suchen, als an den Symptomen herumzudoktorn.

Vorweg: Die Möglichkeit der Überwachung einer entfernten Box ist nicht ohne Grund in der Experten-Ansicht untergebracht.

Lässt sich dein Problem (also das Ursprüngliche: Anrufe werden nicht mehr signalisiert) irgendwie eingrenzen? Wie häufig/wann tritt es auf? Lässt es sich reproduzieren? Hilft im Problemfall das Töten des nc-Prozesses des Callmonitors, anstatt den ganzen Callmonitor neuzustarten?

Viele Grüße,

Andreas

[bolle]

Hi nein reproduzieren lässt sich das ganze leider nicht. Tritt eigentlich täglich auf. Wenn du mir sagt's wie ich den nc prozess kille , kann ich das gerne mal testen. meinst du dass die mehrfachanzeige evtl. Auch damitzusammenhängt ? Weil nach einem Reboot geht das Gaze für eine unbestimmte Zeit.

[buehmann]

Nein, die Mehrfachanzeige dürfte damit zusammenhängen, dass der Callmonitor tatsächlich mehrfach läuft, es also beim Restart Probleme gab.

Es gibt einen Prozess "busybox nc <IP> 1012", wenn der Callmonitor läuft, der die Verbindung zur überwachten Box darstellt. Wenn man diesen Prozess tötet (mit "kill" oder im Extremfall "kill -9"), dann sollte die Verbindung neu aufgebaut werden.

[bolle]

Ok, danke. Und wie genau soll ich das dann in crontab eintragen?

[olistudent]

Du sollst erstmal ausprobieren, ob es dann wieder geht. Wenn du das gemacht hast wird weiter geforscht.

[bolle]

Um weiter zu forschen sollte ich wissen was ich in der Konsole eingeben soll....

EDIT: habe nun kill und dann die PID Nummer des Porzesses eingeben. Die PID Nummer ändert sich dann wieder, richtig.

OK, werde nun mal schauen, was passiert. Crontab habe ich mal ausgemacht. Trotzdem würde mich interessieren wie ich das Kill in den Crontab einbauen kann. Sollte die Anrufsignalisierung morgen auch noch gehen, wissen wir, dass ein Kill reicht um die Verbindung neu aufzubauen, oder?

Achso der Callmonitor lief tatsächlich dreimal....also killt ein Restart wohl nicht korrekt.

[buehmann]

Das kill soll nicht in die Crontab. Das dient nur der Diagnose.

[bolle]

Und jetzt..... Was soll ich machen?

Einfach nur schauen ob mit dem kill die Verbindung wieder aufgebaut wird? Bitte nicht so spärlich mit Infos umgehen

[buehmann]

Bitte etwas mehr Eigeninitiative.

Das Ziel war, festzustellen, ob allein das Neustarten von nc reicht, damit Anrufe wieder signalisiert werden.

Wenn du also merkst, dass Anrufe nicht mehr signalisiert werden (ruf dich am besten zur Kontrolle dann noch mal selbst an), starte nc neu (indem du nc killst) und schau dann (durch einen neuen Anruf an dich selbst), ob der Callmonitor wieder arbeitet (indem er eine deiner Aktionen auslöst oder indem du ins Log schaust). Infos genug?

[bolle]

Jepp....Infos genug! Ich werde das dann mal überprüfen....seit gestern läuft es irgendwie....Aber ich bin mir sicher das der Fehler in der nächsten Zeit wieder auftritt....Dann werde ich nc mal killen und schauen obs dannn wieder funzt!

[bolle]

also nach dem kill geht es wieder!

[buehmann]

Danke, bolle! Das ist sowohl eine gute, als auch eine schlechte Nachricht. Gut, weil wir damit das Problem weit eingegrenzt haben. Schlecht, weil es kaum nachzuvollziehen ist, warum in dieser speziellen Situation sich die Verbindung zwischen den beiden Boxen "aufhängt".

Da die Überwachung einer entfernten Box immer noch ein von mir wenig unterstützer Spezialfall ist, wäre es für den Moment das beste, du wendest deine Cron-Lösung an, aber beschränkt auf das Töten des nc-Prozesses. Der Nachteil ist natürlich, dass dir bei schlechtem Timing ein Anruf in den Sekundenbruchteilen des nc-Neustarts entgehen könnte.

[bolle]

Ok, vielleicht kannst du mir noch sagen wie ich nur das eintrage, dass nur der nc prozess gekillt wird?!

* * * * * /var/tmp/infoframe/refresh.sh
00 02 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 04 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 06 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 08 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 10 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 12 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 14 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 16 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 18 * * * /var/mod/etc/init.d/rc.callmonitor restart
00  20 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 22 * * * /var/mod/etc/init.d/rc.callmonitor restart
00 24 * * * /var/mod/etc/init.d/rc.callmonitor restart

so ist es momentan eingetragen.