Nach der Installation wird die Software einfach mit dem Befehl “mediatomb” aufgerufen. Beim ersten Start wird eine SQLite-Datenbank angelegt und eine Konfig-Datei erstellt. Als Datenbank kann auch mySQL verwendet werden, SQLite wird jedoch bevorzugt, da hier die Datenbank vom Programm selbständig angelegt werden kann, ohne dass der Anwender während der Installation eingreifen muss (Username/Passwort Eingabe etc.). In die Datenbank schreibt Mediatomb später, welche Medien gestreamt werden sollen.
Die Daten, die ich streamen möchte, liegen bei mir auf einer externen 1 TB Festplatte von Western Digital. Diese wird per USB-Hub an den Sheevaplug angeschlossen und danach ins Betriebssystem gemounted. Nach dem Anschließen sollte das Gerät unter /dev zu finden sein. Dort einfach nach sd* suchen. Im Normalfall taucht die Festplatte dann dort mit dem Namen “sda” auf (oder auch “sdb”, “sdc” etc.).
/# cd dev
/dev# ls sd*
sda sda1

Gemounted wird die Festplatte dann in ein entsprechendes Verzeichnis, bspw. in /media/external
/# mkdir media/external
/# mount /dev/sda1 media/external

Damit mediatomb mit der Playstation 3 funktioniert, sind Anpassungen in der Konfigurationsdatei config.xml notwendig. Die Zeile
<protocolInfo extend=”no”/>
muss geändert werden in
<protocolInfo extend=”yes”/>
Die Konfigurationsdatei enthält außerdem eine Reihe von Mappings (siehe unter <mappings>), über die die jeweilige Dateiendung einer Mediendatei einem Mimetyp zugeordnet wird. Um divx für die PS3 zu ermöglichen muss die folgende Zeile
<– <map from=”avi” to=”video/divx”/> –>
entsprechend auskommentiert werden in:
<map from=”avi” to=”video/divx”/>
Bei Bedarf können hier auch einfach weitere Mappings aufgenommen werden.
Weiter oben in der Konfigurationsdatei gibt es auch die Möglichkeit einen festen Port zu hinterlegen. Die Weboberfläche von Mediatomb ist über einen bestimmten Port zu erreichen. Da dieser bei jedem Start von Mediatomb zufällig gewählt wird, macht es Sinn hier einen festen Wert einzutragen. Unterhalb von wird dazu die folgenden Zeile aufgenommen (hier im Beispiel für Port 49111):
<strong>…
<server>
<port>49111</port>
…</strong>

Über eine Weboberfläche hat man nach dem Start von Mediatomb die Möglichkeit die Medien auszuwählen, die man streamen möchte. Diese Information wird dann in die Datenbank geschrieben. Die Weboberfläche erreicht man über eine Adresse, die Mediatomb beim Start auf dem Bildschirm ausgibt, z.B. http://192.168.0.1:49111

Die Weboberfläche ist ähnlich einem Dateibrowser aufgebaut. Links oben klickt man auf “Dateisystem” und sollte dann unter /media/external die externe Festplatte finden. Man markiert dann die Verzeichnisse oder Dateien, die man streamen möchte und klickt oben rechts auf das + Symbol. Damit wird die Datei in der Datenbank für das Streamen vermerkt. Mit dem Symbol rechts daneben kann man auch Parameter für regelmäßiges automatisches Synchronisieren einstellen. Beispielsweise lässt sich somit ein bestimmtes Verzeichnis, bei dem sich der Inhalt oft ändert, in bestimmten Zeitintervallen automatisch mit der Datenbank abgleichen.
Auf der Playstation 3 muss jetzt noch die Verbindung mit dem Medienserver hergestellt werden. Dazu auf der PS3 unter “Einstellungen” – “Netzwerkeinstellungen” den Punkt “Verbindung mit dem Medienserver” auf “Aktiviert” stellen.

Kategorie: Browserspiel
Start: 04.01.2006
Status: in Entwicklung
Techniken: php/html/css
Datenbank: mysql
Adresse: www.mayia.de

Mit dem Befehl
fdisk /dev/mmcblk0
startet man das Tool “fdisk”, mit dem man den Datenträger partitionieren und formatieren kann.
Für die 4 GB große SD-Karte habe ich folgende Partitionen angelegt:
Boot: 50 MB
Daten: 3200 MB
swap: 512 MB

Die Partitionstabelle sollte nach der Partitionierung dann so aussehen:
Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes
49 heads, 48 sectors/track, 3292 cylinders
Units = cylinders of 2352 * 512 = 1204224 bytes
Disk identifier: 0×00000000
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1 45 52896 83 Linux
/dev/mmcblk0p2  46 2832 3277512 83 Linux
/dev/mmcblk0p3  2833 3292 540960 82 Linux swap / Solaris

Danach sind die SD-Karte bzw. die drei Partitionen mit folgenden Befehlen zu formatieren:
mkfs.ext2 -I 128 /dev/mmcblk0p1
mkfs.ext2 /dev/mmcblk0p2
mkswap /dev/mmcblk0p3

Danach wird der Tar Ball von der Homepage von Martin Michlmayr direkt per wget heruntergeladen und auf der SD-Karte installiert.
Damit der Bootvorgang von der SD-Karte stattfindet müssen die Bootargumente in U-Boot geändert werden. Dazu zunächst den Bootvorgang starten und dann gleich abbrechen (wenn der Counter hochzählt), so dass der Marvell-Prompt zu sehen ist (Marvell>>). Nun befinden wir uns im Bootloader und können mit “printenv” uns die aktuellen Bootargumente anschauen.
Für den Fall, dass etwas schief läuft, wollte ich die Möglichkeit haben noch über den internen Flash-Speicher zu booten, in dem ich einfach die SD-Karte entferne.

Für diesen Dual-Boot sind folgende Befehle einzugeben. Damit werden die Bootargument entsprechend geändert.Zunächst die Bootargumente für die SD-Karte setzen:
setenv bootargs_sd ‘console=ttyS0,115200 ro root=/dev/mmcblk0p2′
setenv bootcmd_sd1 ‘setenv bootargs $(bootargs_sd); mmcinit; ext2load mmc 0 0×0800000 /uInitrd’
setenv bootcmd_sd2 ‘ext2load mmc 0 0×400000 /uImage; bootm 0×400000 0×0800000′

Dann die Bootargumente für den Nand Flashspeicher setzen:
setenv bootargs_nand1 ‘console=ttyS0,115200′
setenv bootargs_nand2 ‘mtdparts=orion_nand:0×400000@0×100000(uImage),0x1fb00000@0×500000(rootfs)’
setenv bootargs_nand3 ‘ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs’
setenv bootcmd_nand ‘setenv bootargs $(bootargs_nand1) $(bootargs_nand2) $(bootargs_nand3); nand read.e 0×00800000 0×00100000 0×00400000;bootm 0×00800000′

Zum Schluss den Bootbefehl setzen:
setenv bootcmd ‘run bootcmd_sd1; run bootcmd_sd2; run bootcmd_nand’

Hinweis: Da die Anzahl der Bootargumente beschränkt ist, werden sie auf mehrere Variablen (bootcmd_sd1, boot_cmd_sd2 etc.) aufgeteilt.

Sollte jetzt der Bootbefehl für die SD-karte nicht funktionieren (z.B. weil sie nicht eingesteckt ist) werden automatisch die nächsten Bootbefehle in Folge (hier bootcmd_nand) für den Flashspeicher ausgeführt.

Alternative auf dem Mac wenn wget nicht zur Verfügung steht ist curl.
Dazu ein Alias einrichten mit: echo ‘alias wget=”curl -O”‘ >> ~/.bash_profile
Nun kann wget auch auf dem Mac genutzt werden.

Danach muss ein Konfigurationsfile angelegt werden, in dem u.a. alle Geräte definiert werden müssen, die man steuern möchte:
mkdir /etc/fhem
nano /etc/fhem/fhem.cfg

In das angelegte Konfigurationsfile fhem.cfg werden nun alle Konfigurationsdaten geschrieben.
Im Folgenden sind Auszüge aus meinem Konfigurationsfile aufgelistet.
(Details zur Konfiguration findet man auf der Homepage von FHEM)
Zuerst globale Attribute, wie bspw. die Dateien fürs Loggen, den Loglevel, den Port usw.
attr global logfile /var/log/fhem/fhem-%Y-%m-%d.log
attr global statefile /var/log/fhem/fhem.save
attr global verbose 3
attr global port 7072 global
attr global modpath /usr/local/lib

Dann wird der Sender, die FHZ1000PC, definiert:
define FHZ FHZ /dev/ttyUSB0

Danach die einzelnen Empfänger, hier am Beispiel Wohnzimmer:
#——Wohnzimmer—————————-
setdefaultattr room Wohnzimmer
define radiator1 FHT 1e1e
attr radiator1 comment Wohnzimmer-Heizung
define fht_report1 at +*00:30:00 set radiator1 report1 255 report2 255
define socket1 FS20 651f 00
attr socket1 comment TV und Receiver
define socket2 FS20 651f 01
attr socket2 comment PS3

Die Heizung (radiator1) wird im obigen Beispiel mit dem Hauscode 1e1e definiert. Um den Hauscode zu ermitteln, startet man einfach FHEM und beobachtet das Log-File (es muss das loglevel auf mindestens 4 gesetzt werden (attr global verbose 4)). Nach einiger Zeit findet man im Logfile eine Warnmeldung, dass ein Gerät gefunden wurde, welches noch nicht definiert ist. Der Hauscode des Gerätes wird dabei anzeigt.
Da die FHT80B nur sehr unregelmäßig den Status sendet, wird eine Zeitplanung (fht_report1) definiert, die alle 30 Minuten einen entsprechenden Report von der FHT80b anfordert.
Mit socket2 und socket3 sind hier Funktsteckdosen definiert worden. Der verwendete Hauscode spielt im Normalfall keine Rolle. Er kann beliebig vergeben werden. Zum “Anlernen” der Funksteckdosen wird der Einschaltknopf am Empfänger so lange gedrückt, bis dieser anfängt zu blinken. Dann wird ein entsprechender Sc haltbefehl über FHEM ausgelöst:
fhem.pl 7072 “set socket1 on”

Damit ist die Funksteckdose auf den Hauscode programmiert.
Da ich die Funksteckdosen parallel auch mit einem Handsender bedienen will, sind noch weitere Konfigurationen notwendig. Das Problem bei den Schaltsteckdosen ist, dass sie keine Rückmeldungen geben. FHEM “merkt” sich zwar den aktuellen Schaltvorgang (an oder aus), bekommt aber keine aktive Rückmeldung über den Zustand der Steckdose, bspw. ob der Befehl auch korrekt angekommen ist. Wird parallel noch ein Handsender eingesetzt wird das ganze unter Umständen recht unzuverlässig und bspw. auf einer Webseite ist der aktuelle Zustand (an oder aus) dann nicht mehr sicher darzustellen.
Für den Parallelbetrieb mit einem Handsender gibt es jetzt zwei Möglichkeiten. Entweder der Handsender löst über die FHZ1000PC die Schaltung aus, oder der Handsender löst die Schaltung direkt aus. Ich habe mich für die Direktauslösung entschieden, da das Schalten über den Umweg FHZ1000PC nicht zuverlässig genug war (vielleicht weil die Funksteckdosen parallele Befehle vom Handsender und von der FHZ1000PC nicht gut verarbeitet?) .
Bei der Direktschaltung über den Handsender soll aber die FHZ1000PC bzw. FHEM (falls es den Schaltcode empfängt) zumindest den Schaltstatus mitbekommen und speichern. Auf einer Webseite ist der aktuelle Status der Steckdose somit auch anzeigbar, wenn die Schaltung über den Handsender durchgeführt wird.
Für die Umsetzung werden die Steckdosen zunächst auf den Handsender programmiert. Im LogFile von FHEM wird der Handsender als unbekanntes Gerät aufgelistet und (in meinem Fall) der Code 651f ausgegeben. Diesen Code verwenden wir entsprechend in der Konfigurationsdatei:
#——dummy———
setdefaultattr room hidden
define rc1 FS20 651f 00
define rc1_socket1 notify rc1:% setstate socket1 %
define rc2 FS20 651f 01
define rc2_socket2 notify rc2:% setstate socket2 %

Mit rc1 wird der Handsender entsprechend definiert. 00 hinter dem Code 651f entspricht dem ersten Tastenpaar auf dem Handsender. Analog dazu wird mit rc2 und 01 das zweite Tastenpaar des Handsenders definiert. Mit der notify-Regel wird jetzt jeder empfangene Schaltvorgang des Handsenders (% steht für beliebige Schaltvorgänge, also on oder off) im Status (setstate) von socket1 bzw. socket2 gespeichert.
Mit dieser Definition bekommt also FHEM auch das Schalten der Steckdosen über den Handsender mit und speichert die Information entsprechend.
Weitere Möglichkeiten und Einstellungen findet man auf der Homepage von FHEM.
Wenn beim Start von FHEM die Fehlermeldung “Cant locate Device/SerialPort.pm” kommen sollte, ist es notwendig folgende Installation durchzuführen:
apt-get install libdevice-serialport-perl

Auf der Seite von FHEM gibt es einige Frontends, die man für die Steuerung von FHEM einsetzen kann. Ich habe dafür allerdings mein eigenes Frontend “myHouseBot” auf php-Basis gebaut. Neben der Heizungssteuerung und dem Schalten von Funksteckdosen, habe ich damit auch die Möglichkeit per Webcam die Wohnung zu überwachen, einige Shell-Scripte auf der Sheevaplug zu starten, die Temperaturdaten grafisch darzustellen usw. Die Log-Files von FHEM lassen sich über das Frontend anzeigen, sowie das Konfigurationsfile laden und ändern. Außerdem kann der FHEM-Server gestoppt und gestartet werden. Temperaturwerte aus der Heizungssteuerung werden von FHEM in einer eigenen Datenbank gespeichert. Aus diesen Daten erzeuge ich über die Grafikfunktionen von php (gdlib) entsprechende Temperaturgrafiken, die automatisch beim Laden der Webseite erzeugt werden.
In einer zusätzlichen Datenbanktabelle werden alle Schaltvorgänge, die über die Webseite ausgeführt werden, mitprotokolliert.

Vor kurzem wurde durch ein Softwareupdate mein Technisat HD K2 Festplattenreceiver WLAN-fähig, so dass ich diesen jetzt per USB-WLAN-Stick in mein Netzwerk integrieren konnte und ebenfalls über myHouseBot erreichen kann. Timerprogrammierung ist damit von überall aus möglich.
Außerdem habe ich noch vor kurzem eine Möglichkeit umgesetzt, “Timer” für die Funksteckdosen zu programmieren. Damit lassen sich die Steckdosen zu festgelegten Zeiten automatisch ein- und ausschalten. Sehr nützlich wenn man tagsüber bspw. etwas im TV aufnehmen möchte, aber die Geräte nicht den ganzen Tag auf Standby stehen lassen will. Der Timer schaltet das Gerät dann kurz vor der geplanten Aufnahme automatisch an.
Und ich habe noch einige weitere Ideen, die ich in Zukunft umsetzen werde….
Zum Abschluss des Workshops noch ein paar Bilder von meinem Frontend “myHouseBot”:

Die Formatierung des USB-Sticks kann unter Windows am schnellsten über die Datenträgerverwaltung durchgeführt werden. Diese findet man unter Systemsteuerung – Computerverwaltung.
Der USB-Stick wird dann an den Sheevaplug gesteckt und über die serielle Konsole wird der Sheevaplug mit dem PC verbunden. Im nächste Schritt muss die korrekte Vendor-ID (bei mir 0×0403) und Product-ID (bei mir 0×6010) des Sheevaplug-Anschlusses ermittelt werden. Das kann man beispielsweise mit der Software USBDeview machen. Diese Daten werden in der Datei \uboot\openocd\config\interface\sheevaplug.cfg eingetragen. Außerdem wird die Zeile mit “ft2232_device_desc” mit “#” auskommentiert:

interface ft2232
ft2232_layout sheevaplug
ft2232_vid_pid 0×0403 0×6010
#ft2232_device_desc “SheevaPlug JTAGKey FT2232D B”
jtag_khz 2000

Der Installer startet eine Software auf dem PC, entweder unter Linux oder unter Windows über die Kommandozeile.

 Damit der Installer unter Windows den Sheevaplug über den USB-Anschluss findet sind einige Treiber zu installieren (siehe dazu auch diesen Beitrag im Forum von www.plugcomputer.org.) Unter Windows wird dann in der Kommandozeile der Befehl “runme.exe nand” eingeben, um die Installation auf dem Nand-Flash Speicher durchzuführen. Leider hatte ich mit der Installation unter Windows keinen Erfolg. Der Sheevaplug wurde von der Installationssoftware leider nicht gefunden und gab ständig die Fehlermeldung

“Error unable to open ftdi device: device not found”.

Ich habe die Installation daher über Linux durchgeführt. Dazu von VMWare den kostenlosen VMWare-Player unter Windows installiert und ein Ubuntu 9.10 Image in den Player geladen. Damit hat man ein voll funktionierendes Linux-System in einer virtuellen Maschine laufen. Damit der Sheevaplug am USB Anschluss erkannt wird muss das Treibermodul in den Kernel gehängt werden: “modprobe ftdi_sio vendor=0×0403 product=0×6010″. Und ggf. libftdi1 installiert werden (apt-get install libftdi1).
 Mit dem Befehl “lsusb” werden alle USB-Anschlüsse aufgeführt. Dort muss der Sheevaplug dann bspw. wie folgt aufgeführt sein:

“Bus 002 Device 006: ID 0403:6010 Future Technology Device International, Ltd FT2232C Dual USB-UART/FIFO IC”.

Ich habe den Installer dann mit dem Befehl “wget” erneut herungergeladen, diesmal aber in der Virtuellen Maschine. Im Anschluss die Datei sheevaplug.cfg wie oben beschrieben angepasst und den Installer mit “php runme.php nand” gestartet. Die Installation lief dann sauber durch und nach ca. 5 Minuten war der Sheevaplug wieder bereit zu booten

Darüber wird der Plugcomputer mit dem mitgeliefertem USB-Kabel an einen USB-Anschluss eines PCs angeschlossen. Leider ist der Mini-USB-Stecker des mitgelieferten Kabels eine Idee zu schmal ausgefallen, so dass er nicht fest genug im Anschluss sitzt. Alternativ kann hier aber jedes andere USB-Kabel mit Mini-USB-Anschluss verwendet werden. Der Zugang per SSH erfolgt über den Ethernet-Anschluss. Hiermit lässt sich der Plugcomputer bspw. direkt an einen Router anschließen.

Zu Beginn empfiehlt es sich auf jeden Fall den Anschluss per serieller Konsole vorzunehmen, da nur so auch der komplette Bootvorgang des Plugcomputers mitverfolgt werden kann. Nur so ist es auch möglich die Booteinstellungen zu ändern, um bspw. den Bootvorgang über eine SD-Karte durchzuführen.
Auf dem PC muss zunächst eine Kommunikationssoftware installiert werden. Hier bietet sich bspw. das kostenlose Programm Putty an. Die für die USB-Serielle Verbindung notwendigen Treiber findet ihr hier: www.ftdichip.com. (Unter Win XP sollte das ganze problemlos funktionieren, mit Mac OS X hatte ich leider einige Probleme mit den Treibern).    Nach erfolgter Installation sollten beim Anschließen der Sheevaplug an einen USB-Port Eures PCs im Gerätemanager automatisch zwei neue COM-Ports auftauchen, z.B. COM3 und COM4. Welche Ports zur Verfügung gestellt werden ist abhängig vom USB-Anschluss. Es werden immer zwei COM-Ports angezeigt. Der erste ist der JTAG-Port (den wir an dieser Stelle erstmal nicht benötigen), der zweite die Serielle Konsole.

In Putty wird der Connection Type auf “Serial” gestellt, der korrekte Com-Port eingetragen und die Geschwindigkeit auf 115200 Baud gestellt. Mit einem Klick auf “Open” sollte sich das Verbindungsfenster öffnen. In dieses mit der Maus klicken und eine beliebige Taste drücken, dann sollte eine Eingabeaufforderung zum Einloggen erscheinen.
Im Auslieferzustand ist der Loginname: root und das Passwort: nosoup4u.

Die zweite Zugangsmöglichkeit auf das Betriebssystem ist per SSH über ein Netzwerkkabel (Ethernet-Anschluss). Dazu das Netzwerkkabel einfach an einen Router anschließen un d die vom Router vergebene IP-Adresse für den Zugang verwenden. Unter Mac OS kann dafür einfach der Terminal verwendet werden. Im linken Bild ist das Anmelden per SSH dargestellt (ssh User@Ip-Adresse-Sheevaplug).