Nachdem mein WiFi-Bilderrahmen MeeFrame rund ein Jahr ungenutzt rumlag (da über MeeChannel nicht funktional und die initiale Idee, daß ich meiner Family dann via Picasa-Feed immer mal wieder Bilder aus Berlin auf den Frame schicke – Pendlerschicksal – auch nicht so richtig verfing) und mich bei einer krankheitsbedingten Auszeit beim Wertverlieren frech angrinste, surfte ich noch mal nach aktuellen Entwicklungen beim »InfoFrame-Projekt«, welches aus einer innovatigen Idee aus dem studentischen Alltag entsprang und sich lustigerweise im IP-Phone-Forum fortentwickelte — wohl anfänglich, da diese Implementation Features der Fritz-Boxen nutzt (und auf einer – »gefreezten« – FB lauffähig ist).
Da ich schon länger auf der Suche nach einem Display für Status-Werte, die meine Heimautomation FHEM auswirft, bin, studierte ich auch den InfoFrame-Hardware-Thread, allerdings ohne wirklichen Erfolg. Basierend auf Aussagen im VDR-Portal, die andeuteten, daß der SPF-87H unter Linux als dumme JPEG-Anzeige, ja sogar als Framebuffer, verwendbar sei, kontaktierte ich die Amazone meines Vertrauens und überbrückte die Wartezeit mit der Implementation des InfoFrame-Krams auf meinem neuen Nettop für yaVDR im Wohnzimmer. Dual-Core Atom mit Hyperventilation, äh, -threading, da sollte ja so’n bißchen Apache & PHP kein Problem sein …
Und in der Tat, bis auf die Notwendigkeit, libusb1 für Debian Lenny (Deskop-OS ist bei mir i. d. R. Ubuntu, auf den DockStars und sonstigen PlugComputern läuft i. d. R. Debian Lenny oder, wenn ganz neu aufgesetzt, Squeeze) aus den Backports zu ziehen, war sowohl die native Übersetzung auf ‘nem DockStar als auch die Ausführung der Binaries (spf87h-tool, playusb) herrlich unproblematisch, sodaß der Samsung SPF-87H nun von einem DockStar angesteuert wird (Prinzip: wget InfoFrame-Image, playusb, wait 20, redo once – und das minütlich per cron). Schick, und endlich mal schnell umgesetzt – da lacht das Hacker-Herz ;-)
Da mir der statische Hintergrund des normalen InfoFrames nicht zusagte, erweiterte ich erst einmal das PHP-Skript um dynamische Hintergrundbilder, basierend auf dem schon bei InfoFrame.org hinterlegten Gerüst.
Die Bilder werden im korrekten Seitenverhältnis auf die Bildgröße skaliert, die Bildgröße ist per GET-Parameter nuin auch wählbar. (Und bei Breiten unter 700 Pixeln wird die Datumszeile reformattiert, sodaß auch Mini-Rähmchen wie der Parrot-Rahmen ansteuerbar sind – ausgeben lasse ich auch 640×480, der Parrot rechnet das beim Empfang auf seine 320×240 Pixel zurecht.)
Eine weitere Ergänzung sind konfigurierbare »Seiten«, d. h. es können bestimmte Abfolgen von Plugins definiert werden, die auf einem Bild kombiniert werden, Mail, Weather, FHEM und Kalender zum Beispiel haben kaum auf 800×480 Pixeln sinnvoll
Ferner wurde die Möglichkeit geschaffen, relativ beliebige Sensordaten an InfoFrame zu übergeben — und z. B. vom FHEMPlugin ausgeben zu lassen. Auf FHEM-Seite wird per notify ein Skript gestartet …
define InfoFrameA notify .*_TH:T.* "/var/log/fhem/update_InfoFrame.sh "%NAME" "%
TYPE" "%EVENT""
define InfoFrameB notify WS3600_RH.*:.* "/var/log/fhem/update_InfoFrame.sh "%NAM
E" "%TYPE" "%EVENT""
…, update_InfoFrame.sh ist im Prinzip ein Wrapper, der die unterschiedlichen Parameter für den GET-Aufuf aufbereitet:
(/usr/bin/wget -O /dev/null -q "http://yavdr.local:1234/infoframe/?sensor=$SENSORNAME&type=$TYPESTR&value=$TEMPSTR") &
Welche Daten man, auch letztlich woher, an InfoFrame schickt, ist nicht genauer spezifiziert; die Magie muß das Plugin ggf. leisten, für TH (Temperatur- und Luftfeuchte-Sensoren vom Typ S300TH/S555TH) und getrennte Temperatur- bzw. Feuchtesensoren bringt das FHEMPlugin Logik mit, Rest muß man sich an die eigenen Bedürfnisse anpassen (oder den Warpper so schreiben, daß er die Daten wie erwartet ablegt ;-)):
mysql> select * from if_sensors;
+----------------‐--------------------‐------------‐--------------‐
| name | datum | typ | wert |
+----------------‐--------------------‐------------‐--------------‐
| Bad_TH | 2011-01-30 16:38:32 | TH | T:22_H:43.5 |
| Essz_TH | 2011-01-30 16:39:48 | TH | T:7.2_H:42.9 |
| Flur_TH | 2011-01-30 16:39:25 | TH | T:22.7_H:40.2 |
| Huette_TH | 2011-01-30 16:38:35 | TH | T:4.8_H:83.6 |
| Kammer_TH | 2011-01-30 16:30:39 | TH | T:22.9_H:38 |
| Keller_TH | 2011-01-30 16:34:20 | TH | T:19.6_H:36.6 |
| Parkplatz_TH | 2011-01-30 16:38:52 | TH | T:7.4_H:80.6 |
| Terrarium_TH | 2011-01-30 16:39:01 | TH | T:26_H:55.6 |
| WS3600_Forecast | 2011-01-30 16:39:22 | forecast | Cloudy |
| WS3600_Rain | 2011-01-30 16:39:22 | rain | R1h |
| WS3600_RHi | 2011-01-30 16:39:21 | humidity | 40 |
| WS3600_RHo | 2011-01-30 16:39:22 | humidity | 79 |
| WS3600_RP | 2011-01-30 16:39:22 | pressure | 1007.700 |
| WS3600_Tendency | 2011-01-30 16:39:22 | tendency | Falling |
| WS3600_Ti | 2011-01-30 16:39:21 | temperature | 22.6 |
| WS3600_To | 2011-01-30 16:39:21 | temperature | 0.5 |
+----------------‐--------------------‐------------‐--------------‐
16 rows in set (0.00 sec)
Zugegeben, das FEHMPlugin hat noch wenig Eye-Candy, aber in erster Linie ging es mir darum, die Werte sichtbar zu machen; ohne Browser sehen zu können, daß im Terrarium wieder Wasser nachgesprüht werden muß, ist schon recht praktisch — zumal dessen Bewohner das traditionelle Instrument gerne verbuddeln/umwerfen, der S300TH darin hingegen blieb bislang verschont.
Mit etwas Muße kann man, insbesondere auf den Icon-Set, welches für das WeatherPlugin schon vorhanden ist, da sicher was aufhübschen, aber ein Anfang ist schon mal gemacht ;)
Beim genauen Anschauen der Bilder fällt evtl. auf, daß der obere Bereich etwas abgedunkelt ist — das Problem ist, daß durch die Verwendung beliebiger Hintergründe es zu einem »weißer Adler auf weißem Grund«-Effekt kommen kann: man kann auf zu hellen Hintergründen die weiße Schrift nicht mehr (gut) erkennen. Der erste Trick war, das gesamte Hintergrundbild abzudunkeln, was aber oft wenig vorteilhaft ausssah. Somit dunkle ich derzeit nur die oberen 120 Zeilen ab und habe die Ausgabe des FHEM-Plugins auch nur für diesen Bereich vorgesehen. Das klappt bei vielen Querformatbilden auf meinen Rahmen (MeeFrame:, 800×600, SPF-87H: 800×480) recht gut, aber es bleibt ein Kompromiß. Optimal wäre eine (automatische) Abdunklung der Bereiche, in denen Ausgaben vorgenommen werden, derlei gibt aber die Ausgaberoutine nicht her. Deren eigenwilliges Verhalten ist auch der Grund, warum derzeit das FHEM-Plugin die Ausgabe mit »|« einrahmt — pixelgenaues Positionieren ist mit der Eierlegendenwollmilchsau-Routine nicht möglich (sie variiert die Baselein eigenmächtig), mehrzeilige Ausgaben orientieren sich an der benutzten Fläche, d. h. Texte mit Ober-/Unterlängen verbrauchen mehr Höhe als solche ohne. Weird ;-)
Das Skript zum Aktualisieren des Parrot-Bluetooth-Rahmens sieht wie folgt aus:
#!/bin/bash
# wusel@death:~$ hcitool scan
# Scanning ...
# 88:77:66:55:44:33 Parrot PHOTO
FRAMEBTADDR=88:77:66:55:44:33
SUFFIX="`date +%M|gawk '{printf("%d\n", $1%2);}'`"
wget -q -O /tmp/InfoFrame4Parrot.jpg 'http://yavdr.local:1234/infoframe/?width=640&height=480' 2>/dev/null
RC=$?
if [ $RC -eq 0 ]; then
/home/wusel/with_timeout +25 ussp-push ${FRAMEBTADDR}@ /tmp/InfoFrame4Parrot.jpg tmp-${SUFFIX}.jpg 2>/dev/null
fi
Leider überschreibt der Rahmen nicht empfangene Bilder gleichen Namens, sodaß in Bälde der (interne) Speicher voll sein dürfte; gut, den für 30 EUR aus UK bezogenen Rahmen hatte ich auch nicht primär für InfoFrame vorgesehen, sondem gedenke, ihn neuer Verwendung zuzuführen. Ihn für InfoFrame-Ausgabe zu verwenden ist insofern nur ein Proof-of-Concept ;-)
Ähnlich simpel ist auch die Ansteuerung des SPF-87H gelöst, nur daß hier playusb statt der BT-Übertragung eingesetzt wird:
#!/bin/bash
PWD="`pwd`"
cd /nfs/20090924-1TB
for times in 1 2
do
wget -q -O infoframe-tmp.jpg 'http://yavdr.local:1234/infoframe/?width=800&height=480' 2>/dev/null
if [ $? -eq 0 ]; then
/root/playusb -j infoframe-tmp.jpg 2>infoframe-dbg.out 1>&2
FAIL=$?
if [ $FAIL -ne 0 ]; then
/root/spf87h-tool 2>/dev/null 1>&2
fi
if [ $times == 1 ]; then
sleep 20
fi
fi
done
cd $PWD
(Da der DockStar von einem Flash-Medium läuft, gehe ich auf eine typischerweise sowieso oft aktive Platte und lege die Dateien dort ab.) Der Aufruf von spf87h-tool an dieser Stelle bringt nix, falls sich der Rahmen nicht in Vorbereitung auf den USB-Monitor-Modus befindet, was er erst nach manueller Intervention an den Knöpfen dort in Erwägung zieht, zumindest bei meiner Version. Allerdings läuft er nun auch seit zwei Tagen so durch, solange also in relativ kurzen Intervallen neue JPEGs kommen, scheint zumindest meiner diesen Modus nicht zu verlassen. Ich habe den Aufruf an der Stelle primär für den Fall drin, daß er sich mal aufhängt und ich ihn manuell in den USB-Monitor-Modus bringe – das Skript sollte dann ohne händisches Login die Umschaltung erledigen. Ob’s so klappt, wird die Zukunft zeigen …
Meinen MeeFrame habe ich übrigens über den Einsatz von MediaTomb an den Start gebracht. Per wget (Schema-F ;)) legt die yaVDR-Box jede Minute das aktuelle Bild in ein Verzeichnis, welches wiederum MediaTomb (als einziges) mittels inotify überwacht. Der MeeFrame nutzt über die Einstellung »MeeBox« den MediaTomb als UPnP-Server und streamt den Inhalt dieses Verzeichnisses (1 Bild ;-)) auf sein Display als Diashow. Leider ist auch das nicht rebootfest, sprich nach einem Neustart muß man wieder über den Touchscreen des MeeFrames navigieren: Bilder -> MeeBox -> (Serverauswahl:) MediaTomb -> PCDirectory -> Pfad -> zur -> Datei und dann in der Vorschau rechts das Bild anklicken und nach dem initialen Laden noch die Diashow mit Touch auf’s Dreieck-Icon oben starten. Lästig, aber immerhin. Wie lange das ohne Interaktion durchläuft, muß sichnoch erweisen; leider kennt der MeeFrame auch keine Schlafzeiten, wenn man ihn nicht abschaltet, läuft diese Diashow Tag und Nacht. (Wobei sie mir einmal nach 24h abgebrochen ist: Frame-Reboot – WinCE läßt grüßen? ;-))
Ich werde nun noch die Sourcen zusammenpacken, evtl. etwas (besser) kommentieren und dann später heute abend hier in einem Folgebeitrag ablegen, auf den ich dann auch im InfoFrame-Thread im IP-Phone-Forum verweisen werde.
