- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,707
- Punkte
- 113
Falls irgendjemand noch auf der Suche nach einem Weihnachtsgeschenk ist und schon eine DECT-fähige FRITZ!Box (am besten natürlich eines der Modelle mit dem System im NAND-Flash) vorhanden ist, wie wäre es denn dann mit einem FRITZ!Fon?
Und damit jetzt niemand denkt, ich würde hier Werbung für AVM-Produkte machen ... ich weiß auch, daß es wertigere DECT-Mobilteile in dieser Preisklasse gibt, die obendrein noch besser klingen, auch wenn man den eingebauten Lautsprecher und "Freisprechen" benutzen will. Aber ganz so schlecht wie ihr Ruf sind diese Telefone auch nicht und wer sie z.B. als OEM-Modell bei 1&1 geordert hat, der ist ja vielleicht auch noch auf der Suche nach weiteren Anwendungsmöglichkeiten.
Das ist dann auch schon der - in diesem Beitrag - entscheidende Vorteil so eines FRITZ!Fons ... es arbeitet recht gut mit der Firmware einer FRITZ!Box zusammen. Dazu gehört u.a. auch der integrierte Media-Player, wobei dessen musikalische Qualitäten selbst mit Kopf- oder Ohrhörern wohl kaum über das "Küchenradio"-Niveau hinausgehen, aber die hier zu betrachtende Fähigkeit als "Wiedergabegerät" hat auch glücklicherweise nichts mit den "musikalischen Fähigkeiten" eines FRITZ!Fons zu tun.
Hier geht es darum, daß ein FRITZ!Fon in Kombination mit einer passenden FRITZ!Box auch benutzt werden kann, um sich eine Vorschau von Bildern anzeigen zu lassen, die irgendwo auf der FRITZ!Box gespeichert sind. Mir war der Sinn dieser briefmarkengroßen Vorschaubildchen bisher immer etwas unklar (außer man hat gerade nichts anderes bei der Hand, um den Inhalt einer bestimmten Datei zu überprüfen, aber wer würde dafür schon ein DECT-MT verwenden?), aber unabhängig von diesem Aspekt stellt sich ja auch noch die Frage, wie diese Vorschaubilder eigentlich auf das Mobilteil gelangen. Die Möglichkeit, daß diese Bilder direkt von der Quelle geladen werden und dann das Telefon selbst sie entsprechend skaliert, damit sie auf dem kleinen Display den korrekten Bildinhalt wiedergeben, kann man wohl getrost vergessen. Nicht nur, daß dazu eben z.B. ein 8 MB-JPEG-File erst einmal "over the air" zum Mobilteil gelangen müßte, so ein Telefon hat wohl kaum die notwendige Rechenpower für solche Skalierungen. Also wird wohl das Bild irgendwo anders aufbereitet werden und da bleibt ja eigentlich nur noch die FRITZ!Box.
Nach kurzer Suche in der Firmware findet sich dann früher oder später auch die Datei /bin/picconv.sh, wo offenbar solche Aktionen stattfinden ... schaut man sich dann dieses Skript etwas genauer an, stellt sich heraus, daß es vorwiegend vom pictured (und bei der Verarbeitung eines Fotos für einen Telefonbucheintrag) in der Firmware folgendermaßen aufgerufen wird:
Für den Verwendungszweck gibt es eine feste Liste von Vorgaben je nach "Thema" im Skript ("feed" ist das, was wir hier benötigen), der Ausgabedateiname zeigt in aller Regel irgendwo nach /var/tmp/irgendwas (mit irgendwas == pictured_convtemppic.jpeg). Als Eingabedateiname kriegt das Skript eine URI, dabei werden die Fälle "file://" (lokale Datei, die direkt von ihrem Ursprungsort verwendet wird) und "https://" (Download der entsprechenden Datei über den ctlmgr bzw. wohl eine Funktion des Google-Clients) vom Rest unterschieden, wo dann mit dem "wget" der Busybox ein Download erfolgt (was dann natürlich nur http- und ftp-URLs verkraftet). Diese Dateien werden dann einer Konvertierung unterzogen und das Ergebnis in unserem Falle anschließend an das DECT-MT übermittelt.
Bis hier ist das ja alles schön und gut zu wissen ... aber was kann man denn nun mit diesen ganzen Informationen anfangen?
Wenn wir wissen, daß bei jeder Anzeige einer Bilddatei auf dem Display des Mobilteils erst einmal dieses Skript ausgeführt wird, dann bietet es sich ja förmlich an, die Firmware auch an dieser Stelle zu modifizieren (ich unterstelle mal, das man das als Leser im "Modifikationen"-Unterforum ohnehin macht), um bei der Anzeige einer solchen Bilddatei eigenen Code ausführen zu lassen. Den Umstand, daß der Bildbetrachter des Media-Players nur über mehrere Tastenbetätigungen zu erreichen ist (selbst wenn man ihn als Favoriten ablegt), kann man zwar bedauern, aber leider nicht ändern (ohne Modifikationen an Stellen, von denen man lieber die Finger läßt) - wie praktikabel der im folgenden aufgezeigte Weg im eigenen Haushalt zu verwenden ist, muß also jeder selbst einschätzen.
So eine Möglichkeit zur Ausführung eigener Kommandos macht natürlich am meisten Sinn, wenn es nicht immer derselbe Code ist und wie können wir das am ehesten flexibel gestalten? Sicherlich über die Verwendung unterschiedlicher Bild-Dateien. Bei dieser Vorgehensweise könnte man die Dateien, die man als "Kommando" verwenden will, auf mehreren Wegen von "normalen Bilddateien" unterscheiden.
Ein mögliches Merkmal wäre z.B. ein passender Pfad für den Dateinamen der Quelle, indem man ein Skript mit demselben Namen unter einem festen Pfad (z.B. eben /var/media/ftp/dectcmds/scripts) ablegt und die Anzeige einer Bild-Datei als Aufforderung zur Ausführung des gleichnamigen Skriptes mit dem eigenen Code interpretiert.
Leider macht uns hier die AVM-Firmware einen Strich durch die Rechnung, denn auch wenn man dem Mediaplayer (für DECT-MTs) eine Datei von einer externen Quelle vorsetzt (z.B. dem 1&1-Onlinespeicher), wird diese Datei erst einmal auf die Box übertragen und die Konvertierung erfolgt auch in diesem Falle immer aus einem festen lokalen Verzeichnis mit einem Namen mit aufsteigender Nummerierung. Damit fällt also die Verwendung des Dateinamens als Selektor für ein auszuführendes Kommando schon mal flach.
Alternative ist die Verwendung eines Formats einer Bilddatei, das sowohl von der FRITZ!Box unterstützt wird (bei 06.36 kommen dann PNG- und GIF-Files dazu) als auch die Angabe eines "Kommentars" in den Metadaten der Bilddatei erlaubt und dann wertet man eben diesen Kommentar aus ... dort könnte dann neben einer passenden "Signatur" für ein Kommando-Bild auch der Name des aufzurufenden Skripts und bei Bedarf weitere Parameter hinterlegt werden (z.B. bei der Verwendung zweier Bilder für ein einzelnes Skript, das über einen "on"- oder "off"-Parameter gesteuert wird).
Ich habe mich zwangsläufig für die Variante mit dem Bildkommentar entschieden (es gibt sicherlich noch andere Möglichkeiten, aber es muß sich eben auch um eine Bilddatei in einem unterstützten Format handeln, damit der Mediaplayer diese Datei überhaupt konvertieren will) und für die Verwendung von JPEG-Dateien, da die AVM-Firmware bereits alle Zutaten enthält, um den Kommentar einer JPEG-Datei auszulesen. Um die (externe) Angriffsfläche gar nicht erst übermäßig anzubieten (wir erinnern uns, daß das Skript durchaus auch mit einer URI zu einer externen Ressource aufgerufen werden könnte, wenn auch nicht für die Anzeige auf einem DECT-Handset), werden nur Dateien überhaupt einer näheren Untersuchung unterzogen, die sich bereits lokal auf der FRITZ!Box befinden, wo also der Dateiname mit "file://" beginnt.
Die spannende Stelle in der "picconv.sh" sieht jetzt so aus:
Wird also eine Datei mit "file://" angegeben, wird nur vom AVM-Code getestet, ob diese Datei lesbar ist und damit sind die Vorbereitungshandlungen dann auch schon abgeschlossen. An dieser Stelle kann man sich jetzt mit einem eigenen Kommando einklinken, das könnte dann in etwa so aussehen:
Um also die Änderungen an der Datei picconv.sh so gering wie möglich zu halten, wird lediglich eine zusätzliche Skript-Datei quasi als Bibliothek eingebunden (das ist auch die einzige absolute Pfadreferenz in geändertem AVM-Code für diese Anwendung) und anschließend eine Funktion aus dieser "Library" aufgerufen. Dabei wird der Eingabedateiname durch die stdout-Ausgabe dieser Funktion ersetzt, im Ergebnis zeigt das Telefon am Ende den Inhalt der dort angegebenen Datei an. Dieser Inhalt kann sowohl ein statisches Bild sein (ein Beispiel für "ok" (success.jpg) und "gescheitert" (failure.jpg) ist enthalten im Paket auf dem Server) als natürlich auch ein vom Kommando dynamisch generiertes Bild. (Irgendwo hier habe ich auch mal etwas von einem Projekt gelesen, das regelmäßig das Hintergrundbild eines solchen Telefons aktualisiert und mit aktuellen Werten versieht für irgendwelche "Meßwerte".) Anstatt nur die Verarbeitung des "picconv.sh"-Skripts an dieser Stelle zu beenden, kann man gleich noch eine passende Datei im Anschluß konvertieren lassen (die muß natürlich lokal vorliegen, das "case"-Statement ist ja schon "in Arbeit") und zur Anzeige bringen, um den Erfolg oder Mißerfolg zu signalisieren.
Die eigentliche Arbeit bleibt damit dem Skript "dectcmds_lib.sh" vorbehalten, das kann natürlich jeder nach Belieben gestalten. Dabei darf man nicht aus den Augen verlieren, daß Textausgaben nach stdout/stderr als Dateinamen interpretiert würden; neben einer peniblen Prüfung auf mögliche Shell-Probleme wie fehlende Dateien o.ä., sollte man auch die Umlenkung der Ausgaben von aufgerufenen Kommandos nicht vergessen.
Einen Vorschlag für eine solche denkbare Implementierung kann man sich als Paket unter der URL http://yourfritz.de/dectcmds.tgz ansehen. Das "draft horse" setzt dabei auf JPEG-Bilddateien, die in ihren Kommentaren folgende Angaben enthalten:
Eigene Bilddateien mit passendem Kommentar kann man z.B. mit dem OpenSource-Programm GIMP2 durch Export als JPEG-Datei erzeugen. Das Paket auf meinem Server enthält ein Foto eines FRITZ!Fon MT-F als Vorlage für eine eigene Bilddatei (cmdtemplate.jpg) und drei weitere für den Aufruf des Beispiel-Skripts "samplescript.sh". Allerdings macht es nur bedingt Sinn, für dieses "Kommando-Bild" schon irgendwelche "Vorschaubilder" zu verwenden, da eben bei der Auswahl einer solchen Bilddatei im Media-Player zwar der Name der Datei, nicht jedoch deren Inhalt eine Rolle spielt (das Vorschaubild wird ja erst von picconv.sh erzeugt).
Die Sicherheit der FRITZ!Box steht und fällt natürlich bei diesem Skript mit der Sicherung der verwendeten Verzeichnisse gegen unberechtigte Schreibzugriffe, damit nicht z.B. der von der KiSi vom Internet abgeschnittene Nachwuchs mit einer eigenen Bilddatei irgendwo auf der FRITZ!Box (der Media-Server macht da wenige Unterschiede bei den Zugriffsrechten und kopiert die Dateien zur Konvertierung von jeder beliebigen Quelle erst einmal in ein "Zwischenlager" unter /var/tmp/dmgr_images) ein irgendwo anders auf der Box abgelegtes Skript aufrufen läßt, was ihm administrativen Zugriff auf die Box verschafft. Solchen Problemen kann man natürlich dadurch begegnen, daß man - nachdem man die eigenen Skripte entwickelt und getestet hat - nur noch bestimmte Verzeichnisse als Ablageort für die auszuführenden Kommandos akzeptiert und diese dann ggf. sogar noch ins SquashFS verlagert, so daß eine dynamische Modifikation ohnehin schon einen Zugriff auf die Box erfordern würde.
Entsprechende Einschränkungen sind schon im Skript enthalten, so akzeptiert das Skript eine Bilddatei nur dann als mögliche "Kommandoquelle", wenn sie unterhalb des Dateipfades liegt, der in der Variablen "dectcmds_picturesdir" angegeben ist. Dasselbe gilt für aufzurufende Kommandos (das können ja auch wieder selbst Shell-Skripte sein) und die Variable "dectcmds_scriptsdir".
Wer die Textausgabe eines Kommandos in ein Bild umwandeln will (nicht aus den Augen verlieren, daß die Auflösung des Displays bei so einem Mobilteil begrenzt ist und größere Bilder erst noch von "picconv.sh" herunterskaliert werden), der kann den Pfad zu diesem Kommando mit "dectcmds_text2picture" im Kopf der Skriptdatei festlegen. Dieses Kommando erhält den Text auf stdin und muß auf stdout den vollständigen Namen der erzeugten Bilddatei ausgeben.
Wenn man die Zugriffsrechte für das Verzeichnis mit den Dateien aus dem dectcmds.tgz-Archiv richtig setzt (Schreibzugriff nur für den Owner, also "root"), dann kann man auch mit den NAS-Funktionen diese Dateien nur ansehen und nicht ändern.
Alles in allem läßt sich so etwas wie diese Kommandoausführung per FRITZ!Fon sicherlich auch auf anderen Wegen realisieren (sogar mit "ordentlichem GUI" wie bei SaS), aber wer sich schon immer eine (vom SmartPhone bzw. Tablet unabhängige) Möglichkeit einfacher Befehle an die FRITZ!Box gewünscht hat, etwas Willen zum "Basteln" aufbringt und - das ist das Entscheidende - ein AVM-DECT-Mobilteil hat, der kann damit fast alles umsetzen, was man sich vorstellen kann. Lediglich das Einschalten der DECT-Funktionen dürfte auf diesem Weg schwierig werden.
Und nicht vergessen ... das ist wieder kein "Rezept", eher ein "Serviervorschlag" und eigene Experimente sind nicht nur notwendig, sondern ausdrücklich die einzige Möglichkeit, sich damit anzufreunden und etwas Sinnvolles damit anzustellen. Vor eigenen Anstrengungen an dieser Stelle sollte man auch einmal probiert haben, wie kompliziert und langwierig der Weg über ein DECT-MT zu dieser Vorschau ist (auch mit Favoritenliste) und genau überlegen, ob man das nicht nur unter "aha" (meint nicht die "Home-Automation") ablegen will. Also sollte - trotz meiner Einleitung in diesem Beitrag - das Ganze gut überlegt sein, wenn man nur deshalb ein FRITZ!Fon anschaffen sollte ...
PS: Unter der URL http://yourfritz.de/dectcmds.modscript gibt es auch noch ein Skript für modfs, mit dem man die Änderung an der picconv.sh vornehmen lassen kann. Funktionieren wird das aber auch nur dann, wenn man den Inhalt des schon erwähnten dectcmds.tgz-Archivs unter dem Pfad /var/media/ftp/dectcmds entpackt, solange man kein eigenes "library file" anstelle meiner dectcmds_lib.sh benutzen will. Ändert man den Pfad, muß man das Modscript entsprechend anpassen ... und nicht vergessen, die Schreibrechte für andere als den Eigentümer für das Basisverzeichnis zu entfernen.
Als "Service" für Download und Auspacken des Modscripts:
Das alles natürlich vor dem Start von "modfs" ... das Auspacken des "dectcmds"-Pakets nach /var/media/ftp/dectcmds kann zu einem beliebigen späteren Zeitpunkt erfolgen, aber bitte nicht die NAS-Funktionen dazu benutzen (oder nur dann, wenn man genau weiß, was man da macht mit den Dateirechten).
Ach so ... zum Schreiben der irgendwo in den Bild-Kommentaren erwähnten README-Datei bin ich noch nicht gekommen - vermutlich hole ich das irgendwann einmal nach. Im Moment sollte dieser Beitrag eigentlich ausreichen, um sich eigene Kommandos zu basteln. Zum Setzen von Einstellungen im FRITZ!OS kann man dann ctlmgr_ctl verwenden oder das set.lua-Skript, Abfragen gehen auf allen möglichen Wegen (u.a. ctlmgr_ctl oder queries.lua).
Und damit jetzt niemand denkt, ich würde hier Werbung für AVM-Produkte machen ... ich weiß auch, daß es wertigere DECT-Mobilteile in dieser Preisklasse gibt, die obendrein noch besser klingen, auch wenn man den eingebauten Lautsprecher und "Freisprechen" benutzen will. Aber ganz so schlecht wie ihr Ruf sind diese Telefone auch nicht und wer sie z.B. als OEM-Modell bei 1&1 geordert hat, der ist ja vielleicht auch noch auf der Suche nach weiteren Anwendungsmöglichkeiten.
Das ist dann auch schon der - in diesem Beitrag - entscheidende Vorteil so eines FRITZ!Fons ... es arbeitet recht gut mit der Firmware einer FRITZ!Box zusammen. Dazu gehört u.a. auch der integrierte Media-Player, wobei dessen musikalische Qualitäten selbst mit Kopf- oder Ohrhörern wohl kaum über das "Küchenradio"-Niveau hinausgehen, aber die hier zu betrachtende Fähigkeit als "Wiedergabegerät" hat auch glücklicherweise nichts mit den "musikalischen Fähigkeiten" eines FRITZ!Fons zu tun.
Hier geht es darum, daß ein FRITZ!Fon in Kombination mit einer passenden FRITZ!Box auch benutzt werden kann, um sich eine Vorschau von Bildern anzeigen zu lassen, die irgendwo auf der FRITZ!Box gespeichert sind. Mir war der Sinn dieser briefmarkengroßen Vorschaubildchen bisher immer etwas unklar (außer man hat gerade nichts anderes bei der Hand, um den Inhalt einer bestimmten Datei zu überprüfen, aber wer würde dafür schon ein DECT-MT verwenden?), aber unabhängig von diesem Aspekt stellt sich ja auch noch die Frage, wie diese Vorschaubilder eigentlich auf das Mobilteil gelangen. Die Möglichkeit, daß diese Bilder direkt von der Quelle geladen werden und dann das Telefon selbst sie entsprechend skaliert, damit sie auf dem kleinen Display den korrekten Bildinhalt wiedergeben, kann man wohl getrost vergessen. Nicht nur, daß dazu eben z.B. ein 8 MB-JPEG-File erst einmal "over the air" zum Mobilteil gelangen müßte, so ein Telefon hat wohl kaum die notwendige Rechenpower für solche Skalierungen. Also wird wohl das Bild irgendwo anders aufbereitet werden und da bleibt ja eigentlich nur noch die FRITZ!Box.
Nach kurzer Suche in der Firmware findet sich dann früher oder später auch die Datei /bin/picconv.sh, wo offenbar solche Aktionen stattfinden ... schaut man sich dann dieses Skript etwas genauer an, stellt sich heraus, daß es vorwiegend vom pictured (und bei der Verarbeitung eines Fotos für einen Telefonbucheintrag) in der Firmware folgendermaßen aufgerufen wird:
Code:
/bin/picconv.sh [I]input[/I] [I]output[/I] [I]purpose[/I]Bis hier ist das ja alles schön und gut zu wissen ... aber was kann man denn nun mit diesen ganzen Informationen anfangen?
Wenn wir wissen, daß bei jeder Anzeige einer Bilddatei auf dem Display des Mobilteils erst einmal dieses Skript ausgeführt wird, dann bietet es sich ja förmlich an, die Firmware auch an dieser Stelle zu modifizieren (ich unterstelle mal, das man das als Leser im "Modifikationen"-Unterforum ohnehin macht), um bei der Anzeige einer solchen Bilddatei eigenen Code ausführen zu lassen. Den Umstand, daß der Bildbetrachter des Media-Players nur über mehrere Tastenbetätigungen zu erreichen ist (selbst wenn man ihn als Favoriten ablegt), kann man zwar bedauern, aber leider nicht ändern (ohne Modifikationen an Stellen, von denen man lieber die Finger läßt) - wie praktikabel der im folgenden aufgezeigte Weg im eigenen Haushalt zu verwenden ist, muß also jeder selbst einschätzen.
So eine Möglichkeit zur Ausführung eigener Kommandos macht natürlich am meisten Sinn, wenn es nicht immer derselbe Code ist und wie können wir das am ehesten flexibel gestalten? Sicherlich über die Verwendung unterschiedlicher Bild-Dateien. Bei dieser Vorgehensweise könnte man die Dateien, die man als "Kommando" verwenden will, auf mehreren Wegen von "normalen Bilddateien" unterscheiden.
Ein mögliches Merkmal wäre z.B. ein passender Pfad für den Dateinamen der Quelle, indem man ein Skript mit demselben Namen unter einem festen Pfad (z.B. eben /var/media/ftp/dectcmds/scripts) ablegt und die Anzeige einer Bild-Datei als Aufforderung zur Ausführung des gleichnamigen Skriptes mit dem eigenen Code interpretiert.
Leider macht uns hier die AVM-Firmware einen Strich durch die Rechnung, denn auch wenn man dem Mediaplayer (für DECT-MTs) eine Datei von einer externen Quelle vorsetzt (z.B. dem 1&1-Onlinespeicher), wird diese Datei erst einmal auf die Box übertragen und die Konvertierung erfolgt auch in diesem Falle immer aus einem festen lokalen Verzeichnis mit einem Namen mit aufsteigender Nummerierung. Damit fällt also die Verwendung des Dateinamens als Selektor für ein auszuführendes Kommando schon mal flach.
Alternative ist die Verwendung eines Formats einer Bilddatei, das sowohl von der FRITZ!Box unterstützt wird (bei 06.36 kommen dann PNG- und GIF-Files dazu) als auch die Angabe eines "Kommentars" in den Metadaten der Bilddatei erlaubt und dann wertet man eben diesen Kommentar aus ... dort könnte dann neben einer passenden "Signatur" für ein Kommando-Bild auch der Name des aufzurufenden Skripts und bei Bedarf weitere Parameter hinterlegt werden (z.B. bei der Verwendung zweier Bilder für ein einzelnes Skript, das über einen "on"- oder "off"-Parameter gesteuert wird).
Ich habe mich zwangsläufig für die Variante mit dem Bildkommentar entschieden (es gibt sicherlich noch andere Möglichkeiten, aber es muß sich eben auch um eine Bilddatei in einem unterstützten Format handeln, damit der Mediaplayer diese Datei überhaupt konvertieren will) und für die Verwendung von JPEG-Dateien, da die AVM-Firmware bereits alle Zutaten enthält, um den Kommentar einer JPEG-Datei auszulesen. Um die (externe) Angriffsfläche gar nicht erst übermäßig anzubieten (wir erinnern uns, daß das Skript durchaus auch mit einer URI zu einer externen Ressource aufgerufen werden könnte, wenn auch nicht für die Anzeige auf einem DECT-Handset), werden nur Dateien überhaupt einer näheren Untersuchung unterzogen, die sich bereits lokal auf der FRITZ!Box befinden, wo also der Dateiname mit "file://" beginnt.
Die spannende Stelle in der "picconv.sh" sieht jetzt so aus:
Code:
#download external urls or check local file
case "${in}" in
file://*)
in="${in#file://}"
if [ ! -r "${in}" ] ; then
do_exit 3
fi
;;
[...]
esac
Code:
#download external urls or check local file
case "${in}" in
file://*)
in="${in#file://}"
if [ ! -r "${in}" ] ; then
do_exit 3
fi
[B]
dectcmds_basedir="/var/media/ftp/dectcmds"
dectcmds_lib="$dectcmds_basedir/dectcmds_lib.sh"
if [ -r "$dectcmds_lib" ]; then
source $dectcmds_lib
in="$(dectcmds_command "$in")"
fi
[/B]
;;
[...]
esacDie eigentliche Arbeit bleibt damit dem Skript "dectcmds_lib.sh" vorbehalten, das kann natürlich jeder nach Belieben gestalten. Dabei darf man nicht aus den Augen verlieren, daß Textausgaben nach stdout/stderr als Dateinamen interpretiert würden; neben einer peniblen Prüfung auf mögliche Shell-Probleme wie fehlende Dateien o.ä., sollte man auch die Umlenkung der Ausgaben von aufgerufenen Kommandos nicht vergessen.
Einen Vorschlag für eine solche denkbare Implementierung kann man sich als Paket unter der URL http://yourfritz.de/dectcmds.tgz ansehen. Das "draft horse" setzt dabei auf JPEG-Bilddateien, die in ihren Kommentaren folgende Angaben enthalten:
| Tag | Optional | Standard | Inhalt |
| Package | nein | - | dectcmds (genauso auch geschrieben, sonst muß das Skript geändert werden) |
| Run | nein | - | aufzurufendes Kommando, der Dateiname kann die Zeichenketten "%SCRIPTDIR%" (für das "scripts"-Unterverzeichnis im Basisverzeichnis) oder "%BASEDIR%" für eben dieses Basis-Verzeichnis am Beginn enthalten |
| Parameter | nein | - | an das aufgerufene Kommando zu übergebende Parameter |
| Output | ja | STATIC | zu verwendende Bilddatei bei einem Exit-Code von 0 mit "STATIC" = Anzeige des Bildes "success.jpg" oder "DYNAMIC", dann ist die Ausgabe auf stdout der Name der zu konvertierenden Datei |
| OnError | ja | STATIC_PICTURE | Ausgabe des Kommandos bei Fehlern (Exit-Code ungleich 0) mit "STATIC_PICTURE" = Anzeige des Bildes "failure.jpg" oder "USE_OUTPUT", womit - bei Vorhandensein eines passenden Skript-Files auf der Box - aus dem Fehlertext ein Image generiert wird |
Die Sicherheit der FRITZ!Box steht und fällt natürlich bei diesem Skript mit der Sicherung der verwendeten Verzeichnisse gegen unberechtigte Schreibzugriffe, damit nicht z.B. der von der KiSi vom Internet abgeschnittene Nachwuchs mit einer eigenen Bilddatei irgendwo auf der FRITZ!Box (der Media-Server macht da wenige Unterschiede bei den Zugriffsrechten und kopiert die Dateien zur Konvertierung von jeder beliebigen Quelle erst einmal in ein "Zwischenlager" unter /var/tmp/dmgr_images) ein irgendwo anders auf der Box abgelegtes Skript aufrufen läßt, was ihm administrativen Zugriff auf die Box verschafft. Solchen Problemen kann man natürlich dadurch begegnen, daß man - nachdem man die eigenen Skripte entwickelt und getestet hat - nur noch bestimmte Verzeichnisse als Ablageort für die auszuführenden Kommandos akzeptiert und diese dann ggf. sogar noch ins SquashFS verlagert, so daß eine dynamische Modifikation ohnehin schon einen Zugriff auf die Box erfordern würde.
Entsprechende Einschränkungen sind schon im Skript enthalten, so akzeptiert das Skript eine Bilddatei nur dann als mögliche "Kommandoquelle", wenn sie unterhalb des Dateipfades liegt, der in der Variablen "dectcmds_picturesdir" angegeben ist. Dasselbe gilt für aufzurufende Kommandos (das können ja auch wieder selbst Shell-Skripte sein) und die Variable "dectcmds_scriptsdir".
Wer die Textausgabe eines Kommandos in ein Bild umwandeln will (nicht aus den Augen verlieren, daß die Auflösung des Displays bei so einem Mobilteil begrenzt ist und größere Bilder erst noch von "picconv.sh" herunterskaliert werden), der kann den Pfad zu diesem Kommando mit "dectcmds_text2picture" im Kopf der Skriptdatei festlegen. Dieses Kommando erhält den Text auf stdin und muß auf stdout den vollständigen Namen der erzeugten Bilddatei ausgeben.
Wenn man die Zugriffsrechte für das Verzeichnis mit den Dateien aus dem dectcmds.tgz-Archiv richtig setzt (Schreibzugriff nur für den Owner, also "root"), dann kann man auch mit den NAS-Funktionen diese Dateien nur ansehen und nicht ändern.
Alles in allem läßt sich so etwas wie diese Kommandoausführung per FRITZ!Fon sicherlich auch auf anderen Wegen realisieren (sogar mit "ordentlichem GUI" wie bei SaS), aber wer sich schon immer eine (vom SmartPhone bzw. Tablet unabhängige) Möglichkeit einfacher Befehle an die FRITZ!Box gewünscht hat, etwas Willen zum "Basteln" aufbringt und - das ist das Entscheidende - ein AVM-DECT-Mobilteil hat, der kann damit fast alles umsetzen, was man sich vorstellen kann. Lediglich das Einschalten der DECT-Funktionen dürfte auf diesem Weg schwierig werden.
Und nicht vergessen ... das ist wieder kein "Rezept", eher ein "Serviervorschlag" und eigene Experimente sind nicht nur notwendig, sondern ausdrücklich die einzige Möglichkeit, sich damit anzufreunden und etwas Sinnvolles damit anzustellen. Vor eigenen Anstrengungen an dieser Stelle sollte man auch einmal probiert haben, wie kompliziert und langwierig der Weg über ein DECT-MT zu dieser Vorschau ist (auch mit Favoritenliste) und genau überlegen, ob man das nicht nur unter "aha" (meint nicht die "Home-Automation") ablegen will. Also sollte - trotz meiner Einleitung in diesem Beitrag - das Ganze gut überlegt sein, wenn man nur deshalb ein FRITZ!Fon anschaffen sollte ...
PS: Unter der URL http://yourfritz.de/dectcmds.modscript gibt es auch noch ein Skript für modfs, mit dem man die Änderung an der picconv.sh vornehmen lassen kann. Funktionieren wird das aber auch nur dann, wenn man den Inhalt des schon erwähnten dectcmds.tgz-Archivs unter dem Pfad /var/media/ftp/dectcmds entpackt, solange man kein eigenes "library file" anstelle meiner dectcmds_lib.sh benutzen will. Ändert man den Pfad, muß man das Modscript entsprechend anpassen ... und nicht vergessen, die Schreibrechte für andere als den Eigentümer für das Basisverzeichnis zu entfernen.
Als "Service" für Download und Auspacken des Modscripts:
Code:
cd [I]modfs_directory[/I]
wget -O modscripts/dectcmds.modscript http://yourfritz.de/dectcmds.modscript
chmod 554 modscripts/dectcmds.modscript # für Nachfrage vor der Anwendung oder
chmod 555 modscripts/dectcmds.modscript # für automatische Anwendung des PatchesAch so ... zum Schreiben der irgendwo in den Bild-Kommentaren erwähnten README-Datei bin ich noch nicht gekommen - vermutlich hole ich das irgendwann einmal nach. Im Moment sollte dieser Beitrag eigentlich ausreichen, um sich eigene Kommandos zu basteln. Zum Setzen von Einstellungen im FRITZ!OS kann man dann ctlmgr_ctl verwenden oder das set.lua-Skript, Abfragen gehen auf allen möglichen Wegen (u.a. ctlmgr_ctl oder queries.lua).
Zuletzt bearbeitet:
