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

[buehmann]

Analog DECT/WLAN geht das nur, wenn es im Webinterface von AVM eine Möglichkeit gäbe, die LAN-Ports zu schalten. (Gibt es die?) In meinen Quellen wird das hier abgehandelt: http://callmonitor.svn.sourceforge....onfig.sh?revision=651&content-type=text/plain

 

[tommatt]

gibt es doch...

 

[BurningCrash]

@buehmann

kann man eigentlich dem CallMonitor sagen er soll ein anderes Telefonbuch auslesen ausser das Telefonbuch das "Telefonbuch" heißt?

Klar was ich meine?

 

[buehmann]

@tommatt: Danke, das kannte ich noch nicht. Vermutlich werde ich aber nicht für jede dieser Einstellungen ein Äquivalent im Callmonitor vorsehen.

@BurningCrash: Nein, kann man momentan nicht. Als das Auslesen des Telefonbuchs geschrieben wurde, gab es nur eines.

 

[bolle]

Geht folgendes mit einem EIntrag in den Listerner ...wenn ja wie würde der aussehen.

Anruf auf der MasterBox von Nummer x an meine Nummer. Dies soll auf der SlaveBox ein Reboot auslösen. Der Hintergund ist der, dass es manchmal vorkommt, dass sich meine HDD unmountet und nach dem Neustaret aber wieder eingebunden wird.

Die MasterBox auf der der Anrug eingeht soll sich auf der SlaveBox einloggen und ein reboot veranlassen. Auf der Slave Box bin ich freetz frei...aber das macht ja nichts....

Für Anregungen oder eine Möglichkeit der Realisierung ohne Freetz auf der SlaveBox wäre ich dankbar!!

MFG BOLLE

 

[hermann72pb]

Du versuchst damit das Problem umzugehen, anstatt es zu lösen. Die Box darf keine Festplatte "verlieren". Checke bitte deine USB-Anbindung und die Stromversorgung der Festplatte. Aktive USB-Hubs können in bestimmten Fällen Abhilfe schaffen, können aber selbst für Probleme sorgen. Darum zunächst deine Störungsprobleme beseitigen, bevor du sie durch Workarrounds versuchst zu lösen.
Zu deiner Idee mit dem Reboot. Ja, es wird grundsätzlich möglich sein, einen Reboot der zweiten Box auszulösen. Mit FREETZ, Telnet, SSH (dropbear) wäre es deutlich einfacher, als mit einer unveränderten Box. Aber auch so wird es sicherlich gehen. Ich vermute allerdings, dass callmonitor dafür zwar Bausteine anbietet, eine komplett fertige Lösung wird es aber nicht geben.
Deine Idee würde ich vielleicht noch eleganter lösen. Und zwar nicht per Anruf, sondern per crontab auf der Box1 z.B. alle 5 Minuten einen check ausführen, ob die Platte auf der Box2 noch da ist und wenn nicht, dann die Box automatisch rebooten. Man sollte allerdings da noch einen Rebootzähler einbauen, der dafür sorgt, dass ohne Festplatte die zweite Box nicht im Dauerreboot landet.

MfG

 

[buehmann]

@bolle: Ja, das geht, ein Eintrag könnte so aussehen:

in:request  ^x$  ^meineNummer$  reboot-slave

Wie das Skript "reboot-slave" aussieht, hat nichts mit dem Callmonitor zu tun. Wie schon gesagt könnte man das einfach mit SSH erledigen.

 

[4eversr]

Callmonitor und Samsung UE55ES8090

Hallo,

habe eigentlich alles nach Anleitung eingerichtet um eingehende Anrufe an meinem Samsung angezeigt zu kriegen, ich bekomme aber immer im Callmonitor Log die Fehlermeldung "connection refused".
Können die aktuellen Samsung TVs vielleicht nix mehr mit SOAP Nachrichten anfangen ?

 

[buehmann]

Hallo 4eversr,

dazu liegen mir keine Informationen vor. Du bist der erste seit langem, der sich zu der Samsung-Aktion meldet.

Ich habe mich damals an der dieser Dokumentation zu den SOAP-Nachrichten orientiert: http://wiki.samygo.tv/index.php5/MessageBoxService_request_format Vielleicht findest du im Umfeld dieses Projektes eher heraus, ob es bei aktuellen Samsung-TVs Änderungen gab.

Viele Grüße,

Andreas

 

[hermann72pb]

Ich hatte vor ein Paar Monaten auch erfolglos versucht mit einem Samsung-Fernseher zu reden. Da dieses Gerät nicht mir gehört, sondern meinen Eltern, hatte ich keine Zeit großartig zu recherchieren. Was ich auf jeden Fall damals verstanden hatte: Es ist heutzutage nicht so einfach an Linux von aktuellen Samsung-Geräten dran zu kommen. Der Hersteller hat alte Zugangsmöglichkeiten so gut, wie verbaut. Firmwaremodifikation ist kaum mehr möglich. Es gibt natürlich diverse Apps im Netz, die man angeblich an seinen Fernseher installieren kann, die bewegen sich aber eher im Bereich "online Videos", "online Browsing" etc.
So, wie ich es auch verstanden habe, ist diese SamyGo so eine Art FREETZ für Samsung-Fernseher. Und so, wie ich es wiederum verstanden habe, braucht man SamyGo, um SOAP-Nachrichten zu empfangen.
Mag sein, dass ich mich irre, mag sein, dass ich damals nicht genügend recherchiert hatte. Wenn es der Fall ist, sollte mich derjenige bitte korrigieren, der sich damit besser auskennt. Es wäre gut, wenn dieser "Kenner" uns hier mit ein Paar Links zu entsprechenden Portalen / Webquellen versorgen würde. Diskutieren und durchkauen müssen wir es hier nicht, da es definitiv OT wäre. Gute Hinweise mit entsprechenden Links schaden aber nie und ersparen einem oder anderen 3-4 Stunden der Suche im Netz.

MfG

 

[60plus]

SMS auf SamsungTV UE37D6500??

Hi,

@buehmann

mit dem unten genannten Proggy kann ich am Samsung TV UE37D6500 auch ein SMS Fenster initialisieren und nun meine Frage, wäre es möglich mit dem callmonitor selbiges auch zu initialisieren?


@4eversr,

teste bitte mit Rainer seinem Proggy ob du eine Meldung auf dem TV auslösen kannst.
http://samsung.rainerullrich.de/ruSamsungTVCommunicator_V0.0.13.0.zip

Wenn du damit kein Erfolg hast wird es von der Software Version nicht(mehr) unterstützt, downgrade würde helfen(Samygo).


@hermann72pb

Samygo Board>http://forum.samygo.tv
Samygo Wiki>http://wiki.samygo.tv/index.php5/Main_Page

mfg

60plus

 

[hermann72pb]

@60plus: Bei den WIKIs und Foren war ich schon. Meine Aussage war doch, dass du dieses Samygo heutzutage fast vergessen kannst, weil alle aktuellen Fernsehgeräte die von dir richtig verzeichnete als "nicht mehr" unterstützte Firmware haben. Bei diesen neuen Geräten kannst du aber meistens nicht mehr downgraden, weil es keine älteren Firmwares gibt. Außerdem bieten die neuen Firmwares gerade viele Features fürs Internet und für zusätzliche Apps. Auf die will auch keiner verzichten, wenn er downgradet.

Ich finde es eigentlich als Schweinerei von Samsung, den Weg zur Firmware komplett zu versperren. Schließlich haben sie sich den Namen in der Branche dank busybox und Open Source gemacht. Hoffentlich schwenkt AVM nicht in die gleiche Richtung.

MfG

 

[60plus]

Hi,
ich gebe dir Recht was Samsung angeht.

Ein downgrade ist aber möglich, trotz Samsung Philosophie und auf Apps braucht man nicht zu verzichten.

mfg

60plus

 

[buehmann]

@buehmann

mit dem unten genannten Proggy kann ich am Samsung TV UE37D6500 auch ein SMS Fenster initialisieren und nun meine Frage, wäre es möglich mit dem callmonitor selbiges auch zu initialisieren?

1. Es gibt beim Callmonitor schon die Aktion "samsung"; funktioniert die beim genannten Fernseher? 2. Das Programm liegt nur ausführbarer Form vor. Dem kann man also nichts entnehmen, wie es funktioniert. 3. Wenn du ein ähnliches Programm für Linux/die Fritzbox findest/schreibst, mit einer Kommandozeilenschnittstelle, dann kannst du es ohne Weiteres auch mit dem Callmonitor verbinden.

 

[60plus]

Hi,
buehmann,

zu 1. ja diese Ation funktioniert
zu 2. es gibt wol eine Debugg Funktion
zu 3. das wäre mir nicht möglich....leider


mfg

60plus

 

[donfaustino]

Hi,
ich habe hier ein merkwürdiges Problem. Habe ein neues Freetz für die 7270 erstellt.
Meine Regel sieht so aus:

* ^ ^ wget -O /dev/null "http://xxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_address=$SOURCE_ADDRESS&dest=$DEST&dest_disp=$DEST_DISP&dest_name=$DEST_NAME&dest_address=$DEST_ADDRESS&ext=$EXT&duration=$DURATION&provider=$PROVIDER" >/dev/null 2>&1 &

Das Callmonitor Script "loggt" die übergebenen Daten in eine Datenbank.
Wenn ich nun einen Testanruf mache, wird das wget aufgerufen und damit auch die callmonitor.php und der Anruf landet in der DB. Mache ich aber nun einen richtigen Anruf, wird dieser zwar erkannt (-> Eintrag im Syslog) und das wget aufgerufen, aber anscheinend wird das callmonitor.php script nicht aufgerufen weil der Eintrag in der Db fehlt.
Irgendjemand eine Idee warum der TEstanruf funktioniert? Leider steht im Log auch nicht der Ausgefüllte wget-Aufruf mit den ersetzten Variablen (tzb. $SOURCE etc)

Hier der Aufruf per Testanruf:

including /usr/lib/callmonitor/actions.d/config.sh
including /usr/lib/callmonitor/actions.d/dboxlcd.sh
including /usr/lib/callmonitor/actions.d/dial.sh
including /usr/lib/callmonitor/actions.d/mail.sh
including /usr/lib/callmonitor/actions.d/messages.sh
including /usr/lib/callmonitor/actions.d/musicpal.sh
including /usr/lib/callmonitor/actions.d/rc.sh
including /usr/lib/callmonitor/actions.d/roku.sh
including /usr/lib/callmonitor/actions.d/samsung.sh
>>> in:connect ID=1 TIMESTAMP=05.10.12 19:43 SOURCE=0176xxxxxxxxxx DEST=03xxxxxxxx EXT=4 DURATION=16 PROVIDER=
[0] event detected:
  EVENT=in:connect
  SOURCE='0176xxxxxxxxx'
  DEST='03xxxxxxxxx'
[0+] detailed event data:
  SOURCE_DISP='0176xxxxxxxxxx'
  SOURCE_ENTRY=''
    SOURCE_NAME=''
    SOURCE_ADDRESS=''
  DEST_DISP='xxxxxxxxxx'
  DEST_ENTRY=''
    DEST_NAME=''
    DEST_ADDRESS=''
  ID=1
  EXT=4
  DURATION=16
  TIMESTAMP='05.10.12 19:43'
  PROVIDER=
  UUID=7b85fc66-7987-4a4e-bdf7-194cd934cbd2
[0:0] processing rule '*' '^' '^' 'wget -O /dev/null "http://xxxxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_address=$SOURCE_ADDRESS&dest=$DEST&dest_disp=$DEST_DISP&dest_name=$DEST_NAME&dest_address=$DEST_ADDRESS&ext=$EXT&duration=$DURATION&provider=$PROVIDER" >/dev/null 2>&1 &'
[0:0] event 'in:connect' matches pattern '*'
[0:0] parameter SOURCE='0176xxxxxxxx' matches pattern '^'
[0:0] parameter DEST='030xxxxxxxxx' matches pattern '^'
[0:0] SUCCEEDED
[0:0] ACTION: 'wget -O /dev/null "http://xxxxxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_address=$SOURCE_ADDRESS&dest=$DEST&dest_disp=$DEST_DISP&dest_name=$DEST_NAME&dest_address=$DEST_ADDRESS&ext=$EXT&duration=$DURATION&provider=$PROVIDER" >/dev/null 2>&1 &'

Hier der richtige Anruf der im Syslog mitprotokolliert wird aber das script nicht aufgerufen wird.

Oct  5 19:41:45 fritz daemon.debug callmonitor: <<< timestamp=05.10.12 19:41:45 event=CONNECT id=0 ext=40 remote=0176xxxxxxxxxxx
Oct  5 19:41:45 fritz daemon.debug callmonitor: >>> in:connect ID=0 TIMESTAMP=05.10.12 19:41:45 SOURCE=0176xxxxxxxxxxx DEST=03xxxxxxxxxx EXT=40 DURATION= PROVIDER=POTS
Oct  5 19:41:45 fritz daemon.info callmonitor: [2] event detected:
Oct  5 19:41:45 fritz daemon.info callmonitor:   EVENT=in:connect
Oct  5 19:41:45 fritz daemon.info callmonitor:   SOURCE='0176xxxxxxxxxxxx'
Oct  5 19:41:45 fritz daemon.info callmonitor:   DEST='03xxxxxxxxxxxx'
Oct  5 19:41:45 fritz daemon.debug callmonitor: [2+] detailed event data:
Oct  5 19:41:45 fritz daemon.debug callmonitor:   SOURCE_DISP='0176xxxxxxxxxxxx'
Oct  5 19:41:45 fritz daemon.debug callmonitor:   SOURCE_ENTRY=''
Oct  5 19:41:45 fritz daemon.debug callmonitor:     SOURCE_NAME=''
Oct  5 19:41:45 fritz daemon.debug callmonitor:     SOURCE_ADDRESS=''
Oct  5 19:41:45 fritz daemon.debug callmonitor:   DEST_DISP='xxxxxxxxxxxxxxx'
Oct  5 19:41:45 fritz daemon.debug callmonitor:   DEST_ENTRY=''
Oct  5 19:41:45 fritz daemon.debug callmonitor:     DEST_ADDRESS=''
Oct  5 19:41:45 fritz daemon.debug callmonitor:   ID=0
Oct  5 19:41:46 fritz daemon.debug callmonitor: [2:0] processing rule '*' '^' '^' 'wget -O /dev/null "http://xxxxxxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_addr
Oct  5 19:41:46 fritz daemon.debug callmonitor: [2:0] event 'in:connect' matches pattern '*'
Oct  5 19:41:46 fritz daemon.debug callmonitor: [2:0] parameter SOURCE='0176xxxxxxxxxx' matches pattern '^'
Oct  5 19:41:46 fritz daemon.debug callmonitor: [2:0] parameter DEST='03xxxxxxxx' matches pattern '^'
Oct  5 19:41:46 fritz daemon.debug callmonitor: [2:0] SUCCEEDED
Oct  5 19:41:46 fritz daemon.info callmonitor: [2:0] ACTION: 'wget -O /dev/null "http://xxxxxxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_address=$SOURCE_ADDRESS&

 

[buehmann]

Hallo donfaustino,

laut dem Log ruft der Callmonitor deine Aktion auf, was auch nicht verwunderlich ist: Eine Regel mit den Bedingungen "* ^ ^" muss immer zutreffen.

Mir fallen viele Dinge an deiner Regel auf, die nicht unbedingt direkt etwas mit dem Scheitern zu tun haben müssen, es aber haben könnten und deren Behebung dir auf jeden Fall bei der Fehlersuche helfen wird:

* ^ ^ wget -O /dev/null "http://xxxxxxxxx.de/callmonitor.php?type=s&ursprung=Alex_Tobias&event=$EVENT&id=$ID&source=$SOURCE&source_disp=$SOURCE_DISP&source_name=$SOURCE_NAME&source_address=$SOURCE_ADDRESS&dest=$DEST&dest_disp=$DEST_DISP&dest_name=$DEST_NAME&dest_address=$DEST_ADDRESS&ext=$EXT&duration=$DURATION&provider=$PROVIDER" >/dev/null 2>&1 &

1. Deine Regel ist sehr lang, zu lang, um die Übersicht zu bewahren. Bitte erstelle in so einem Fall ein separates Shellskript und rufe das aus der Regel heraus auf. (Sobald du ein separates Skript benutzt, kannst du dort auch einfach ein paar Zeilen einfügen, die die tatsächlichen Aufrufe zur Fehlersuche in eine Logdatei schreiben.)

2. Du führst deine Aktion im Hintergrund aus (&). Das ist unnötig: Der Callmonitor kümmert sich selbst um die richtige Ausführung der Aktionen. Ich habe Aktionen mit "&" nie getestet und weiß aus dem Stehgreif auch nicht, welche Nebenwirkungen sie haben könnten.

3. Du unterdrückst sämtliche Fehlermeldungen von wget (2>/dev/null). Das ist bei der Fehlersuche nicht besonders hilfreich. Also (zumindest temporär) weg mit dem "2>&1"!

4. "wget -O /dev/null ... >/dev/null" ist doppelt gemoppelt, schadet aber nicht.

5. Du wirst früher oder später Probleme bekommen, wenn die eingebundenen Variablen "besondere Zeichen" enthalten, entweder auf deiner Serverseite oder schon bei wget. Denke nur mal daran, was passiert, wenn dich eine "GmbH & Co. KG" anruft (das "&"!). Um Daten für die Einbindung in eine URL zu kodieren, bietet der Callmonitor die Funktion urlencode an.

Viele Grüße und viel Erfolg,

Andreas

 

[donfaustino]

Hi,
vielen dank für die Antwort.
Fehler habe ich gefunden! Um die befüllten Variablen zu sehen habe ich das gesamte statement mal in eine txt Datei geloggt. Es lag an der ID. Im Testanruf hatte die ID eine 1, im echten Anruf eine 0 bzw war leer. Und genau auf diese ID hat das PHP-Script ausgewertet.
Für die Weiterentwicklung möchte ich empfehlen das Statement mit den ausgefüllten Variablen auch im Log auszugeben auch im Syslog wenn ausgewählt

5. Du wirst früher oder später Probleme bekommen, wenn die eingebundenen Variablen "besondere Zeichen" enthalten, entweder auf deiner Serverseite oder schon bei wget. Denke nur mal daran, was passiert, wenn dich eine "GmbH & Co. KG" anruft (das "&"!). Um Daten für die Einbindung in eine URL zu kodieren, bietet der Callmonitor die Funktion urlencode an.

Dieses Problem hatte ich schon tatsächlich. Danke für den Hinweis, das wusste ich noch nicht. Auf der Wiki-Seite bin ich darüber auch noch nicht gestolpert. Gibts es noch weiterer "versteckte" Funktionen?

 

[buehmann]

"Versteckte" Funktionen gibt es sicher, aber die sind aus gutem Grund versteckt. ;-) Hilfreich für dich (als Alternative zu deinem eigenen wget mit vielen urlencodes) könnte http://freetz.org/wiki/packages/callmonitor/actions/getmsg sein, das für viele der Callmonitor-Benachrichtungsaktionen verwendet wird.

PS: Das Statement mit den ausgefüllten Variablen im Log auszugeben, ist im gegebenen Umfeld nicht-trivial: Die Aktionen werden einfach per "eval" von der Shell interpretiert.

 

[60plus]

Hi,

der callmonitor kann ja schon "SMS" auf dem Samsung TV darstellen, zumindest von der Fritzbox über telnet.
Nun meine Frage, wie muss der Eintrag in der Regel des callmonitor aussehen um eine "SMS" die vom Dienst 01930100 an den TV zu schicken.

Ich habe jetzt diese "in:request callaction samsung_text 192.168.178.25" es geht aber nicht.


mfg
60plus