Zunächst habe ich entdeckt, dass die meisten OTP-Apps die Möglichkeit bieten, das OTP in die Zwischenablage zu kopieren. Also habe ich die erste Aktion „Gib den Zugangscode ein“ ersetzt durch „Zwischenablage abrufen“ und dann in die nächste Aktion durch „Variable sOTP auf Zwischenablage festlegen“ ersetzt. Das spart dann zumindest mal einen Schritt.
Und danach dachte ich mir: Vielleicht gibt es eine Shortcut-fähige OTP App, die dann in der Lage ist, per Siri Shortcut einen Code direkt in die Zwischenablage zu kopieren. Und siehe da: Die gibt es tatsächlich.
Mehr Infos zur App auch auf der Webseite von Roland Moers hier: https://cooperrs.de/otpauth.htmlhttps://cooperrs.de/otpauth.html
Nun sieht der erste Teil meines Kurzbefehls so aus:
Und damit brauche ich außer dem Aufruf des Shortcuts keine weitere Interaktion mehr mit meinem iPhone. Und das coolste war das Gesicht der Personen, die mich vor der Tür stehend haben sagen hören „Hey Siri, Tür öffnen“. Der Blick: Unbezahlbar!
P.S.: Die 4,49 € für die Pro Version von OTP Auth habe ich gerne bezahlt auch wenn ich die eigentlich nicht gebraucht hätte. Danke Roland.
Kurzer Disclaimer vorweg: Alles was ihr jetzt lest und ggf. nachmacht, macht ihr auf eigene Gefahr. Die hier vorgestellte Lösung ist dazu geeignet, dass ihr den Inhalt eueres Hauses verlieren könnt. Wenn ihr irgendetwas davon nachmachen wollt, solltet ihr sicher sein, dass das was ihr hier lest, auch komplett verstanden und von euch nachvollzogen werden kann. Ich hab‘ euch jedenfalls gewarnt!
Was wird benötigt, um das ganze zu verstehen?
Fundierte FHEM-Kenntnisse
Eine gegenüber dem Internet abgeschottete FHEMWEB-Instanz
FHEM kann aus dem Internet über DynDNS erreicht werden
Ein iOS Gerät mit der Kurzbefehle-App und Kenntnisse, wie man einen Siri-Shortcut erstellt
Programmierkenntnisse in der Arduino-IDE (oder vergleichbaren Lösungen)
Einen MQTT-Broker und Kenntnisse, wie das MQTT Protokoll funktioniert
Einen WeMos D1 Mini und ein wenig Verständnis, wie der funktioniert
Ein kleines SG90 Servo (zumindest in meinem speziellen Fall, aber dazu später)
Ein wenig „vorhandene“ Hardware z.B. Breadbord, Jumperwires usw. was man als Maker so eben braucht
So und jetzt geht’s los.
Seit einigen Jahren setze ich FHEM zur Hausautomatisierung ein. Seit den ersten Tagen habe ich eine Möglichkeit gesucht, über FHEM meine Haustür öffnen zu können. Und das möglichst charmant und natürlich auch sicher. Die Haustür hat einen elektrischen Türöffner, der über ein GIRA Steuergerät Audio 1287 00 und entsprechende Türsprechstellen bzw. Wohnungsstationen ausgelöst werden kann.
Leider gab es hier immer zwei kleinere Hürden zu überwinden:
Das Steuergerät von GIRA wird über ein Bus-System gesteuert, zu dem es – zumindest für mich – keine Protokollbeschreibungen gibt. Außerdem kann ich an den Wohnungsstationen nur dann die „Tür öffnen-Taste“ bedienen, wenn vorher jemand an der Türstation geklingelt hat… Irgendwie in diese vorhandenen Geräte einzugreifen und über Relais, Optokoppler oder sonstwas die Tür zu öffnen und dabei das komplette „System“ zu gefährden, kam also nicht in Frage.
Die zweite Hürde war, das ganze irgendwie gegen Missbrauch abzusichern. Natürlich kann man in FHEM Befehle ja über einen URL-Aufruf per http im Browser ausführen. Aber FHEM ungesichert aus dem Internet erreichbar zu machen? No way! Die Instanz mit einem Benutzer und einem komplexen Passwort abzusichern? Schon besser. HTTPS verwenden über einen Reverse-Proxy und let’s encrypt Zertifikaten? Wir kommen dem Ziel schon näher.
Doch zunächst zur ersten Hürde zurück. Zum Glück gibt’s von dem Steuergerät eine Bedienungsanleitung in der folgendes steht:
Die Taste „Türöffnerprogr.“ hat zwei Funktionen:
Türöffner-Programmiermodus einschalten: Wird die Taste „Türöffnerprogr.“ für 3 s gedrückt, während sich das System im Programmiermodus befindet, wird der Türöffner-Programmiermodus aktiviert … blablabla
Betätigung des angeschlossenen Türöffners. Durch kurzes Drücken der Taste „Türöffnerprogr.“ wird der Türöffner für die eingestellte Zeit (Türöffnerzeit) aktiviert…
Aha! Der zweite Punkt lässt sich also mit ein wenig Hardware lösen: Ein kleines Servo gesteuert von einem WeMos D1 mini sollte doch diese kleine Taste betätigen können. Und der WeMos wäre ja auch nicht der erste, der sich im Schaltschrank befindet. Ein wenig Recherche im Netz und der Code für die Servosteuerung über MQTT war fertig:
/*
Wifi, MQTT und Servo
*/
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <Servo.h>
Servo myservo;
// Update these with values suitable for your network.
const char* ssid = "SSID";
const char* password = "WLANPASSWORT";
const char* mqtt_server = "MQTTBROKER"; // MQTT IP oder DNS-Name
const char* servo_topic = "/servo/cmd"; // Topic braucht ihr später noch in FHEM
WiFiClient espClient;
PubSubClient client(espClient);
long lastMsg = 0;
char msg[50];
int value = 0;
void setup() {
Serial.begin(115200);
myservo.attach(2);
myservo.write(value);
setup_wifi();
client.setServer(mqtt_server, 1883);
client.setCallback(callback);
}
void setup_wifi() {
delay(10);
// We start by connecting to a WiFi network
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
}
void callback(char* topic, byte* payload, unsigned int length) {
String string;
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i = 0; i < length; i++) {
// Serial.print((char)payload[i]);
string+=((char)payload[i]);
}
Serial.print(string);
if (strcmp(topic, servo_topic) == 0)
Serial.print(" ");
int resultado = string.toInt();
int pos = resultado;
Serial.println(pos);
myservo.write(pos);
delay(300);
myservo.write(0);
}
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
Serial.print("Attempting MQTT connection...");
// Attempt to connect
if (client.connect("ESP8266Client")) {
Serial.println("connected");
client.subscribe(servo_topic);
} else {
Serial.print("failed, rc=");
Serial.print(client.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
}
void loop() {
if (!client.connected()) {
reconnect();
}
client.loop();
delay(100);
}
In den markierten Zeilen noch die eigenen Daten eintragen SSID, WLAN-Passwort, MQTT-Broker und Topic und ab damit auf den WeMos. Kleine Anmerkung: Der Code ist quick and dirty zusammengeschustert. Hier fehlt noch z.B. WifiManager mit eigenen Parametern verwenden, Servo-Status publishen, Telemetrie-Daten des WeMos per MQTT publishen, LWT festlegen, Serial-Output mit debug-flag ein- und ausschaltbar machen usw. Ihr könnt gerne mithelfen 😉
Eine Sache im Code ist ganz wichtig: Bevor irgendeine Ausgabe auf der seriellen Schnittstelle erfolgt, muss das Servo initialisiert werden und auf seine 0-Stellung gesetzt werden. Wenn im Setup schon serial.print Befehle drin sind, dann spinnt das Servo. Wenn es dann in seiner Position ist, kann es sich auch mal weiter drehen, als notwendig, und dann ggf. doch die Taste evtl. zu lange drücken oder sich in die falsche Richtung drehen und mit dem Hebel am Steuergerät hängen bleiben. Was dann mit dem WeMos passiert? K.P.!
Für die Schaltung mache ich kein Fritzing auf. Mein Servo hat ein rotes, ein braunes und ein orangenes Kabel. Rot kommt am WeMos an 3,3V (oder 5V), braun an GND und orange an D4 (daher im code oben myservo.attach(2) – PIN2 ist D4 auf dem WeMos).
WeMos auf Breadboard im Multimedia-Feld im Schaltschrank
Das Servo wird nun an geeigneter Position auf dem Steuergerät befestigt:
ob es tatsächlich so schlau war, die grüne, dauerleuchtende Status LED des Steuergerätes mit dem Servo zu überkleben, werden wir in ein paar Wochen sehen…
Weiter geht es mit der zweiten Hürde: Absicherung der Lösung und Integration in FHEM.
Halten wir folgendes fest: FHEM ist aus dem Internet über https mit einem gültigen Zertifikat und einer definierten URL über DynDNS erreichbar und mit Benutzer und Passwort abgesichert, am besten noch mit einer eigenen FHEMWEB-Instanz. Stimmt’s? Wenn nicht: Sorry, aber das sind Basics, die müsst ihr euch anderweitig erarbeiten. Alles andere wäre jetzt grob fahrlässig und dann bitte die folgenden Schritte nicht nachmachen. Schreibt mir ggf. eine Mail und ich schicke euch Links dazu, die ich für meine FHEM-Installation genutzt habe, um diese Anforderungen zu erfüllen.
Die Überschrift sagt ja was von OTP und Siri-Shortcuts. Also kümmern wir uns zunächst mal um OTP: Ein „Einmalkennwort“.
Weitere Infos dazu hier bei Matthias Kleine auf YouTube
Damit hat man dann eine zusätzlich Funktion in FHEM, um über eine Authenticator-App auf dem Smartphone ein OTP zu generieren und dieses in FHEM auf Gültigkeit zu prüfen.
Um jetzt FHEM „von Außen“ das OTP zu übergeben, legen wir mal ein Dummy-Device an:
Also alles etwas komplizierter, aber ihr seid ja Experten (sonst wäret ihr gar nicht hier).
Also, nachdem wir es nun erfolgreich geschafft haben über eine URL das Reading „AuthCode“ im Device „gAuthTest“ zu setzen, legen wir uns noch ein Notify an, welches überprüft, ob das ein gültiges OTP war:
Hier habe ich jetzt etwas vorgegriffen. Der set-Befehl im Notify funktioniert natürlich noch nicht, weil das Device DoorServo nicht existiert. Also holen wir das schnell nach;
Hier könntest Du jetzt einen Test machen, um alles in FHEM und auf dem WeMos programmierte zu prüfen, in dem Du einfach mal z.B. im Browser versuchst das Reading AuthCode im Device AuthTest zu setzen. Wenn Du das OTP korrekt in der URL eingegeben hast, dann sollte sich das Servo nun kurz um 25° bewegen und dann wieder auf die 0-Stellung zurückfallen. Wenn das OTP nicht passt, dann passiert einfach gar nix.(Und hier erwarte ich eine Menge Feedback, weil das so einfach nicht ist. Stichworte: URL mit BasicAuth aufrufen, URL codieren, csrf-Token korrekt angeben usw. Aber: Das muss verstanden werden und funktionieren, sonst geht’s hier nicht weiter. Fragen? Gerne per Mail.)
Also weiter gemäß der Überschrift im Beitrag. OTP ist also geklärt nun kommt Siri dran.
Ich meine, seit iOS 11 gibt es die Siri-Shortcuts und mittlerweile auch die „Kurzbefehle-App“ auf iPhones und iPads. Wer sich etwas mit den Apple Betriebssystemen auskennt, weiß vielleicht, dass es in Betriebssystemen von Apple immer eine Möglichkeit der IAC=“Inter Application Communication“ gegeben hat. Auf dem Mac gab es schon in den 90er’n AppleScript. Ich behaupte, dass viele Betriebe, die sich in den 90er’n hin zu Multimedia-Betrieben entwickelt haben, ohne AppleScript nicht überlebt hätten. Über AppleScript konnten Programme untereinander und mit dem Betriebssystem interagieren. Und das noch über eine „lesbare“ Programmiersprache. Die Weiterentwicklung war dann in Mac OS X der „Automator“ und als letztendliche Konsequenz kam dann diese Funktionalität auch mit den Siri-Shortcuts bzw. der Kurzbefehle-App auf Apple’s mobiles Betriebssystem iOS. (Sorry für den Exkurs, aber das war, ist und bleibt ein Grund für mich, Apple-Systeme zu nutzen. Ich stehe einfach auf IAC 😉 )
Und all das hilft uns jetzt, das „Problem“ zu lösen!
Wie wäre es, wenn man folgendes tun könnte:
„Hey Siri, Tür öffnen“
Siri antwortet mit „Gib den Zugangscode ein“
„123456“ zu Siri zu sprechen und die Tür geht auf
Und genau das machen wir jetzt abschließend zu dem Beitrag.
Anmerkung: Es ist leider nicht ganz so einfach, den Siri-Shortcut in Form von Text zu exportieren. Aufgrund der verwendeten Zugangsdaten zu FHEM werde ich diesen Kurzbefehl hier nicht zum Download anbieten. Daher werde ich Text und Bild verwenden, um euch den Kurzbefehl zu erklären.
Zunächst aktivieren wir in den Einstellungen des iOS Devices für die Kurzbefehle-App die Option „Nicht vertrauensw. erlauben“ (ob das wirklich notwendig ist, muss ich noch recherchieren, aber wir machen das jetzt einfach mal).
Wir starten mit dem Aufruf der Kurzbefehle-App, gehen auf „Meine Kurzbefehle“ und wählen „Kurzbefehl erstellen“ aus. Den Kurzbefehlnamen nennen wir „Tür öffnen“. Damit geht schon mal „Hey Siri, Tür öffnen“. Als erste Aktion fügen wir „Nach Eingabe Fragen“ ein und definieren die Frage „Gib den Zugangscode ein“. Eingabetyp ist „Text“ (weil das OTP auch mit einer Null beginnen kann).
Die Nächste Aktion ist „Variable konfigurieren“. Diese nennen wir „sOTP“ und setzen sie auf „Eingabe breitgestellt“ fest.
Die nächste Aktion ist „Text“. Hier geben wir die externe FHEM-URL ein und (leider) zwar mit der Angabe von Username und Passwort (Wenn jemand da eine andere Möglichkeit kennt: Her damit!) Also lautet die URL dann beispielsweise so:
https://username:passwort@meine.fhem.instanz
Als nächstes brauchen wir eine neue Aktion „zu Variable hinzufügen“ Und zwar fügen wir den Text zu sBaseURL hinzu.
Dann brauchen wir noch eine „Text“-Aktion. Diese enthält den FHEM-Befehl und wird ergänzt mit der Variable sOTP.
Dann brauchen wir eine URL Codieren Aktion (wie immer am besten die Suche verwenden, damit man diese Aktionen schnell finden kann). Mit dieser Aktion codieren wir den Text, damit Leerzeichen etc. entsprechend ersetzt werden.
Die dann folgende Aktion ist „Variable konfigurieren“. Hier legen wir die Variable sCMD auf den Text der codierten URL fest. Die Schritte sehen dann so aus:
So, jetzt kommt ein „tricky-part“. FHEM bzw. FHEMWEB hat seit einiger Zeut ja einen Schutzmechanismus gegen Cross-Site-Scripting-Attacks eingebaut. Das ganze wird über das csrf-Token geregelt. Und genau das holen wir uns jetzt mit den nächsten 3 Aktionen.
Die erste davon ist „Header von URL abrufen“. Hier bauen wir uns die URL wie folgt zusammen: sBaseURL/fhem?XHR=1
Die nächste Aktion ist „Wörterbuchwert abrufen“. Damit holen wir uns letztendlich aus einem named-array einen bestimmten Wert (Was für eine blöde Übersetzung). Und zwar den Wert für X-FHEM-csrfToken in Header von URL abrufen.
Die dritte Aktion, die wir jetzt brauchen ist wieder eine „Variable konfigurieren“ und zwar sCSRF auf Wörterbuchwert festlegen. Das sieht dann im Detail so aus:
wer findet den Schreibfehler?
Und zu guter Letzt rufen wir eine Aktion „Inhalte von URL abrufen auf“ und bauen darin die URL mit den einzelnen Variablen zusammen:
CSRF <> CSFR 😉
Fertig? Leider noch nicht so ganz. Beim Testen ist mir ein Eintrag im FHEM-Log aufgefallen, der wohl kein großes Problem verursacht, aber Einträge in Logfiles, die sich nicht so einfach erklären lassen, sind per se verdächtig. Es handelte sich um z.B. diese Zeile im log:
2020.05.22 20:46:50 3: WEB_192.168.xxx.xxx_12345: unsupported HTTP method HEAD, rejecting it.
Das konnte ich durch Setzen eines Attributes in der FHEMWEB-Instanz eliminieren.
Hier möchte ich euch mal mitteilen, wie ich meine Multimedia-Anlage dazu bringe, sich komplett ab- bzw. wieder einzuschalten, je nachdem, welche Aktivität in der Harmony gerade läuft oder eben nicht mehr läuft.
>>Kritik-Mode-ON<< Wie immer gibt es leider im fhem-wiki dazu nur uralt-Beiträge und auch das Forum ist nur bedingt hilfreich, weil man sich durch etliche Beiträge durchkämpfen muss, bevor man etwas brauchbares findet. >>Kritik-Mode-Off<<
Wie im Titel erwähnt, handelt es sich um einen Beitrag zur Hausautomatisierungssoftware „fhem“. Daher sind alle Befehle, die in diesem Beitrag stehen, fhem-spezifisch und es wird vorausgesetzt, dass beim Weiterlesen fhem-spezifische Begriffe (Device, DoIf, Readings etc…) verstanden werden. Das Prinzip kann aber sicherlich auf andere Hausautomatisierungssysteme übertragen werden.
Nun zum Thema.
Mein Hardware-Setup sieht folgendermaßen aus:
RaspberryPi 3 für fhem
Sonoff Pow (mit Tasmota)
Amazon Dash Button
Logitech Harmony Hub
Philips Ambilight TV
Onkyo-Receiver
Magnat Surround-Boxen (mit aktivem Subwoofer)
Lässt man mal den RaspberryPi und den Sonoff Pow weg, komme ich auf einen Stromverbrauch von etwa 160 W wenn der TV, der Receiver und der Subwoofer eingeschaltet sind. Im Standby verbrauchen diese etwa 52 W(!). Das liegt zum größten Teil am Onkyo und dem Subwoofer.
Also liegt es nahe, den Stromverbrauch auf ca. 0 W zu senken, wenn die Multimedia-Anlage nicht in Betrieb ist.
Voraussetzung im Harmony Hub
Ein zusätzliches dummy Gerät beliebiger Art ist angelegt (gebt einfach als Hersteller „dummy“ und als Modellnummer „dummy“ ein und legt das Gerät dann an. Hauptsächlich es kennt die Befehle „PowerOn“ und „PowerOff“).
Dem Gerät eine Einschaltverzögerung von ca. 15 sec. geben.
Die Betriebseinstellung für dieses Gerät auf „Immer eingeschaltet lassen“ stellen
In der Sequenz „Befehle für Aktionsstart“ aller Aktivitäten, dieses Gerät als erstes hinzufügen mit dem Befehl „Power On“
In der Sequenz „Befehle für Aktionsende“ aller Aktivitäten, dieses Gerät als letztes hinzufügen mit dem dem Befehl „Power Off“
Voraussetzung in fhem
harmony device (in meinem Fall „WZ.Harmony“ genannt)
Tasmota_Device (von Matthias Kleine) device (in meinem Fall „WZ.Multimedia“ genannt)
dash_dhcp Device für den Amazon dash_button (in meinem Fall „DashButton“ genannt)
Nun kann folgendes DoIf in fhem angelegt werden
([WZ.Harmony:currentActivity] eq "PowerOff" ) (sleep 20; set WZ.Multimedia OFF)
DOELSEIF
([WZ.Harmony:currentActivity] ne "PowerOff" ) (set WZ.Multimedia ON)
Attribute, wie „do always“ etc. bitte weglassen!
Kurze Erklärung: Immer dann, wenn das Reading „currentActivity“ des Devices „WZ.Harmony“ den Wert „PowerOff“ bekommt, dann wartet fhem 20 Sekunden und sendet dann den Befehl „OFF“ an das Device „WZ.Multimedia“. Das gibt den an der Aktivität beteiligten Geräten genug Zeit, sich vernünftig in den StandBy-Betrieb zu schalten. Wenn das Reading „currentActivity“ nicht „PowerOff“ ist, dann wird direkt ein „ON“ an das Device „WZ.Multimedia“ gesendet. Die im Harmony-Gerät „Sonoff“ definierte Einschaltverzögerung, gibt den an der Aktivität beteiligten Geräten genug „Vorlaufzeit“, um auf den eigentlichen Einschaltbefehl in der Startsequenz reagieren zu können. Der Onkyo und der Philips TV brauchen halt eine gewisse Zeit, bis Sie auf Befehle des Harmony Hubs reagieren, nachdem Sie mit Strom versorgt werden.
Mit der Einschaltverzögerung und dem sleep-Wert im DoIf kann man sicher noch experimentieren.
Und wie spare ich nun Strom?
Erstmal reduziert sich der Stromverbrauch um etwa 50 W, wenn der Harmony Hub die Aktivität „PowerOff“ ausführt. Zudem schlafe ich sehr gerne vor der Glotze ein und dann wache ich morgens auf und die komplette Nacht hindurch hat die Anlage Strom verbraucht 🙁
Und jetzt kommt der DashButton ins Spiel:
Folgendes zusätzliches DoIf sorgt dafür, dass der Sleeptimer im Harmony Hub gesetzt wird, wenn ich den DashButton drücke:
Wichtig hierbei ist, dass im DoIf das Attribut „do“ auf „always“ gesetzt wird. Nur damit wird erreicht, dass bei einem erneuten Drücken des DashButtons, der Sleeptimer wieder auf 60 Minuten gesetzt wird. Während ich also zum ersten Mal den Button gedrückt habe, wird der Sleeptimer auf 60 Minuten gesetzt. Nach 60 Minuten wird die Aktivität „PowerOff“ gestartet und damit wird über den Sonoff nach weiteren 20 Sekunden die Anlage komplett abgeschaltet. Schaffe ich es, den Button innerhalb der 60 Minuten mindestens ein weiteres Mal zu drücken, bleibt die Anlage wieder für 60 Minuten an und der Vorgang wiederholt sich.
Und jetzt noch ein paar Worte außerhalb des eigentlichen Themas:
Vielen Dank an die fhem-Forum Benutzer Byte09, justme1968 sowie an Matthias Kleine für das Entwickeln des Tasmota_Device und die genialen Beiträge auf seiner Site und an alle fhem-Forum User, die mit konstruktiven Beiträgen im fhem-Forum behilflich sind, anderen Nutzern lösungsorientiert zu helfen. Kein Dank geht an Alle, die nur auf die angebliche Faulheit der fhem-Forum Benutzer schimpfen, sich selbst Wissen anzulesen und an diejenigen, die auf die CommandRef oder das fhem-Wiki verweisen, weil sie einfach nur mit ihren Wissensvorsprung angeben wollen und nicht wirklich daran interessiert sind, anderen Menschen zu helfen.
Normalerweise habe ich etwas gegen Auto-Aufkleber wie z.B. „Kevin on Board“, die Weissagung der Cree, Stuttgart 21 oder gar den Christenfisch. Aber es schwebt mir immer mal wieder eine Idee für genau so eine Art Aufkleber durch den Kopf, wenn ich auf bundesdeutschen Autobahnen unterwegs bin. Die grafische Umsetzung überlasse ich entweder Anderen oder mache das irgendwann selbst. Wichtig ist mir der Inhalt der Message an alle Idioten da draußen:
Stellt euch vor, in einer Tempo 100 Zone kann jemand folgenden Text auf einem Aufkleber am Heck eueres Autos lesen:
„Liebe Raser und Drängler:
Selten WILL ich nicht schneller,
manchmal KANN ich nicht schneller,
aber meistens DARF ich nicht schneller fahren“
Darf gerne in dieser oder ähnlicher Form mal auf einem Auto gesehen werden.
Ich hatte hier vor einiger Zeit mal das Problem, dass ich bei AppleMail plötzlich immer eine bestimmte E-Mail als ungelesen angezeigt bekommen habe, obwohl diese selbst keine „ungelesen“ Markierung mehr hat. Folgender Eintrag aus Apples Supportcommunity hat mir dann weitergeholfen:
Guess what, i have the answer. go into the library folder in lion they make it so you cant see this folder. to get into it, go to your „go“ menu from finder with the option button held down and go to library, then go to mail, then go to the folder V2, then go to the folder „maildata“. move three files to your desktop or anywhere out of the way: „Envelope Index“, „Envelope index-shm“ and „envelope index-wal“. then re-start mail. it should fix the whole problem. It worked for me. after this, you can delete the old files from wherever you put them.
Ich wollte meinem RaspberryPi immer mal wieder eine neue Aufgabe geben und hatte nie Zeit dafür oder auch keine konkrete Anforderung. Was ich aber immer schon mal vor hatte, war es, die Signale meiner Sat-Anlage ins Netzwerk zu streamen.
Mein Sat-Receiver – ein Kathrein UFS-913 – kann dies schon. Und da er zwei Tuner hat, kann auch ein Teilnehmer fernsehen und ein anderer ein anderes Programm streamen. Je nachdem, welcher Transponder auf dem jeweiligen Tuner aktiv ist, geht sogar noch eine Aufnahme oder ein zweiter Stream.
Meine Sat-Anlage (Astra 19,2E) wird über einen Multischalter in verschiedene Räume verteilt. Natürlich könnte ich jetzt in jedem Raum einen Fernseher mit einem entsprechenden Tuner installieren. Das ist aber nicht mehr zeitgemäß:
Meine Tochter hat nur z.B. noch einen PC mit dem sie ab und zu auf den Stream des UFS-913 zugreift und sonst Streamingdienste nutzt
Bevor ich den UFS-913 gekauft habe, war die zusätzliche Anschaffung eines elgato netstream sat immer mal wieder in der Diskussion. Mir erschien diese Variante aber immer zu teuer.
Was lag nun näher, als dem RaspberryPi die Aufgabe zu geben, die DVB-S2 Signale ins interne Netz zu streamen.
Die MLD bietet eine einfache Möglichkeit einen PC in eine Multimedia Zentrale auf der Basis des Video Disk Recorder (VDR) von Klaus Schmidinger zu verwandeln.
Was bietet dieser digitale Videorekorder auf Linux-Basis:
Fernsehen
zeitgesteuerte Aufnahmen und
zeitversetzte Wiedergabe (Timeshifting)
Abspielen von DVDs und MP3s,
Programmierung und Konfiguration per Browser,
und vieles mehr
Und seit neuestem gibt es vom MLD auch eine Edition für den Raspberry PI
Zunächst einmal fand ich hier eine grundsätzliche Anleitung zur Installation der MLD auf dem Raspberry. Im Wesentlichen konnte ich dieses Vorgehen übernehmen, musste aber an einigen Stellen noch nacharbeiten, doch dazu später mehr.
Neben dem Raspberry PI (den ich schon hatte) braucht man noch einen DVB-S(2) USB Receiver. Im Netz findet man häufig die Receiver von Sundtek, die für linuxtv geeignet sind, mir aber viel zu teuer waren. Ich bin dann nach einiger Recherche auf den DVBSky S960 gestoßen, der beim Amazon bereits für unter 50 EUR zu haben war.
DVBSky S960
Da in der MLD grundsätzlich ein VDR werkelt, der laut dieser Webseite mit dem DVBSky S960 klar kommt, habe ich einfach mal zugeschlagen.
Geliefert wird der DVBSky S960 mit Netzteil (Vorteil, weil man am Raspberry dann nicht noch einen aktiven USB-Hub braucht), USB-Kabel, Fernbedienung (kann ich sicher noch für andere Projekte brauchen) und einer Mini-CD mit Treibern und Software. In dem Zusammenhang: In meinem Haushalt gibt es kein CD-ROM Laufwerk mehr, in dem diese Mini-CDs verwendet werden können. Das hätte man sich als Hersteller auch sparen können. Aber die Herstellerseite bietet auch alles zum Download an. Gut so!
Wir benötigen eine FAT32 formatierte SD-Karte mit einer Größe von mindestens 4GB. Da ich auf einem Mac arbeite, starte ich das Festplattendienstprogramm und lösche die erkannte Karte mit dem FAT-Dateiformat:
Dann laden wir die MLD in der Server Version hier herunter
Das Image für einen Streamingserver
… und entpacken dieses.
Wenn beim RaspberryPi eine MPEG2-Lizenz vorliegt, kann man diese bereits jetzt in die config.txt eintragen in dem die Zeile mit der MPEG2-Lizenz hinzugefügt wird (nur als Beispiel!):
decode_MPG2=0x1a2b3c4d
Alle enthaltenen Dateien markieren wir im Finder und kopieren diese auf die SD-Karte:
Inhalt der SD-Karte
Mit dieser SD-Karte im RaspberryPi starten wir diesen. MLD bringt in der Server-Version einen SSH-Server und einen DHCP-Client mit. Nun gilt es herauszufinden, welche IP-Adresse der RaspberryPi mit dieser Karte nun hat. Im Falle einer Fritzbox als Router im Heimnetz können wir diese recht einfach über die Weboberfläche der Fritzbox finden. Unter „Heimnetz“ -> „Netzwerk“ finden wir einen Eintrag ähnlich diesem hier
Wir können den RaspberryPi nun entweder unter seinem DNS-Namen (hier MLD_SERVER) oder seiner IP-Adresse (hier 192.168.178.113) ansprechen und eine SSH-Verbindung aufbauen. Wir starten das Terminal und geben folgendes ein:
ssh -l root MLD_SERVER
Eventuell muss man die SSH-Verbindung noch bestätigen (mit „yes“)
The authenticity of host 'mld_server (192.168.178.113)' can't be established.
RSA key fingerprint is ..............
Are you sure you want to continue connecting (yes/no)? yes
root@mld_server's password:
Das Standardpasswort ist „root“ (kann später geändert werden, wenn der Raspberry mit MLD auch über das Internet erreicht werden soll).
Dann landen wir auf der MLD_SERVER Konsole und können mit „install“ die Installation des MLD auf der SD-Karte durchführen und den RaspberryPi neu starten:
MLD_SERVER> install
start installation
partitioning disk mmcblk0
format disk mmcblk0p1
format disk mmcblk0p2
install system on mmcblk0p2
write boot files on mmcblk0p1
Installation completed
MLD_SERVER> reboot
Nach dem Reboot und erneuter Verbindung per SSH konfigurieren wir ein paar Pakete mit dem MLD-Package Manager opkg:
Wichtig sind die ersten zwei Zeilen. Trotzdem gab es bei mir ein paar Fehler (ntp-client z.B. wurde nicht gefunden), die ich aber zunächst ignoriert habe.
Sollte der vdr nun breits laufen, stoppen wir diesen mit
MLD_SERVER> stop vdr
Nun prüfen wir, ob der DVBSky S960 vom Betriebssystem erkannt wurde:
MLD_SERVER> dmesg | grep -i dvb
Die Ausgabe dieses Befehls sollte in etwa so aussehen:
[ 9.519312] v4l-dvb-saa716x: dfd91ae70d2d6350c04162f8ac32074be14947e1 saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
[ 9.577000] v4l-dvb-saa716x: dfd91ae70d2d6350c04162f8ac32074be14947e1 saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
[ 9.721303] usb 1-1.3: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[ 9.730878] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 9.731882] DVB: registering new adapter (DVBSky S960/S860)
[ 9.733336] dvbsky_usb MAC address=00:18:42:54:96:0c
[ 9.733375] usb 1-1.3: dvb_usb_v2: MAC address: 00:18:42:54:96:0c
[ 10.161739] dvbsky_m88ds3103_load_firmware: Waiting for firmware upload (dvb-fe-ds3103.fw)...
[ 10.191291] dvbsky_m88ds3103_load_firmware: Waiting for firmware upload(2)...
[ 11.291209] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Montage DS3103/TS2022)...
[ 11.341001] Registered IR keymap rc-dvbsky
[ 11.345532] input: DVBSky S960/S860 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/rc/rc0/input0
[ 11.346369] rc0: DVBSky S960/S860 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/rc/rc0
[ 11.346418] usb 1-1.3: dvb_usb_v2: schedule remote query interval to 300 msecs
[ 11.346448] usb 1-1.3: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized and connected
[ 11.348535] usbcore: registered new interface driver dvb_usb_dvbsky
Die Standard Installation des vdr bringt ein paar vordefinierte Kanallisten mit. Diese sind im Verzeichnis /etc/vdr/channels/ zu finden.
Wir bearbeiten die /etc/rc.config und ändern die Kanalliste:
MLD_SERVER> nano -w /etc/rc.config
...
# Kanalliste die verwendet werden soll (verfügbare Listen stehen unter /etc/vdr/channels)
VDR_CHANNELLIST="DVD-S-S19.2E-Astra-FTA-DE-HD"
...
Dann starten wir den vdr
MLD_SERVER> start vdr
Jetzt rufen wir am Mac folgende URL auf:
https://MLD_SERVER:3000/channels.html
Dann sollte folgendes Bild erscheinen
Funktionierender Streamdev-Server
Wenn das erfolgreich ist, kann der Spaß weitergehen: Im zweiten Teil zu diesem Thema.