Guten Morgen, Ulf,

Zitat von
_ub_
Allerdings gibt es auch Anzeichen eines Codepage-Problems... kannst Du bei getmsg festlegen, dass der http-request als unicode gesendet wird?
Ich habe Kontrolle darüber, was ich sende. Das Problem, das du ansprichst, dürfte daher rühren, dass "§" in Latin-1 und UTF-8 eben nicht identisch kodiert ist; in UTF-8 besteht es aus zwei Bytes \xC2\xA7.
Beide, sowohl latin1 als auch UTF-8.
Das ist überraschend; nun gut, dann nehme ich erst einmal Latin-1, und wir schauen, ob es am Ende zuverlässig funktioniert.
"hallo Schatz!

hallo Chef..."

So weiss ich bis heute auch nach längerem Rumprobieren noch immer nicht, warum zB nur das erste Wort des Anrufernamens angezeigt wird
Du benutzt getmsg nicht ganz richtig; wichtig ist die Trennung in eine URL-Vorlage und in die eigentliche Nachricht, die dann von getmsg richtig kodiert in die Vorlage eingebaut und abgeschickt wird. Dass bei einem Leerzeichen die Ausgabe aufhört, liegt dann daran, dass du auf Shell-Ebene das Quoting vergessen hast, so dass diese deinen String auseinandernimmt und getmsg mehrere Strings zu sehen bekommt.
Nehmen wir mal dein Beispiel her:
Code:
getmsg admin:admin@musicpal /admin/cgi-bin/ipc_send?show_msg_box+Anruf+an+$DEST_DISP+§+von+$SOURCE_NAME+§#10
Das müsste so aussehen (es gibt mehrere Möglichkeiten, es zu formulieren, aber diese kommt deinem Beispiel am nächsten):
Code:
getmsg admin:admin@musicpal "/admin/cgi-bin/ipc_send?show_msg_box%%20%s" "Anruf an $DEST_DISP§von $SOURCE_NAME§#10"
Hier hat getmsg drei Argumente: Zielrechner (evtl. inklusive Authentifizierung, aber die könnte man auch über Optionen wie --user/--password machen), Muster für den GET-Aufruf ("%s" markiert die Stellen, wo nachfolgende Argumente eingesetzt werden; möchte man ein literales "%" in der URL haben, muss man es verdoppeln; vgl. im Beispiel: "%20" wird zu "%%20") und die Nachricht (so, wie sie ist; um die richtige Kodierung der Leerzeichen und Sonderzeichen kümmert sich getmsg).
Wenn es möglich wäre, eingegangene AB-Nachrichten als RSS-Feed abzurufen, wäre das Problem sogar noch einfacher lösbar.
Dafür könnte man eventuell eine neue Seite im Webinterface der Fritzbox anlegen; das System von AVM ist recht mächtig, was das Generieren von dynamischen Seiten angeht.
Aber zurück zur Sache: Ich habe eine erste Version der Funktion musicpalmessage geschrieben. Es wäre toll, wenn du sie intensiv testen könntest: Speichere die angehängte Datei in /tmp/flash/callmonitor/actions.local.d/musicpal.sh (Endung .txt entfernen!) und starte den Callmonitor neu. Nun solltest du in den Listeners folgendes tun können:
Code:
musicpalmessage admin:admin@musicpal
Das gibt die Standardnachricht aus; schau mal, ob die halbwegs brauchbar ist. Eine eigene Nachricht bekommst du so:
Code:
musicpalmessage admin:admin@musicpal "Hallo, Welt! ${SOURCE}"
Den Timeout habe ich testweise eingebaut und auf 10 Sekunden gesetzt. Falls der wider Erwarten funktionieren sollte, kannst du ihn so verändern:
Code:
MUSICPAL_TIMEOUT=20 musicpalmessage admin:admin@musicpal "Hallo, Welt! ${SOURCE}"
Mehrzeilige Nachrichten gehen so (wie gewohnt im Callmonitor):
Code:
musicpalmessage admin:admin@musicpal "Zeile 1${LF}Zeile 2"
"menu_collapse" habe ich vorerst in eine eigene Funktion gepackt:
Code:
musicpalclear admin:admin@musicpal
Anstatt immer bei Ende des Gesprächs menu_collapse aufzurufen oder nach einer gewissen Zeit, wäre es denkbar, den Aufruf immer direkt vor einer neuen Nachricht abzuschicken. Die Variante "musicpalmessage2" macht das; probier es einfach mal aus.
Viele Grüße
Andreas