Homeserver 34: Die Fritz!Box an die USV anschließen

Nun, da die USV durchaus noch Kapazitäten frei hat, würde ich sie nun auch dafür nutzen wollen, meine Fritz!Box noch eine Weile zu betreiben. Fällt nur der Strom in unserem Haus, oder nur in der unmittelbaren Straße aus, so habe ich immer noch DSL, und kann also auch noch Mails verschicken. Die Fritz!Box noch eine Weile betreiben zu können ist insofern wichtig, da ich nur noch einen AllIP-VDSL-Anschluss habe. Bei einem Stromausfall könnte ich also nicht einmal mehr telefonieren.

Nennt mich ruhig nostalgisch, aber ich sehne mich schon irgendwie nach ISDN-Zeiten zurück. Das ISDN-Netz bekam seinen Strom durch das Telefonnetz selbst. Fiel also mal der Strom aus, so war zwar eine Telefonanlage ausgefallen, aber man konnte ein Tischtelefon direkt am ISDN-Anschluss für Notfälle betreiben. Somit waren also auch evtl. nötige Notrufe noch möglich. Fällt aber bei einem AllIP-Anschluss der Strom aus, ist Ende im Gelände! Da mag ein Schnurlostelefon noch so voll geladene Akkus haben, Telefonieren is nich! 🙁 Nicht nur, weil die Basisstation des Schnurlostelefons keinen Saft mehr hat, sondern das ganze Netz nicht mehr! 🙁 VoIP mag ja sonst eine Menge Vorteile haben, dies ist definitiv keiner davon!

Mit der USV kann ich aber meine Fritz!Box noch eine Weile betreiben. Zumindest reicht es aus, dass der Server seine Status-Mails los wird, mein WLAN noch für eine Weile steht und mein MacBook z. B. sein Backup abschließen kann und evtl. ich noch eine Weile telefonieren kann. Mein Schnurlostelefon ist nämlich an der Basis der Fritz!Box angemeldet.

Das mit den Backups ist wichtig, da es sonst dazu führen kann, dass so ein TimeMachine-Backup unbrauchbar werden könnte. Und da diese Backups meist nur zwischen 2 und 5 Minuten dauern, reicht auch der Strom der USV dafür noch aus. Selbst wenn der Backup-Vorgang länger dauern sollte, so hat man genug Zeit, den Vorgang über das Menü sauber abzubrechen. Somit verbleibt das TimeMachine-Backup in einem benutzbaren Zustand.

Ist der Stromausfall aber großflächig, also so etwas wie der Stromausfall für einen ganzen Stadtteil, und ist der graue Kasten, an dem man mit seiner VDSL-Leitung angeschlossen ist, nicht mit Notstrom ausgestattet, nutzt das natürlich nichts. Aber man kann sich auch nicht für alle Eventualitäten wappnen. Für den Fall eines Stromausfalls in der eigenen Wohnung, dem Haus oder nur eines Teils der Straße jedoch ist diese Absicherung mehr als ausreichend.

Was brauche ich?

Ich habe mich für die APC Back-UPS BX700UI entschieden, was im Nachhinein vielleicht ein Fehler war. Diese hat nur 4 Kaltgerätestecker. Falls ihr noch keine USV angeschafft habt, nehmt die Varianten mit Schuko-Stecker, das sind die normalen Steckdosen. Diese Modelle sind zwar 8 bis 10 € teurer, aber dafür müsst ihr euch keine Adapter kaufen.

Ich benötige also, um die Fritz!Box anschließen zu können, einen Adapter von Kaltgeräteanschluss auf Schuko-Stecker. An der USV sind 4 Kaltgerätebuchsen, weiblich, also benötige ich einen Kaltgerätestecker männlich auf Schuko-Buchse weiblich. Solche Adapter gibt es eine Menge, ich habe einen von Inline für 5,58 € gekauft.

Anschluss

Das ist denkbar einfach. Man schließt einfach den Kaltgerätestecker an eine der freien Buchsen an der USV an. Am anderen Ende des Kabels baumelt eine normale große Steckdose. Hier steckt man das Netzkabel der Fritz!Box ein, fertig. Man muss die USV oder sonst etwas, was an der USV angeschlossen ist, nicht extra ausschalten dafür.

Der Rest ist selbsterklärend: Einige Zeit später ist die Fritz!Box hochgefahren und hat sich mit der DSL-Vermittlungsstelle synchronisiert. Fällt nun der Strom aus, die Vermittlungsstelle aber arbeitet weiter, so bleibt die DSL-Verbindung bestehen und man kann noch telefonieren, bis der USV der Saft ausgeht. Zwar wird sich der Server irgendwann zwischen 15 und 10 % Kapazität der USV abschalten, die Fritz!Box jedoch wird noch eine Weile weiter mit Strom versorgt werden.

Status der USV mit angeschlossener Fritz!Box

Der Server verbraucht für sich etwa 17 % der Kapazität der USV und kann, laut Statusanzeige, bis zu 32,3 Minuten betrieben werden. Dafür, dass der Server im Leerlauf ist, ist das schon eine ganze Menge. Jeden ersten Sonntag im Monat macht MDADM einen Integritäts-Check des RAIDs. Neugierig, wie ich bin, habe ich mal geguckt, was der Status hierzu zu sagen hatte. Die Last war dann bei 23 % und der Server hätte etwa 21 Minuten betrieben werden können. Das habe ich jetzt aus dem Kopf wiedergegeben, weil ich nicht dran gedacht hatte, die Werte aufzuschreiben. Könnte also sein, dass ich mich etwas in der Laufzeit vertue. Trotzdem, immer noch über 20 Minuten, und auch das ist beachtlich.

Gehen wir aber mal vom Normalfall aus, also 17 % Last auf der USV bei Leerlauf des Servers. Naja, ganz im Leerlauf ist er ja nicht, ein paar Dienste laufen schon noch im Hintergrund. Aber die sind nicht so energiehungrig.

Wenn ich nun die Status-Webseite aufrufe, so sehe ich für die Auslastung der USV einen Wert von 19 % und eine voraussichtliche Batterielaufzeit von 28,7 Minuten. Das heißt, die Fritz!Box belastet die USV mit gerade mal um die 2 %. Wenn der Server also heruntergefahren wird, ist die Fritz!Box noch eine geraume Zeit online!

Fazit

Ob man sich jetzt die USV mit Kaltgerätesteckern und Adaptern für Schuko-Stecker kauft, oder ob man gleich die USV mit Schuko-Steckern kauft, preislich macht es keinen Unterschied. Aber falls ihr noch keine USV gekauft habt, würde ich aus Bequemlichkeit die Variante mit Schuko-Steckern kaufen.

Immer noch ist Luft nach Oben. Aber man muss die USV auch nicht bis zum Zusammenbruch auslasten. Trotzdem, beruhigend, dass der Server beim nächsten Stromausfall nicht einfach ausgeht und die Daten in einem Chaos zurücklässt.

Homeserver 33: Unterbrechungsfreie Stromversorgung

So, jetzt reicht’s mir! Das war jetzt der dritte Stromausfall innerhalb der letzten paar Monate. Und jedes Mal muss ich den Server überprüfen, ob das Dateisystem Schaden genommen hat, ob das RAID noch funktioniert, ob Daten verloren sind… All das steht in absolut keinem Verhältnis zu einer 60 € USV. Zwar dauern diese Stromausfälle nie lange, meistens zwischen 1 und 5 Minuten, aber das ist ja letztlich auch egal. Der Server ist dennoch ausgegangen, und zwar ohne seine Daten korrekt abzulegen. Jedenfalls im schlimmsten Fall.

Hinzu kommt, dass ich hier öfter mal Spannungsschwankungen habe. Die sind auch nicht wirklich schlimm, können aber zur Folge haben, dass eine Festplatte sich aus dem RAID abmeldet, wieder eingetragen werden muss und Stunden braucht, bis das RAID wieder synchronisiert ist und fehlerfrei läuft.

Also finde ich, ist jetzt der richtige Zeitpunkt gekommen, eine unterbrechungsfreie Stromversorgung anzuschaffen. Die soll gar nicht so sehr den Server im Betrieb halten. Wenn aber der Netzstrom ausfällt, soll der Server kontrolliert und vernünftig heruntergefahren werden. Und am besten wäre das, wenn dies auch noch automatisch gehen würde! Und diese USV soll, nach Möglichkeit, Spannungsschwankungen ausgleichen und auch als Überspannungsschutz dienen.

Diese Wünsche klingen echt teuer, oder? Habe ich auch gedacht, aber ist es zum Glück nicht. Ich habe mich selbst gewundert, aber man kann all dies tatsächlich schon für weit unter 100 € haben. Und zwar bietet APC ein paar USVs an, die für diesen Zweck geradezu ideal sind.

Ich habe mich für eine APC Backups BX700UI entschieden. Zum Zeitpunkt des Kaufs kostete sie 62,99 € bei Amazon. Die hat 390 Watt Ausgangsleistung und soll bei halber Last 9 Minuten überbrücken können. Für meine Zwecke reicht das Dicke, weil mein Server niemals so viel braucht. Selbst wenn, reicht die Zeit locker, um sauber herunterzufahren.

So eine USV hat durchaus Vor-, aber auch Nachteile. Daher werde ich mal ein Paar davon aufzählen.

Vorteile

Diese dürften auf der Hand liegen:

  • Bei Stromausfall sauberes Runterfahren
  • Automatische Spannungsregulierung und Überspannungsschutz
  • Bis zu 4 Geräte können hier angeschlossen werden
  • Gerät ist per PC steuerbar, geht mit Linux genau so gut wie mit Windows

Nachteile

Ja, so ein Teil hat leider auch Nachteile. Aber man muss halt abwägen, ob man sich damit zufrieden geben kann, oder ob die Nachteile die Vorteile überwiegen. Ich persönlich kann mit den Nachteilen leben.

  • Alle Geräte kleiner als 700VA sind nicht steuerbar. Das Modell BX500UI hätte mir auch gereicht, ist aber halt nicht von Linux steuerbar und kann nicht den PC runterfahren.
  • Ich habe das Modell mit 4 Kaltgeräteanschlüssen gewählt. Es gibt das ganze auch mit 4 Schuko-Steckern, das ist aber teurer.
  • Die USV verbraucht selbst ebenfalls Strom. In den Rezensionen gehen die Meinungen aber auseinander, wie hoch der Verbrauch tatsächlich ist, auch wenn die Akkus voll sind.
  • Akkus sind nicht durch den Anwender austauschbar. Das muss der Service tun. Die Kosten für das Hin- und Herschicken, Akku, Arbeit, … So ein Akku soll zwischen 3 und 5 Jahren halten. Wäre zu überlegen, ob eine neue USV dann nicht evtl. billiger ist.
  • USB-Kabel nicht im Lieferumfang. OK, kein Beinbruch, aber wissen sollte man das schon. 🙂 Falls man also kein USB A-B-Kabel hat, sollte man sich noch eines besorgen.

Vorbereitungen

OK, dann mal los! Ein etwas gewichtiges Paket ist bei mir eingetroffen. Ich habe aber, um schon mal vorbereitet zu sein, das PDF-Handbuch zu dem BX700UI gelesen. Danach ist es sogar ziemlich einfach, das Gerät in Betrieb zu nehmen, weil es so viel gar nicht dran einzustellen gibt.

Lediglich 2 Punkte in der Anleitung stören mich: Die Signaltöne und LED-Signale sind in einer Tabelle in der PDF beschrieben, die nur schwer zu lesen ist. Eine andere Tabelle beschreibt die Möglichkeiten, das Verhalten der USV bei Stromschwankungen und dergleichen einzustellen. Auch diese ist mit Jaws nicht gut zu lesen. Da muss ich mir mal helfen lassen, aber abgesehen davon sehe ich keine Probleme.

Der Inhalt des Kartons ist relativ unspektakulär. Ein Handbuch, ein Kaltgerätekabel zum Verbinden der USV mit einem PC, und die USV selbst. Puh, das Teil müffelt! 🙁 Hoffentlich geht das bald weg!

An der Front der USV ist nur der Power-Knopf. An der Rückseite gibt es 4 Kaltgeräteanschlüsse, ein Netzanschluss, eine Unterbrechertaste – so etwas wie eine Sicherung, RJ-11-Anschlüsse zum durchschleifen und den Batteriekonnektor. Und natürlich ist dort auch der USB-Anschluss für die Steuerung.

Die Batterie ist zwar fest eingebaut, aber noch nicht angeschlossen. Hat also keinen physischen Kontakt zum Gerät. Hierfür gibt es hinten eine Art Griff, genau befindet der sich hinten oben. Dieser muss rausgezogen, nach unten geklappt und in das Gerät reingeschoben und fest reingedrückt werden. Sollte man, warum auch immer, die USV länger mal wegpacken wollen, kann man mit einem Schlitzschraubendreher den Griff wieder rausziehen, um die Batterie wieder vom Gerät zu trennen.

Das wär’s eigentlich schon, die USV ist bereits einsatzbereit.

Installation

Die Installation geht in 2 Schritten. Zunächst muss die USV angeschlossen und mit dem Server verbunden werden. Das betrifft die Stromversorgung, aber auch ein USB-Kabel für das Monitoring. Als nächstes muss auf dem Server das Paket für das Strom-Management installiert und konfiguriert werden.

Hardware-Installation

Zunächst fahre ich den Server herunter und trenne ihn vom Strom. Das Netzkabel, welches von der Wandsteckdose in den Server ging, wird jetzt in die USV gesteckt. Sobald die USV Strom aus der Wand bekommt, beginnt sie bereits, ihre Batterien aufzuladen.

Das Kaltgerätekabel wird in einen der 4 hinteren Anschlüsse an der USV eingesteckt, das andere Ende kommt in das Netzteil des Servers.

Und zu guter Letzt kommt ein USB-Kabel an die USV, das andere Ende natürlich in den Server, damit wir die USV steuern, bzw. die USV den Server herunterfahren kann. Ich sagte ja bereits, dass kein USB-Kabel im Lieferumfang der USV war. Nun, in meiner PC-Grabbelkiste findet sich derlei Zeugs zu Hauf. Wer keines hat, sollte beim Kauf der USV dran denken. Ihr braucht eines mit einem A-Stecker an dem einen, und einem B-Stecker am anderen Ende.

Natürlich fährt nicht die USV den Server runter. Das tut die Software, die ich nachher installiere. Die USV meldet über das USB-Kabel nur ihren Zustand, also wie viel Strom noch auf der Batterie ist, ob Strom aus der Wand kommt und mit welcher Spannung usw. Die Software, die auf dem Server läuft entscheidet dann anhand dieser Angaben, ob und was sie dann tut.

Damit der Server aber jetzt hochgefahren werden kann, muss die USV mit dem Power-Knopf an der Front eingeschaltet werden. Es ertönt ein kurzer Ton, man kann noch ein paar mal das Knacken von Relais hören, dann ist das Gerät an. Nun kann man den Server einschalten und hochfahren.

Software-Installation

Nun muss noch die Software installiert werden, damit der Server mit der USV überhaupt etwas anfangen kann. Hierzu logge ich mich wieder über eine SSH-Verbindung auf meinem Server ein.

Um zu sehen, ob die unterbrechungsfreie Stromversorgung überhaupt vom Server erkannt wurde, gebe ich ein mal den Befehl lsusb ein. Nun wird mir eine Liste der USB-Geräte angezeigt, welche auf meinem Server vorhanden sind. Die interessante Zeile ist die hier:

Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply

Das zeigt mir, dass die USV erkannt wurde und wir damit auch was anfangen können.

Nun muss das Software-Paket installiert werden, mit dem man die USV steuert:

sudo apt-get install apcupsd

Hiermit wird das Programm und dessen Dokumentation installiert.

Nun muss der Dienst aber noch konfiguriert und gestartet werden. Dazu muss zunächst die Datei /etc/apcupsd/apcupsd.conf editiert werden:

sudo nano /etc/apcupsd/apcupsd.conf

Folgende Werte habe ich geändert. Alle nicht erwähnten Felder sind so, wie sie standardmäßig waren.

  • UPSCABLE: Standardmäßig steht hier „smart“, ich habe es zu „usb“ geändert.
  • UPSTYPE: Standardmäßig steht hier „apcsmart“, ich ändere das auf „usb“.
  • DEVICE: Diese Zeile muss auskommentiert werden, also ein Nummernzeichen „#“ muss vor die Zeile gesetzt werden.
  • POLLTIME: Gibt den Wert in Sekunden an, nach denen die USV nach ihrem Status befragt wird. Die Zeile ist auskommentiert und auf 60 Sekunden eingestellt. Hier das Nummernzeichen entfernen und den Wert auf 15 setzen. Ich erkläre später, warum.

Diese Werte sind wichtig, da die USV sonst vom Dienst nicht erkannt wird. Natürlich werden die Werte ohne Anführungsstriche eingegeben.

Nun muss noch konfiguriert werden, wann der Server heruntergefahren wird. Hier bedurfte es einiger Experimente, weil ich nicht wusste, wie schnell der Server die Akkus der USV verbraucht.

  • BATTERYLEVEL: Wenn dieser Wert in Prozent erreicht ist, wird der Server heruntergefahren. Er steht auf 5 %, das ändere ich auf 15.
  • MINUTES: Wenn die Batterielaufzeit in Minuten diesen Wert erreicht, wird der Server heruntergefahren. Hier ist bereits eingestellt, dass der Server abgeschaltet wird, wenn nur noch 3 Minuten Restlaufzeit auf der Batterie verfügbar sind.
  • NISIP: Hier ist 127.0.0.1 voreingestellt, ändert das auf 0.0.0.0. Sonst funktioniert einiges nicht richtig. Zum Beispiel funktioniert dann die Statusabfrage in einer SSH-Sitzung nicht mehr.

Bei voller Akkuladung kann die USV meinen Server etwa 30 Minuten betreiben. Das ist schon eine Menge, finde ich. Damit aber der Server rechtzeitig heruntergefahren werden kann, muss der Befehl zum Runterfahren kommen, wenn noch Genug Kapazität auf dem Akku ist. Rein rechnerisch würde also 1 Minute Laufzeit etwas um die 3 % Akkukapazität verbrauchen. Um also eine Reserve zu haben, falls die Last doch mal höher ist, habe ich die Schwelle, bei der der Befehl kommt, auf 15 % gesetzt, oder wenn der Akku früher durch hohe CPU-Last nur noch 3 Minuten Laufzeit hat.

Nun kommt noch die Polltime dazu. Die voreingestellten 60 Sekunden sind viel zu viel! Im schlimmsten Fall könnte der Befehl zu spät kommen, und der Saft ist alle, bevor alle Prozesse ordentlich beendet sind. Also stelle ich die Polltime auf 15 Sekunden ein, so dass alle 15 Sekunden der Status der USV-Akkus abgefragt wird. So stelle ich sicher, dass der Befehl kommt, wenn noch 4 bis 5 Minuten Leistung auf dem Akku sind, und nicht erst, wenn nur noch 2 Minuten Restlaufzeit da sind. Das ist mir nämlich in den ersten Tests so passiert.

Das war es für diese Datei, mit Ctrl+X speichern, fertig.

Der Dienst kann aber noch nicht gestartet werden, da er sich erst starten lässt, nachdem er konfiguriert wurde. Also müssen wir dem Dienst noch erklären, dass er nun konfiguriert ist… 🙂 Ich weiß, kompliziert, aber ist halt so. Also müssen wir noch folgende Datei editieren:

sudo nano /etc/default/apcupsd

Hier gibt es ganz unten einen Wert „ISCONFIGURED=no“. Diesen Wert müssen wir auf „yes“ setzen, so dass die Zeile so aussieht:

ISCONFIGURED=yes

Nun wieder mit Ctrl+X speichern, auch hier, fertig!

Der Dienst wird jetzt mit folgendem Befehl gestartet:

sudo service apcupsd start

Benutzung

Viel kann man jetzt gar nicht mehr machen. Der Dienst wird jetzt im Hintergrund arbeiten und schauen, was die USV meldet. Meldet sie, dass sie auf Batterie läuft, wird der Dienst das erkennen. Meldet die USV, dass nur noch 15 % oder nur noch 3 Minuten Restlaufzeit auf der Batterie sind, wird der Server heruntergefahren.

Man kann jetzt aber mal den Status abfragen. Die Ausgabe ist echt umfangreich, daher beschreibe ich mal die wichtigsten Parameter. Man ruft den Status mit:

sudo apcaccess

auf. Die Ausgabe ist, wie ich sagte, umfangreich. Daher hier mal die wichtigsten Werte. Ganz oben kommen ein paar generelle Infos über den Rechner, die Softwareversion und die Konfigurationseinstellungen, die wir früher schon gemacht haben.

  • MODEL: Back-UPS XS 700U: Nun, sagt ja schon, was es ist.
  • STATUS: ONLINE: OK, ist auch recht aussagekräftig.
  • LINEV: 238.0 Volts: Das zeigt die derzeit tatsächliche Spannung an. Das stand vorhin mal bei 232.
  • LOADPCT: 18.0 Percent: Das ist die Auslastung der USV. Da geht noch was… 🙂
  • BCHARGE: 100.0 Percent: OK, die Batterien sind voll!
  • TIMELEFT: 31.1 Minutes: So lange könnte die USV den Server betreiben.

Dann kommen viele Angaben über Firmware, Batteriedatum, Seriennummer usw. Aber das sind die paar wirklich interessanten Infos.

Benachrichtigung per Mail

Man mag sich fragen, wie die Mail gesendet werden soll, wenn doch der Strom ausgefallen ist? Tja, da mag was dran sein. 🙂 Aber für die Zukunft plane ich, auch die Fritz!Box an die USV zu hängen. Dann hätte sich dieses Problem erledigt. 🙂

Aber warum will ich überhaupt eine Mail? Naja, das ist eigentlich ganz einfach: Die USV kann den Server bei Stromausfall kontrolliert herunterfahren. Sie kann ihn aber nicht wieder starten. Wenn ich also eine Mail bekomme, vorausgesetzt, ich kriege das hin, dass die Mail auch noch rausgeht, dann weiß ich wenigstens, dass der Server runtergefahren ist. Nun kann ich später mal versuchen, mich per VPN mit meinem Heimnetz zu verbinden und per Wake on LAN den Server wieder aufzuwecken.

Der Dienst für die USV kann über 5 Zustände eine Meldung verschicken. Dies wird in 5 Skripten eingestellt, demzufolge müssen auch 5 Skripte editiert werden. Ihr könnt zwar auch den versendeten Text anpassen, wenn ihr aber mit dem Standardtext zufrieden seid wie ich, so sind es nur 2 kleine Änderungen in den Skripten, damit die Mailbenachrichtigungen funktionieren.

  • changeme: Dieses Skript informiert darüber, dass die Akkus erledigt sind und gewechselt werden möchten.
  • commfailure: Dieses Skript informiert darüber, dass die USV nicht mehr ansprechbar ist. Vielleicht ist das USB-Kabel defekt, rausgerutscht oder an der USV selbst stimmt was nicht. Das kann man dann prüfen.
  • commok: Das Skript meldet, wenn wieder alles in Ordnung mit der Kommunikation zwischen USV und Server ist. Das USB-Kabel könnte wieder eingesteckt sein? 🙂
  • onbattery und offbattery: Diese Skripte informieren darüber, wenn die USV auf Batteriebetrieb schaltet, und wenn der Strom wieder da ist, bevor die Batterie leer war.

Diese Skripte befinden sich alle in /etc/apcupsd, und können dort editiert werden. Beispielsweise könnte so ein Befehl so aussehen:

sudo nano /etc/apcupsd/onbattery

Diese Skripte sind alle gleich aufgebaut, so dass die Änderungen an allen 5 Skripten gleich sind.

Ganz oben kommen ein paar auskommentierte Zeilen. Die erste aktive Zeile ist:

HOSTNAME=`hostname`

Darunter müsst ihr die Variable SYSADMIN definieren, damit dem Skript eure Mailadresse bekannt ist.

SYSADMIN=mailadresse@beispiel.de

Die vorletzte Zeile im Skript lautet:

) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN

Ändert diese Zeile, und zwar ersetzt $APCUPSD_MAIL durch mail, so dass die Zeile so aussieht:

) | mail -s "$MSG" $SYSADMIN

Fertig! Macht das mit allen 5 Skripten, und die Mailbenachrichtigungen funktionieren.

Abfrage des USV-Status per Webbrowser

Nun, wenn man nicht zu Hause ist, ist es schwierig, zu gucken, was die USV gerade macht. Ich kann sowieso viele Statusmeldungen des Servers per Webbrowser sehen, warum also nicht auch noch die der USV? Und das ist einfacher, als ich dachte!

Man braucht eigentlich nur das Paket apcupsd-cgi zu installieren.

sudo apt-get install apcupsd-cgi

Und schon kann man per Webbrowser drauf zugreifen. In meinem Falle lautet die Adresse:

https://server01/cgi-bin/apcupsd/multimon.cgi

Das funktioniert natürlich nur aus dem lokalen Netz. Zwar ist mein Webzugriff passwortgesichert, aber sicher ist sicher, die öffentliche Adresse behalte ich mal für mich… 🙂

Ich habe mir ja eine index.html-Datei in mein WWW-Verzeichnis gelegt, wo ich diese einzelnen Programme verlinke. So brauche ich mir diese Adressen nicht alle merken. Und hier trage ich natürlich auch den Link zu dieser Applikation ein.

Zum Beispiel würde das so aussehen:

<p><a href="/cgi-bin/apcupsd/multimon.cgi">Unterbrechungsfreie Stromversorgung</a></p>

Nun kann ich diese Seite über meine Index-Seite aus aufrufen.

Hier gibt es einen Überblick über die USV. Man könnte, wenn man denn hätte, auch mehrere USVs damit überwachen, aber ich habe ja mal nur eine. In einer Tabelle sind die Geräte nun mit ihren grundlegenden Parametern aufgelistet.

Will ich jetzt also alles über die USV wissen, die an „Local Host“ angeschlossen ist, klicke ich den Link und bekomme alle Daten, die ich auch mit apcaccess bekommen würde, und noch die paar letzten Ereignisse die die USV betreffen angezeigt.

Zumindest mal mit Jaws ist das alles ziemlich gut bedienbar!

Kleiner Test

So, wollen wir mal sehen, ob das Teil auch funktioniert? Ich ziehe jetzt einfach mal den Stecker der USV aus der Wand. Damit simuliere ich einen Stromausfall!

Die USV gibt jetzt in regelmäßigen Abständen 4 Pieptöne von sich. Der Server läuft noch, aber eben auf Akku. Die USV hat dabei ein leichtes Brummen.

Nun kann ich mit apcaccess immer wieder schauen, wie der Status ist. Momentan ist der Status „ONBATT“, also auf Akku, BCharge ist bei um die 80 % und angeblich kann der Server noch 28 Minuten laufen. Nun, warten wir mal ab… 🙂

Irgendwann beginnt die USV damit, ständig kurze Pieptöne von sich zu geben, ich kann hören, dass Linux die Festplatten des RAID einzeln abschaltet und der Server geht aus.

Das ist mir bei Linux schon früher aufgefallen, dass die Festplatten nicht einfach alle gleichzeitig abgeschaltet werden, wenn die Prozesse runtergefahren sind, Linux schaltet die Platten einzeln und nacheinander ab. Daran höre ich aber, dass das Herunterfahren einwandfrei geklappt hat.

Nachdem ich den Stecker zurück in die Wand gesteckt und den Server wieder hochgefahren habe, prüfe ich den Status der USV. Da wären noch 9 % Akkukapazität übrig gewesen, also genug Luft, auch wenn das Runterfahren mal länger gedauert hätte. So etwas passiert leider gelegentlich.

Fazit

Puh, das Teil müffelt immer noch! Mit was für einer Chemikalie hat APC das Teil denn eingenebelt? Aber das geht in den nächsten Tagen hoffentlich wieder weg.

Abgesehen vom etwas strengen Geruch finde ich, tut das Teil absolut, was es soll. Überspannungsschutz, geordnetes Herunterfahren und das bitteschön ohne mein Zutun. Nur um das Wiederaufwecken muss ich mich dann kümmern. Aber das ist OK, Hauptsache es sind erst mal keine Datenverluste passiert.

Später will ich noch die Fritz!Box an die USV hängen, damit der Server im Notfall wenigstens Mails schicken kann. Vorausgesetzt natürlich, dass die Vermittlungsstelle, an der mein DSL-Anschluss hängt, nicht auch vom Stromausfall betroffen ist… 🙁 In den letzten paar Fällen war es aber immer ein hausinterner Stromausfall, wahrscheinlich wird am Stromnetz gearbeitet, ich weiß es nicht. Es war jedenfalls kein Stromausfall vom Versorger.

Für diesen doch guten Preis finde ich, sollte man sich so ein Teil gönnen, wenn man einen Server betreibt. Der Aufwand der Dateisystemreparatur, Datenintegritätsprüfung und Backupwiederherstellung steht jedenfalls in keinem Verhältnis zu einer einmaligen Ausgabe von knapp 60 €.

Hama MCE Remote in Kodi auf dem Raspberry Pi 2 einbinden

Ein Mediacenter nutzt ja erst mal nicht sehr viel, wenn man ihn nicht auch bedienen kann. Und da, wie ich finde, eine Tastatur, sei sie nun per Kabel oder drahtlos angeschlossen, nicht so toll ins Wohnzimmerbild passt, kommt natürlich nur eine Fernbedienung in Frage.

Ich habe mich für eine Hama MCE Remote entschieden, die es bei Amazon für 28,65 € gibt. Zugegeben, als ich die gekauft habe, war sie bedeutend billiger.

Es gibt zwar eine Menge Fernbedienungen, die unseren Zweck erfüllen, diese werden aber unterschiedlich eingerichtet und konfiguriert. Und die Hama MCE Remote hat durchaus einige Besonderheiten, weswegen ich diesen Text schreibe.

Hinweise

Die Anleitung gilt nur für Linux und auf Linux basierende Installationen. Diese Anleitung funktioniert bei mir mit einem Mediacenter PC mit Ubuntu und auch mit dem Raspberry Pi 2.

Auch wenn die Einrichtung erst mal sehr kompliziert erscheint, so muss man dies jedoch nur ein Mal machen. Danach hat man seine Ruhe. Und da die Fernbedienung tadellos funktioniert, würde ich diese Zeit durchaus investieren. Folgt also der Anleitung, und eure Fernbedienung sollte, wenn es zu keinen Problemen kommt, gut funktionieren.

Um euch den Einstieg leicht zu machen, findet ihr hier den Inhalt der Konfigurationsdateien komplett. Es ist zwar nicht garantiert, dass es bei euch mit genau dieser Konfiguration auch läuft, aber so habt ihr einen Einstiegspunkt, von dem aus ihr eurem persönlichen Geschmack oder euren Systemvoraussetzungen entsprechend arbeiten könnt.

In dieser Anleitung findet ihr die Beispielkonfigurationen für einen Raspberry Pi 2 mit XBIAN. Wie ihr das installieren und konfigurieren könnt, erfahrt ihr in den Podcasts 80 bis 84.

Vorbereitungen

Fahrt euren Raspberry Pi herunter und zieht das Netzkabel. Vermutlich ist das zwar nicht nötig, aber ich möchte die Anleitung gerne an einem fest definierten Startpunkt beginnen.

Schließt den USB-IR-Empfänger der Fernbedienung an den Raspberry Pi an. Merkt euch, an welche USB-Schnittstelle ihr den Empfänger anschließt. Solltet ihr den Empfänger später mal an eine andere USB-Schnittstelle des Raspberry Pi anschließen, könnte es gut sein, dass ihr die UDEV-Regel neu konfigurieren müsst, dazu aber später. Ihr erspart euch das, wenn ihr den Empfänger immer an der gleichen USB-Schnittstelle anschließt. Ich habe hierzu die untere USB-Buchse direkt neben dem Netzwerkanschluss gewählt.

Nun könnt ihr das Netzteil des Raspberry Pi wieder anschließen. Wartet nun, bis das System voll hochgefahren ist.

Software-Installation

Wenn Kodi hochgefahren ist, und ihr Tasten an der Fernbedienung drückt, passiert was. Warum also noch konfigurieren, könntet ihr Fragen? Ja, Basisfunktionen der Fernbedienung funktionieren. Manch einem mag das sogar reichen. Aber es funktionieren längst nicht alle Tasten und man möchte vielleicht manche Sonderfunktionen auf bestimmte Tasten legen. Und hier wird es erforderlich, etwas Hand anzulegen. 🙂

Übrigens, hier kommt die Anleitung her, nach der ich die Fernbedienung konfiguriert habe. Sollte euch meine kurze Beschreibung nicht reichen, so findet ihr das Ganze auch im Detail dort.

Damit die Fernbedienung nun also so läuft, wie wir das wollen, braucht’s ein Software-Paket. Das Paket lirc für Fernbedienungen ist ja schon installiert, wir brauchen aber zusätzlich noch inputlirc. Öffnet also eine Sitzung mit einem SSH-Client und meldet euch am Raspberry Pi an. Nun gebt ihr folgende Befehle ein:

sudo apt-get update
sudo apt-get install inputlirc

Lasst das Fenster ruhig offen, das brauchen wir noch einige Male zum editieren von Konfigurationsdateien.

UDEV-Regel erstellen

Damit die Fernbedienung auch immer gefunden wird, bedarf es einer UDEV-Regel. Ich könnte mir durchaus vorstellen, dass es auch einfacher geht, aber bei mir haben diverse Abkürzungen nur kurzfristig funktioniert, daher erwähne ich die gleich nicht. Dieser Weg mag komplizierter sein, er hat aber den unschlagbaren Vorteil, dass er funktioniert… 🙂

Bei einem PC, wie z. B. meinem Mediacenter-PC, mag der Vorgang umfangreicher sein, aber da wir beim Raspberry Pi doch eine sehr überschaubare Hardware haben, können wir uns diverse Schritte auch schenken. Aber wir sollten doch mal eben etwas kontrollieren.

Lasst euch doch mal den Inhalt des Verzeichnisses /dev/input anzeigen:

ls /dev/input

Hier müssten jetzt 4 Verzeichnisse sein, event0, event1, event2 und evtl. mouse0. Interessant sind für uns die drei eventx-Verzeichnisse.

Eine der Besonderheiten der Hama MCE Remote ist, dass sie tatsächlich als 2 Geräte vorhanden ist. Sie ist nämlich nicht nur Fernbedienung, sondern auch Maus. Daher verteilen sich die Tasten auf mehrere Geräte. Um nun herauszufinden, welches Gerät mit welchem event-Verzeichnis verknüpft ist, gebt ihr folgenden Befehl ein:

cat /proc/bus/input/devices

Ihr bekommt dann eine Ausgabe, die in Etwa so aussehen könnte:

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:06.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:06.0/usb4/4-1/4-1:1.0/input/input0
U: Uniq=
H: Handlers=kbd event0
B: EV=120013
B: KEY=e080ffdf01cfffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:06.0-1/input1
S: Sysfs=/devices/pci0000:00/0000:00:06.0/usb4/4-1/4-1:1.1/input/input5
U: Uniq=
H: Handlers=kbd mouse1 event1
B: EV=17
B: KEY=1f0000 2020000 3878d801d001 1e000000000000 0
B: REL=103
B: MSC=10

Das ist nur eine Beispielanzeige, die ich aus der oben genannten Anleitung rauskopiert und geringfügig angepasst habe. Der Raspberry Pi ist zur Zeit verliehen und steht mir gerade nicht zur Verfügung, weswegen ich etwas triksen musste… 🙂 Viel wichtiger ist, dass wir bei beiden Geräten in der Zeile „h: Handlers=“ sehen können, an welchen Verzeichnissen sie hängen.

Bei meinem Raspberry Pi ist das event0 und eventt1. Das Verzeichnis event2 ist mit lirc verknüpft.

Nun benötigen wir noch die Minor- und Major-Nummern beider Geräte. Das ist später für die Regeldatei nötig. Diese bekommen wir so heraus:

udevadm info -q all -n /dev/input/event0
udevadm info -q all -n /dev/input/event1

Die ganze Anzeige ist völlig belanglos, nur ganz unten findet ihr die beiden Zeilen „Major“ und „Minor“. Diese Zahlen notiert ihr euch bitte, für beide Geräte, da sie gleich für die Regeln nötig werden. In meinem Fall waren es übrigens Major 13 und Minor 64 und 65.

Nun schreiben wir eine UDEV-Regeldatei.

sudo nano /etc/udev/rules.d/10-irremote.rules

Und in diese leere Datei fügen wir folgenden Inhalt ein:

SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ATTR{dev}=="13:64",SYMLINK="input/irremote0"
SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ATTR{dev}=="13:65",SYMLINK="input/irremote1"

Vergesst nicht, die Minor-Zahl zu ändern, die hier bei 64 und 65 steht, falls dies bei euch andere Werte hat. Sonst funktioniert es nicht. Speichert die Datei nun mit Ctrl+X, so dass ihr wieder auf der Eingabeaufforderung steht.

Man könnte UDEV einfach neu starten, aber das hat bei mir nicht funktioniert, keine Ahnung, warum. Daher habe ich den Raspberry Pi komplett neu gestartet mit dem Befehl „sudo reboot“. Das dauert zwar, aber naja…

Wenn der Raspberry Pi wieder hochgefahren ist und ihr mit SSH wieder verbunden seid, lasst euch doch nochmal das Verzeichnis /dev/input anzeigen. Wenn die Regel nämlich geklappt hat, sind da jetzt zwei neue Verzeichnisse, eigentlich sind das symbolische Links: irremote0 und irremote1. Falls nicht, hat was nicht geklappt.

Editieren von Konfigurationsdateien

Ab jetzt wird es einfacher, denn nun könnt ihr getrost die Beispiele verwenden, die ich hier reinstelle. Anpassen müsst ihr da nichts mehr.

inputlirc

Zunächst muss die Datei /etc/default/inputlirc editiert werden.

sudo nano /etc/default/inputlirc

Am besten, ihr löscht den Inhalt der Datei und fügt folgenden Inhalt ein:

# Options to be passed to inputlirc.
EVENTS="/dev/input/irremote0 /dev/input/irremote1"
OPTIONS="-g -m 0 -c -r 280"

Nun noch mit Ctrl+X speichern.

lircd.conf

Damit imputlirc funktionieren kann, muss lirc umgangen werden. Öffnet also:

sudo nano /etc/lirc/lircd.conf

Hier stehen bereits einige Zeilen drin. Kommentiert diese aus. Stellt vor jede Zeile ein Nummernzeichen, #, voran. Anschließend mit Ctrl+X speichern, fertig.

custom.conf

Nun muss die Hardware für lirc konfiguriert werden:

sudo nano /etc/lirc/hardware/custom.conf

Löscht auch hier den Inhalt und fügt folgenden Inhalt ein:

# /etc/lirc/hardware/custom.conf
#
# Arguments which will be used when launching lircd
#LIRCD_ARGS=""

#Enable lircd
START_LIRCD="false"

#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD=false

#Don't start irexec, even if a good config file seems to exist.
#START_IREXEC=false

#Try to load appropriate kernel modules
LOAD_MODULES=false

# Run "lircd --driver=help" for a list of supported drivers.
#DRIVER=""
# usually /dev/lirc0 is the correct setting for systems using udev
#DEVICE=""
#MODULES=""

# Default configuration files for your hardware if any
LIRCD_CONF=""
#LIRCMD_CONF=""

Auch dies noch mit Ctrl+X speichern, fertig. Der Raspberry Pi muss mit „sudo reboot“ neu gestartet werden.

Konfiguration von Kodi

Hier gibt es zwei Dateien, die das Verhalten der Fernbedienung beeinflussen. Zum Einen haben wir eine keymap.xml und eine Lircmap.xml. Beide Dateien sorgen im Zusammenspiel dafür, dass die Fernbedienung letztlich tut, was wir von ihr wollen.

Verbindet euch nach dem Neustart des Raspberry Pi also wieder per SSH und wechselt in das Kodi-Verzeichnis, und dort in das Verzeichnis für die eigenen Einstellungen:

cd .kodi/userdata

remote.xml

Die Fernbedienung kann bestimmte Funktionen in bestimmten Fenstern unterschiedlich behandeln. So habe ich es z. B. eingestellt, dass die Taste, mit der ich das Kontextmenü öffne, im Hauptfenster die Favoritenliste öffnet. Auch eine Löschtaste, falls man mal alte TV-Aufnahmen löschen will, habe ich hinzugefügt. Damit dies aber funktioniert, braucht es eben eine keymap.

Wir stehen ja jetzt im userdata-Verzeichnis. Also müssen wir eben noch ins keymaps-Verzeichnis:

cd keymaps

Hier erstellen wir die Datei remote.xml:

nano remote.xml

Das sudo ist hier nicht nötig, weil wir jetzt ja nicht mit Admin-Rechten, sondern unseren eigenen Rechten arbeiten.

In die nun offene leere Datei fügt ihr folgenden Inhalt ein:

<keymap>
    <global>
        <remote>
            <start>ActivateWindow(shutdownmenu)</start>
            <teletext>XBMC.RunScript(service.xbmc.tts,key.ITEM_EXTRA)</teletext>
            <record>screenshot</record>
        </remote>
        <universalremote>
            <obc1>XBMC.RunScript(service.xbmc.tts,key.REPEAT)</obc1>
            <obc2>XBMC.RunScript(special://home/addons/service.xbmc.tts/enabler.py)</obc2>
            <obc3>XBMC.RunScript(service.xbmc.tts,key.STOP)</obc3>
        </universalremote>
    </global>
    <MyVideoFiles>
        <remote>
            <clear>Delete</clear>
        </remote>
    </MyVideoFiles>
    <MyMusicFiles>
        <remote>
            <clear>Delete</clear>
        </remote>
    </MyMusicFiles>
    <Home>
        <remote>
            <title>ActivateWindow(favourites)</title>
        </remote>
    </Home>
</keymap>

Nun noch mit Ctrl+X speichern und mit cd .. zurück ins userdata-Verzeichnis gehen.

Lircmap.xml

Jeder Tastendruck auf eurer Fernbedienung sendet einen Code an den Rechner. Und in der Datei Lircmap.xml legt ihr fest, welche Taste welchen Code hat. Und danach weiß Kodi, was es damit zu tun hat.

Wenn ihr auf der Eingabeaufforderung nun den Befehl irw eingebt, so seid ihr in einem Fenster, in dem ihr die Codes sehen könnt. Drückt mal z. B. auf die Play-Taste, die Ausgabe sieht dann wahrscheinlich so aus:

a4 0 KEY_PLAYPAUSE /dev/input/irremote1

Ihr wisst jetzt also, dass der Code KEY_PLAYPAUSE die Play-Taste auf dem Gerät /dev/input/irremote1 ist.

Das könntet ihr jetzt für jede einzelne Taste wiederholen, um sie in die Lircmap.xml einzutragen, aber ihr könnt auch meine Lircmap nehmen. Die ist, so finde ich, schon recht brauchbar belegt… 🙂 Übrigens, das irw-Programm beendet ihr mit Ctrl+c.

Ihr seid ja jetzt im userdata-Verzeichnis, also öffnet ihr:

nano Lircmap.xml

Und in die leere Datei fügt ihr folgenden Inhalt ein:

<lircmap>
    <remote device="/dev/input/irremote1">
        <power>KEY_SLEEP</power>
        <play>KEY_PLAYPAUSE</play>
        <stop>KEY_STOPCD</stop>
        <menu>BTN_MOUSE</menu>
        <title>BTN_RIGHT</title>
        <skipplus>KEY_NEXTSONG</skipplus>
        <skipminus>KEY_PREVIOUSSONG</skipminus>
        <start>KEY_HOMEPAGE</start>
        <volumeplus>KEY_VOLUMEUP</volumeplus>
        <volumeminus>KEY_VOLUMEDOWN</volumeminus>
        <mute>KEY_MUTE</mute>
    </remote>
    <remote device="/dev/input/irremote0">  
        <record>CTRL_KEY_R</record>
        <reverse>CTRL_SHIFT_KEY_B</reverse>
        <forward>CTRL_SHIFT_KEY_F</forward>
        <left>KEY_LEFT</left>
        <right>KEY_RIGHT</right>
        <up>KEY_UP</up>
        <down>KEY_DOWN</down>
        <select>KEY_ENTER</select>
        <pageplus>KEY_PAGEUP</pageplus>
        <pageminus>KEY_PAGEDOWN</pageminus>
        <back>KEY_BACKSPACE</back>
        <info>ALT_META_KEY_ENTER</info>
        <display>KEY_ESC</display>
        <myvideo>CTRL_KEY_E</myvideo>
        <mymusic>CTRL_KEY_M</mymusic>
        <mypictures>CTRL_KEY_I</mypictures>
        <mytv>CTRL_SHIFT_KEY_T</mytv>
        <one>KEY_KP1</one>
        <two>KEY_KP2</two>
        <three>KEY_KP3</three>
        <four>KEY_KP4</four>
        <five>KEY_KP5</five>
        <six>KEY_KP6</six>
        <seven>KEY_KP7</seven>
        <eight>KEY_KP8</eight>
        <nine>KEY_KP9</nine>
        <zero>KEY_KP0</zero>
        <star>KEY_KPASTERISK</star>
        <hash>ALT_KEY_KP5</hash>
        <clear>CTRL_KEY_O</clear>
        <teletext>CTRL_KEY_G</teletext>
        <obc1>CTRL_KEY_T</obc1>
        <obc3>CTRL_SHIFT_KEY_M</obc3>
        <obc2>ALT_KEY_F4</obc2>
    </remote>
</lircmap>

Nun noch mit Ctrl+X speichern und den Raspberry Pi ein letztes Mal mit „sudo reboot“ neu starten.

Besonderheiten der Tastenbelegung

Die Fernbedienung ist korrekt belegt, mit ein paar Besonderheiten, auf die ich mal ganz kurz eingehen möchte, da sie sich vielleicht nicht von selbst erschließen. Ich werde jetzt nicht auf die ganze Fernbedienung eingehen, nur auf die Besonderheiten, die sich durch meine Tastenbelegung ergeben.

Ganz oben sind ja zwei einsame Tasten. Die rechte davon ist Power, und schaltet den Raspberry Pi ab, bzw. fährt ihn runter. Die linke taste öffnet ein Abschaltmenü, wo man auch einen Neustart auswählen kann.

Darunter kommen die Farbtasten, von links nach rechts: TV, Audio, Bilder, Video. So kann man schnell in die jeweiligen Bereiche springen.

Darunter kommt eine Reihe, die so belegt ist, dass man von der Beschriftung der Tasten nicht auf deren Funktion schließen kann. Auch wieder von links nach rechts:

  • Löschen: Löscht Aufnahmen im TV-Bereich oder auch Dateien in Videos oder Audios.
  • Extras vorlesen: Wenn ihr auf einem Film steht, der in eurer Datenbank ist, so liest dieser Tastendruck die Filmbeschreibung vor. Im EPG liest es die EPG-Daten vor.
  • Fenster vorlesen: Liest Fenstertitel und evtl. wie viele Elemente in diesem Fenster sind.
  • Ruhe: Unterbricht die Sprachausgabe.

Das Cursor-Kreuz ist ja klar, aber hier mal kurz die Beschreibung der 4 Tasten um das Kreuz herum:

  • Linke obere ecke: Eine ebene Zurück, um z. B. in das darüberliegende Verzeichnis zu wechseln. Bei Texteingaben ist das auch die Rücktaste.
  • Linke untere Ecke: Schließt die Texteingabe ohne zu bestätigen, wechselt ins Hauptmenü oder beendet die Ansicht für Videos oder Audios oder dergleichen. Bei laufender Wiedergabe bringt diese Taste euch in das OSD-Menü.
  • Beide Tasten rechts vom Cursor-Kreuz: Öffnen überall das Kontextmenü, außer im Hauptmenü, dort öffnet es die Favoritenansicht.

Die beiden rechten Tasten senden den gleichen Code, daher konnte ich sie nicht unterschiedlich belegen.

Unter dem Cursor-Kreuz kommt so ein rundes Pad, das ist die Maussteuerung und ist nutzlos, weil auch nicht konfiguriert. Aber darunter wird es noch mal interessant:

Links sind zwei Tasten übereinander, das ist oben laut und unten leise. In der Mitte ist eine kleine Taste, das ist Stumm, und darunter eine querliegende längliche dicke Taste, das ist die Info-Taste. Damit zeigt ihr z. B. die Datenbank-Infos an oder könnt bei laufenden Sendungen oder Audios Details zum gerade abgespielten Track anzeigen. Rechts sind wieder zwei Tasten übereinander, das ist Page up und Page down.

Darunter kommt die Zifferntastatur, damit gibt man auch im SMS-Stil Text ein. In Listen kann man so auch per Anfangsbuchstabe springen.

Ganz unten sind noch zwei Tasten, die von Bedeutung sind: Ganz links unten schaltet den Kodi Screen Reader aus und ein. Die mittlere Taste blendet bei laufendem Video die Benutzeroberfläche ein und aus. Und ganz rechts ist eine zweite Enter-Taste, die sendet auch den gleichen Code wie die OK-Taste in der Mitte des Cursor-Kreuzes.

Fazit

Ich kann und will nicht garantieren, dass meine Konfigurationsbeispiele so bei euch funktionieren oder euren Geschmack treffen. Vor allem ist wirklich viel Aufmerksamkeit bei der Ermittlung der Minor- und Major-Nummern gefragt. Wenn UDEV die Fernbedienung nicht finden kann, funktioniert keines meiner Konfigurationsbeispiele.

Wenn es denn aber mal läuft, braucht ihr euch darum nicht mehr zu kümmern. Bislang laufen drei Kodi-Installationen, die ich mit dieser Fernbedienung eingerichtet habe, seit mehr als 2 Jahren problemlos. Vor allem, wenn man sich an die Belegung mal gewöhnt hat, ist es sehr bequem, alles in einer Hand steuern zu können. Auch wenn die Einrichtung kompliziert ist, es hat sich definitiv gelohnt!

Podcast Nr. 84: Kodi Mediacenter auf einem Raspberry Pi 2 – Teil 5

In diesem Podcast beschreibe ich ein Problem, welches im Zusammenhang mit dem Kodi Screen Reader auftreten kann. Will man eine Quelle abspielen, die Dolby Digital oder DTS Passthrough benutzen will, und der Screen Reader möchte erzählen, was er da abspielt, kann es zu Konflikten kommen.

Weiterhin beschreibe ich, wie ihr Quellen zu Kodi hinzufügt, wie man Filme in die Datenbank einträgt und was die Datenbank so alles an Infos über den Film rausrückt.

Noch eine kleine Anmerkung zu den abgehackten Ansagen des Kodi Screen Readers: In den Einstellungen zu dem Screen Reader gibt es einen Punkt, „Audiowiedergabe durch Player durchleiten“. Diese muss eingeschaltet werden. Das behebt zwar das Problem nicht völlig, vermindert es aber deutlich. Ich experimentiere weiter, vielleicht finde ich eine Lösung, das Problem gänzlich zu beseitigen.

Download

 

Podcast Nr. 83: Kodi Mediacenter auf einem Raspberry Pi 2 – Teil 4

In diesem Podcast gehe ich mehr auf die Einstellmöglichkeiten innerhalb von Kodi ein. Ich erkläre auch, was für Einschränkungen im Bereich der HD-Tonformate beim Raspberry Pi 2 zu erwarten sind. Außerdem zeige ich auch das XBIAN-Konfigurationstool unter Kodi.

Im Podcast erkläre ich, dass die Alsa-Utils installiert werden müssen, damit man im Kodi Screen Reader aplay als Player auswählen kann. In einem SSH-Terminal ist dafür folgender Befehl einzugeben:

sudo apt-get install alsa-utils

Die Lizenzschlüssel für die Hardwaredekodierung von MPEG2 und VC-1 könnt ihr im Raspberry Pi Store kaufen. Der Schlüssel für MPEG2 kostet £2,40 und der für VC-1 kostet £1,20. Insgesamt habe ich also £3,60 ausgegeben, das waren zum Zeitpunkt des Kaufs 5,19 €.

Download

 

Podcast Nr. 82: Kodi Mediacenter auf einem Raspberry Pi 2 – Teil 3

In diesem Podcast schließe ich meinen Raspberry an und starte ihn zum ersten mal. Anschließend werden für Kodi noch Pakete nachinstalliert, die Grundkonfiguration der Grafik gemacht und der Kodi Screen Reader installiert.

Damit es zu keinen Fehlern bei den Befehlen kommt, die verwendet wurden, gibt es hier mal eine Liste der Befehle, die im Podcast verwendet wurden.

Kleiner Hinweis: Die Befehle, die Administratorrechte benötigen, bekommen ein „sudo“ vorangestellt. Gibt man so einen Befehl zum ersten mal ein, wird das sudo-Passwort benötigt, dann, für eine gewisse Zeit, nicht mehr. Ich bin mir nicht ganz sicher, aber ich meine, es wären 15 Minuten.

Verbindet man sich per SSH mit dem Raspberry Pi 2, so ist bei XBIAN der Benutzername standardmäßig xbian und das Passwort raspberry.

Hier die Befehlsliste:

  • sudo apt-get update: Dies aktualisiert die Daten aus den Paket-Repositories.
  • sudo apt-get upgrade: Dies installiert evtl. vorhandene neuere Versionen. Der apt-get update Befehl sollte immer vorher ausgeführt werden, da sonst nicht bekannt ist, ob es neuere Versionen gibt.
  • sudo apt-get install xxx: Dies installiert Pakete, wobei xxx für den Paketnamen steht. Zum Beispiel sudo apt-get install espeak.
  • apt-cache search xxx: Dies durchsucht Paketquellen, wobei xxx für einen Paketnamen oder sonst für einen Suchbegriff stehen kann.

Um euch per SSH mit dem Raspberry Pi verbinden zu können, benötigt ihr einen SSH-Client. Da gäbe es PUTTY, der mit Jaws z. B. so leidlich funktioniert. Ich persönlich verwende Cygwin, dessen Installation etwas komplexer ist, aber wenn ihr das nur selten braucht, empfehle ich euch Putty, weil dieser keine Installation benötigt.

PUTTY gibt es hier.

CYGWIN gibt es hier.

Detaillierte Informationen über Kodi, Zugang zum Kodi Forum oder zum Kodi Wiki gibt es über die Homepage von Kodi. Detaillierte Informationen zu XBIAN, Zugang zum Forum und dessen Wiki gibt es auf der XBIAN-Homepage.

Download

 

Podcast Nr. 81: Kodi Mediacenter auf einem Raspberry Pi 2 – Teil 2

In diesem Podcast packe ich den Raspberry Pi 2 aus, installiere ihn in sein neues Gehäuse und bereite die SD-Karte für den Einsatz als Mediacenter vor. Hierzu lade ich ein Image von der XBIAN Website herunter.

[Update] – Im ursprünglichen Text habe ich vergessen anzugeben, was ich genau bestellt habe. Ihr könnt jeden Online-Händler nutzen, der euch genehm ist, ich habe die Teile bei Amazon gekauft.

Folgende Teile wurden hier im Podcast verwendet:

Raspberry Pi 2 Modell B Preis: 38,50 €

Aukru 3er Set kit Raspberry Pi 2 Gehäuse/Case transparent + Netzteil 5V 2000mA Micro usb + Kühlkörper Für Raspberry Pi 2 Model B Preis: 13,99 €

SanDisk Ultra Android 8GB microSDHC UHS-I Class 10 Speicherkarte + SD-Adapter bis zu 48MB/s lesen Preis: 6,99 €

Preise können sich evtl. ändern, das sind die Preise, die ich zum Zeitpunkt des Kaufs bezahlt habe.

Download

 

Podcast Nr. 80: Kodi Mediacenter auf einem Raspberry Pi 2 – Teil 1

Stromsparend, leise und vor allem günstig soll er sein. Der Raspberry Pi 2 Model B hat auch genug Leistung, um nicht nur Kodi Mediacenter zu betreiben, sondern auch den Kodi Screen Reader, den wir als Blinde brauchen, um Kodi bedienen zu können.

In diesem Podcast beschreibe ich, wie Kodi funktioniert, führe das an einer vorhandenen Installation auf meinem Mediacenter-PC vor und wo hin ich mit der Raspberry-Pi-Installation hin möchte. Hier kann man schon mal einen guten Eindruck davon bekommen, wie der Kodi Screen Reader funktioniert.

Download

 

Podcast Nr. 79: Fernsehen mit Eye-TV am Mac

Sascha Furtner stellt in diesem Podcast das Eye-TV Go von Elgato vor. Damit ein DVB-T-Empfang überhaupt möglich ist, beschreibt er auch eine aktive Zimmerantenne. Und, damit letztlich auch TV geguckt werden kann, muss natürlich die Eye-TV-Software am Mac konfiguriert werden.

Download

 

Podcast Nr. 78: Updaten und erkunden des Samsung Galaxy S5

Nun, da unser Galaxy S5 eingerichtet ist, will ich in diesem Podcast einmal das Gerät etwas erkunden. Zunächst schauen wir uns die Playstore-App und die App-Updates an, erkunden den Startbildschirm und fügen Anwendungen dem Bildschirm hinzu.

Download

 

Technik und Kommunikation für Sehbehinderte und Blinde