Callmonitor 1.*

[Silent-Tears]

Das "meckern" ist wie von buhemann angemerkt standard, denn das PRogramm kennt den Parameter nicht. Sowas sieht immer so aus

 

[Peter931]

Ist der Callmonitor auf externe Anrufe beschränkt? (Frage von Newbie zum Callmonitor)

HAllo
Ich nutze die Version Version 1.12.3.
Ich habe DEBUG-Ausgabe angeschaltet und kann alles über Status-Syslog verfolgen.

Ich möchte ein Wake-On-Lan ansteuern.
Funktioniert sogar alles bestens, wenn ich mit dem Handy anrufe und als Source meine handy-Nummer angebe. ICH BIN BEGEISTERT !!!

Ich will aber in Zukunft mit einem INTERNEN Telefon ( z.B ISDN S0-1 ) ein internes Telefon anrufen ( z.B Analog 1 ) um Wake on lan durchzuführen.

Wenn ich nun von meinem internen Anschluss( z.B ISDN-S0-1) anrufe, finde ich aber keinerlei Einträge im LOG-File durch den Callmonitor.
Ist der Callmonitor auf externe Anrufe beschränkt?

Gruß
Peter

P.S.
Wo landet eigentlich eine solche Ausgabe genau?? In welchem Unterverzeichnis?
in:request ^ ^ echo "Neuer Anruf ! " >> log

 

[matze1985]

Da loggt wohl der Callmonitor nicht, also ist da mit dem Callmonitor wenig zu machen.

PS:
Wahrscheinlich in dem Verzeichnis, wo der Callmonitor gestartet wurde, dies passiert beim automatischen Start über dir rc.scripte, welche von rc.S ausgerufen werden.
Kann gut sein, dass es in einem nicht beschreibbaren Bereicht ist, vielleicht /. Warum gibst du nicht nen ganzen Pfad an.

in:request ^ ^ echo "Neuer Anruf ! " >> /tmp/log

 

[Peter931]

Callmonitor sieht nicht die internen Anrufe

Ja, so wie es aussieht, bearbeitet der Callmonitor NICHT die INTERNEN Anrufe.

Sieht jemand eine andere Möglichkeit, wie man gezielt durch wählen einer Telefonnummer(code) einen Befehl ( ether-wake) aufrufen könnte?
Gibt es vielleicht ein anderes Paket, dass dazu geeignet wäre?

 

[Izzy]

Hol Dir eine SIP Nummer und dann rufst Du die von intern an - kommt ja dann über SIP wieder von außen rein, sollte daher funktionieren.

 

[matze1985]

Die muss nicht mal bei dir angemeldet sein, da jeder Rausruf ja bearbeitet wird
Kann also auch eine Nummer sein, die einfach da ist und keine sie abhebt, weil sie keine benutzt.

 

[buehmann]

Hallo Peter,

um das schon gesagte noch mal zusammenzufassen:

Ja, der Callmonitor "sieht" keine Anrufe von intern nach intern; die werden von den AVM-Diensten auf der entsprechenden Schnittstelle nicht bekanntgemacht. Ein Workaround ist das Anwählen einer SIP-Adresse auf dem eigenen (Dyndns-)Host.

Wo landet eigentlich eine solche Ausgabe genau?? In welchem Unterverzeichnis?
in:request ^ ^ echo "Neuer Anruf ! " >> log

Das ist unspezifiziert: Es wird kein bestimmtes Verzeichnis garantiert. Du solltest also, wenn du Dateien ansprechen willst, immer absolute Pfade benutzen.

Gruß,
Andreas

 

[zirkon]

Hat noch jemand Probleme mit der vorherigen Suche im Telefonbuch, sowie den Standortangaben und der aktuellen 7270 Firmware 54.04.70?

[¤] Mehrmalige Neustarts haben das Problem jetzt behoben und das Fritzboxeigene Telefonbuch wird wieder verwendet.


Jetzt habe ich aber noch eine andere Frage. SOURCE_NAME und SOURCE_ADDRESS ergeben sehr häufig die gleichen Ausgaben, obwohl sie doch seit 1.12 separiert sein sollten?

 

[buehmann]

Guten Morgen,

Jetzt habe ich aber noch eine andere Frage. SOURCE_NAME und SOURCE_ADDRESS ergeben sehr häufig die gleichen Ausgaben

das interessiert mich. Kannst du Beispiele geben, bei denen das auftritt? (Am besten anhand des Werts von SOURCE_ENTRY aus der Debug-Ausgabe.)

Gruß,
Andreas

 

[zirkon]

War ein Top-Eintrag bei DasTelefonbuch. Der Log-Eintrag sieht dann so aus:

SOURCE_ENTRY='Str. 3, 12345 Musterstadt, Nachname Vorname; Str. 3, 12345 Musterstadt, Str. 5, 12345 Musterstadt'
    SOURCE_NAME='Str. 3, 12345 Musterstadt, Nachname Vorname'
    SOURCE_ADDRESS='Str. 3, 12345 Musterstadt, Str. 5, 12345 Musterstadt'

Umstellung auf DasÖrtliche hat dann geholfen ... liegt also nicht zwingend am CM. Kann man auf solch unterschiedliche Einträge überhaupt gescheit mit Parsern reagieren?

 

[buehmann]

Das sieht ja, äh ... spannend aus.

Natürlich kann man mit Parsern prinzipiell solche unterschiedlichen Einträge erkennen. Um festzustellen, wie schwierig das in diesem Fall ist, bräuchte ich erst mal eine Nummer, die zu solch einem Eintrag führt.

Andreas

 

[zirkon]

Habe dir mal eine PN mit der dementsprechenden Nummer geschickt. Liegt wohl auch daran, dass "DasTelefonbuch" bei der Rückwärtssuche in diesem Fall drei Ergebnisse ausgespuckt (2x Treffer + 1x falsche Nummer).

 

[buehmann]

Hallo zirkon,

danke für die Nummer. Ich habe meinen DasTelefonbuch-Code angepasst (und den für 11880 auch); das Format hatte sich (mal wieder) geändert. Ich teste die neue Version noch bis Sonntag und lade sie dann hoch.

Andreas

 

[zirkon]

Dann hatte sich's ja gelohnt und schnell gelöst hast du das Problem ja auch

 

[buehmann]

callmonitor-1.12.4

So ... v1.12.4 steht zum Download bereit mit folgenden Änderungen:

• callaction: Kurze Kommandozeilenhilfe
• roku.sh: sbxmessage für mehrzeilige Nachrichten an SoundBridge
• reverse: DasTelefonbuch und 11880 aktualisiert

Andreas

 

[princenewton007]

Hallo Andreas,

super, dass du dein Wort gehalten hast
Ich habe soeben die neue roku.sh (sbxmessage für mehrzeilige Nachrichten an SoundBridge) ausprobiert. Leider wird die Ausgabe von z.B.

in:request ^ ^ sbxmessage 192.168.x.y "${SOURCE_NAME} ${SOURCE_DISP}"

unvollständig in einer Zeile dargestellt. Ab welcher Zeichenanzahl greift der Zeilenumsprung? (Die SB-Home kann 16 Zeichen pro Zeile darstellen)

Gruß Kai

 

[buehmann]

Hallo Kai,

es gibt keinen automatischen Zeilenwechsel: sbxmessage funktioniert wie alle anderen Benachrichtigungsfunktionen; die Nachricht selbst muss mehrzeilig sein.

Also entweder default_sbxmessage() so definieren, dass die gewünschte Nachricht in mehreren Zeilen ausgegeben wird, oder in deiner Variante mit expliziten Zeilenwechseln arbeiten (einen Zeilenwechsel findest du in der Variablen ${LF}):

in:request ^ ^ sbxmessage 192.168.x.y "${SOURCE_NAME}${LF}${SOURCE_DISP}"

Andreas

 

[donatello]

am ende dieses thread angekommen, habe ich noch immer nicht herausgefunden, ob folgendes möglich ist:

ziel:
bei ausgehendem signal (zb "22") soll folgendes ausgelöst werden:
http://192.168.1.11/xbmcCmds/xbmcHttp?command=PlayNext()
(ein http befehl, der der xbox sagt, sie soll den nächsten track abspielen)

wenn ich es richtig verstanden habe, dann wird das nicht funktionieren.

 

[princenewton007]

JA super. Jetzt läuft die ganze Geschichte. Die nützliche Konstante $LF habe ich jetzt auch im WIKI wiedergefunden ...

Und so sieht das ganze aus. Besten Dank.

 

[buehmann]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Hallo donatello,

willkommen bei uns im Forum!

bei ausgehendem signal (zb "22") soll folgendes ausgelöst werden:
http://192.168.1.11/xbmcCmds/xbmcHttp?command=PlayNext()

Das Aufrufen der URL ist kein Problem (und kann z.B. mit wget erledigt werden). Die Frage ist, was du mit "ausgehendem Signal" meinst: Diese Aktion bei irgendeinem Anruf-Ereignis auszuführen, ist leicht. Das Problem, was du siehst, dürfte sein, dass das Abheben des Hörers und das Wählen von "22" (sozusagen als benutzerdefinierter Wählcode) für die Box zunächst keinen Anruf darstellt. Deswegen bekommt auch der Callmonitor davon nichts mit und kann keine Aktion ausführen.

Ein mehrfach zitierter Workaround ist dieser: Leg dir in der Fritzbox eine Kurzwahl auf eine SIP-Adresse auf deiner eigenen Box an (z.B. *722 -> [email protected]); diese Adresse muss nicht existieren, aber beim Wählen von *722 gibt es dann einen erfolglosen Anruf, auf den der Callmonitor reagieren kann. Frag einfach nach, wenn du Details zu dieser Lösung brauchst.

Andreas

[Beitrag 2:]
Hallo Kai,

Anhang anzeigen 34639

danke für das Foto als Rückmeldung! Freut mich, dass es jetzt funktioniert.

Andreas