Amazon Echo wird zum Radio für lokale MP3 Dateien

Vielleicht geht es Euch wie es mir ging, nachdem ich den Amazon Echo ein paar Wochen im Betrieb hatte. Wir haben uns gleich zu Anfang einen großen Amazon Echo und einen kleinen Amazon Echo Dot zugelegt (Nachtrag am 09.08.2018: Dank Amazon Prime Day jetzt stolzer Besitzer von 3 Amazon Echo Dot und 2 Amazon Echo, sowie 2 Fire TV Sticks 🙂 ).

Nach den ersten Spielereien mit der netten Dame aus dem Böxle haben wir festgestellt, das wir Sie primär zum Musik hören nutzen. Jetzt ist es so, das wir als Amazon Prime Kunden zwar “nur” die kleine Variante von Amazon Musik nutzen können, welche zwar um die 2000000 Songs beinhaltet, aber man nicht von beiden Amazon Echo auf Amazon Musik gleichzeitig zugreifen kann. D.h. bisher hat einer Amazon Musik gehört, der andere dann TuneIn Radio.

So richtig zufriedstellend fand ich das alles nicht, zumal ich doch eine recht große eigene MP3 Musiksammlung im Laufe der Jahre angesammelt habe. Folgende Gedanken gingen mir dabei durch den Kopf:

• Gedanke 1: Ich richte einen Icecastserver ein – verbinde diesen mit TuneIn Radio – und rufe via Alexa ab. Problem: Musikrechte (könnte für mich privat sehr teuer werden)

• Gedanke 2: Auf der QNAP (auf dieser NAS liegen meine MP3s) die Music Station aktivieren und diese via IFTTT ansteuern. Leider geht das Rezept bei IFTTT für die Auswahl der Playlisten nicht (vermutlich ein BUG oder mein OS für die NAS ist zu alt)

• Gedanke 3: Wie baue ich einen Skill, um ein eigenes Radio zu betreiben. Den Skill bei Amazon halt immer privat halten

Nach längerer Suche bin ich über das inoffizielle deutsche Alexa und Echo Forum gestoßen, in welchem der Benutzer Waringer folgenden Thread eröffnet hat: Alexa-Radio

Alexa-Radio

Hier mal eine kurze Zusammenfassung. Der Benutzer Waringer hatte das gleiche Problem, nichts im Internet gefunden und daraufhin selbst was programmiert. Der Skill ist kein fertiges Produkt, d.h. Ihr müsst Euch ein wenig mit Internet, Webserver und vielleicht Linux auskennen, aber ich hatte stehts super Unterstützung durch Waringer erfahren dürfen. Diese Unterstützung möchte ich jetzt auf diesem Weg weitergeben und erstelle hierzu eine möglichst detailierte Anleitung.

Was braucht Ihr alles?

• Ein Amazon Konto. Das werdet Ihr wohl schon haben, sonst hättet Ihr vermutlich keinen Amazon Echo zu Hause rumstehen
• Ein Amazon Developer Konto. Dieses könnt Ihr hier erstellen . Soweit ich noch richtig informiert bin, ist dieses kostenfrei. Nur für den Zugang zu Amazon AWS wird eine Kreditkarte (wegen Authentifizierung) benötigt, aber für diese Lösung hier brauchen wir kein Amazon AWS.
• Eine URL, welche an die IP Adresse eures Zuhause leitet (klingt komisch, erkäre ich aber später im Detail)
• Einen oder zwei privat betriebene Webserver
• Ein NAS wo die MP3 liegen (eventuell geht auch eine andere Lösung)
• Einen Amazon Echo oder Amazon Echo Dot oder ….
• Etwas Zeit und Nerven, da mit Sicherheit nicht immer alles Rund läuft.

Fangen wir an

Zu aller Anfang etwas Theorie. Im Prinzip läuft das ganze so ab. Bei Amazon Developer wird eine private Skill Information erstellt. Eine Anleitung hierzu kommt später. In dieser Skill Information wird eine URL hinterlegt, wo Amazon den “eigentlichen Skill” findet. Bei mir habe ich das folgendermaßen gelöst:

NAS

• Meine QNAP NAS meldet sich bei myqnapcloud.com an. Dort habe ich schon eine URL konfiguriert, d.h. die QNAP meldet sich dort von sich aus an und bestückt die “private” URL mit der aktuellen externen IP Adresse, welche ich von meinem Provider bekommen habe. Sicherlich tut es hier auch jedes andere DynDNS Tool oder Anbieter (z.B. in der Fritzbox). Es ist halt wichtig, mit einer URL den Webserver bei Dir zu Hause ansprechen zu können.
  Ich wollte das Ganze noch “schick” haben. Da ich ja die Domain hasenmueller.de betreibe, habe ich ein paar SubDomain Eintäge im DNS vom Provider setzen lassen, welche als CNAME Einträge gesetzt wurden, d.h. wenn z.B. die Subdomain abc.mypublicfqdn.tld aufgerufen wird, steht im DNS, dass es sich um die IP von der URL abc.myprivatefqdn.tld handelt. Wichtig! Das hat nichts mit einer URL Weiterleitung zu tun. Es dient einzig und allein der Auflösung von Namen zu IP Adresse.
  Amazon fragt also (bei dem gehosteten Skill) nach, welche IP hat die URL abc.mypublicfqdn.tld. Der DNS beantwortet diese Frage dann auf Grund des CNAME Eintrags mit der IP der URL von abc.myprivatefqdn.tld. Somit landet die Anfrage des Skill bei meiner privaten externen IP Adresse bei mir zu Hause. Ebenfalls wichtig ist, dass diese private und extern erreichbare URL, mit einem SSL Zertifikat abgesichert ist. Hier sei die Verwendung von Let’s Encrypt zu empfehlen.

Notebook

• Da ich noch ein altes Notebook (8 GB RAM – 500 GB Festplatte) rumliegen hatte, habe ich auf dieses die Virtualisierungsplattform (Citrix) XenServer installiert. Auf diesem haben ich dann 2 virtuelle Ubuntu 18.04 LTS Server installiert. Ihr könnt natürlich auch andere Virtualisierungsplattformen verwenden oder echtes Blech, ganz nach Eurem Gusto. Der XenServer dient als reine “ich stelle folgende Dienste zur Verfügung” Plattform. Warum habe ich mich für 2 Ubuntu Server entschieden? Ich wollte einfach den externen Zugriff vom internen Netz etwas entkoppeln. Sicherlich lacht sich jetzt der eine oder andere Hacker ins Fäustchen, aber für die Security des kleinen Mannes reicht es allemal.

Virtuell

• Nennen wir die beiden Server zur Vereinfachung extern (IP 192.168.1.235) und intern (IP 192.168.1.236)
  • Auf dem externen Server laufen folgende Dienste:
    Apache2 (als reverse Proxy)
    SSL mit Let’s Encrypt
    OpenSSH (abgesichert)
    Firewall
    Fail2Ban
    Logwatch
    Apticron
  • Auf dem internen Server laufen folgende Dienste:
    Apache2
    Alexa-Radio Skill
    MP3 Dateien werden von NAS auf eine Mountpoint gemountet
    MariaDB, auf welcher der Skill die Informationen der MP3 speichert, damit diese ausgewertet werden können.

Details

Ich werde hier jetzt nicht darauf eingehen wie man ein Windows oder Linux installiert, genauso wenig, wie man einen Apache2 Webserver installiert, aber auf meine Konfigurationen werde ich eingehen.

Auf dem externen Server habe ich eine Config, welche alles was auf Port 80 ankommt, auf Port 443 weiterleitet.

Sobald man dann auf dem Port 443 anklopft (was Amazon auf jeden Fall macht) kommt diese Config zum Einsatz:

<IfModule mod_ssl.c>
<VirtualHost extern.myprivatefqdn.tld:443>

        ServerAdmin webmaster@myprivatefqdn.tld
        ServerName extern.myprivatefqdn.tld
        
        # URL Zeile vom Browser wird auf http://192.168.1.236:1280 umgeschrieben, somit intern Zugriff, extern kein Zugriff
        #<Directory "/soundfiles/">
                   RedirectMatch ^/soundfiles/(.*)$ http://192.168.1.236:1280/$1
        #</Directory>

        # Weiterleitung an Skill Radio, welcher auf Port 3081 im Webserver läuft
        Proxypass               "/echo/radio" "http://192.168.1.236:3081/echo/radio"
        ProxyPassReverse        "/echo/radio" "http://192.168.1.236:3081/echo/radio"

        LogLevel debug
        ErrorLog ${APACHE_LOG_DIR}/alexa-radio_error.log
        CustomLog ${APACHE_LOG_DIR}/alexa-radio_access.log combined

SSLCertificateFile /etc/letsencrypt/live/extern.myprivatefqdn.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/extern.myprivatefqdn.tld/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Was genau passiert hier?

Wenn Du im Browser die URL http://extern.myprivatefqdn.tld (also HTTP Port 80) eintippst, wirst Du auf https://extern.myprivatefqdn.tld (also HTTPs Port 443) weitergeleitet und siehst ….. nichts, also nur eine leere Seite. Für Scriptskids völlig uninteressant.

Solltest Du jedoch die URL https://extern.myprivatefqdn.tld/soundfiles/ aufrufen, erfolgt ein RedirectMatch auf die URL http://192.168.1.236 auf Port 1280. Die Webseite welche mir angezeigt wird, ist mein MP3 Verzeichis von 0 bis 9 und A bis Z. Das kommt aus dem Grund zustande, da ich ja im Vorfeld auf dem internen Webserver

1. einen Mount von meinem QNAP NAS auf einen internen Mountpoint gemacht habe (nur lesend!) und
2. dann im HTML Verzeichnis vom internen Apache Webserver (welches auf Port 1280 hört) mit symbolischen Links diese interne Verzeichnis dort optisch zur Verfügung stelle.

Somit kann ich mich “intern” durch die MP3 Verzeichnisse mit dem Browser durchklicken bis ich auf der eigentlichen MP3 Datei bin und diese theoretisch im Browser anhören. Ruft man die URL https://extern.myprivatefqdn.tld/soundfiles/ jedoch von “außerhalb” meines private Netzwerks auf, ist die IP 192.168.1.236 ja gar nicht bekannt, da diese privaten IPs nicht ins Internet geroutet werden.

Es muss zum Musik hören also folgende Information bekannt sein

1. Die externe URL
2. Das virtuelle Unterverzeichnis (in Beispiel “soundfiles”)
3. Man muss sich im gleichen privaten Netzwerk wie der Amazon Echo befinden

Damit sind wir auf dem externen Webserver erst mal fertig.

Der eigentliche Skill

Auf der GitHub Seite von Waringer solltet Ihr mal alles durchlesen. Dort wird das Zusammenspiel auch nochmals graphisch dargestellt. Wir wissen in unserem Beispiel aber auch, das es im externen Webserver in der Config die Zeilen

# Weiterleitung an Skill Radio, welcher auf Port 3081 im Webserver läuft

Proxypass "/echo/radio" "http://192.168.1.236:3081/echo/radio"
ProxyPassReverse "/echo/radio" "http://192.168.1.236:3081/echo/radio"

gab. Wozu werden die jetzt benötigt. Ich habe ganz oben erwähnt, das man im Amazon Developer eine URL hinterlegen muss. Das ist die URL, auf dem der eigentliche "programmierte" Skill läuft. D.h folgendes wird der Reihe nach passieren.

1. Du erstellst auf Amazon Developer den Skill Eintrag.
2. Jetzt aktivierst Du diesen “privaten” Skill auf dem Amazon Echo
3. Dann sprichst Du z.B. “Alexa, öffne [Name des Skills, wie Ihr den genannt habt] und suche [z.B. ABBA]
4. Alexa, besser Amazon Echo kontaktiert dann Amazon. Amazon prüft ob die externe URL erreichbar ist und übergibt an den Skill
5. Der Skill welcher intern auf http://192.168.1.236:3081/echo/radio läuft, ruft die externe URL https://extern.myprivatefqdn.tld/soundfiles/ auf und wird dabei auf die interne URL http://192.168.1.236:1280 umgeleitet, wo der Amazon Echo dann den Weg zu den MP3 Dateien findet.
6. Auf Grund der internen Datenbank (MariaDB) kennt der Skill die Eigenschaften der MP3 und erstellt eine temporäre Playlist, die der Reihe nach alles abspielt, wo er in der Datenbank was mit [z.B. ABBA] gefunden hat. Von Waringer wurde auch noch eine Optimierung programmiert, womit man das Kommentarfeld der MP3 Tags auslesen kann. Somit kann man dann “steuerbare” Playlisten erstellen, indem man eigene Schlüsselwörter in die Kommentare (getrennt durch Strichpunkt “;”) schreibt.

Der Skill wurde mit der Programmiersprache Go durch Waringer programmiert. Du musst diese also zuerst auf dem internen Webserver installieren. Die Anleitung auf deren Homepage ist aber recht gut. Danach müssen die beiden Dateien radio.go und scanner.go kompiliert werden. Die auf der GitHub beschriebene Datei radio.conf wird nicht während die Kompilierungsphase gebraucht, sondern erst dann, wenn die kompilierte Datei radio gestartet wird.

Shortcuts

Nachtrag am 09.08.2018:

Nachdem ich jetzt ca. 3 Wochen im Urlaub war, musste ich selbst feststellen, das gewisse Befehle auf der Linux Konsole in Verbindung mit dem Alexa-Radio Skill mir geistig abhanden gekommen sind (was eigentlich für einen erholsamen Urlaub spricht). Von daher schreibe ich hier einfach mal ein paar Befehlszeilen auf, damit man diese parat hat.

Mit

./build.sh

werden die ganzen *.go Dateien kompiliert.

Nach dem erfolgreichen Kompilieren müssen die beiden Dateien

bin/radio

und

bin/scanner

in das Verzeichnis

/usr/local/bin/

kopiert werden.

Im Verzeichnis

/etc

liegt die Datei radio.conf, welche auf eure individuellen Systemvorausetzungen angepasst sein muss. Diese Datei wird nur beim starten des Skills ausgelesen und benötigt (jedoch nicht beim Kompilieren).

Im Serververzeichnis

/etc/systemd/system

befindet sich die Datei alexa-radio.service mit dem Inhalt

[Unit]
Description=Alexa-Radio
After=network.target mysqld.service 

[Service] 
ExecStart=/usr/local/bin/radio -c /etc/radio.conf
Type=simple
WatchdogSec=30s
Restart=on-failure

[Install]
WantedBy=multi-user.target

Eingeschaltet bzw. aktiviert wird es mit dem Befehl

systemctl enable alexa-radio.service

Danach kann man den Skill mit

systemctl start alexa-radio.service

starten und mit

systemctl stop alexa-radio.service

stoppen.

Falls Ihr mal die Datenbank zwischendurch updaten müsst, geht das so

mysql -u Benutzername -p Passwort < sql/dateiname.sql

Damit wird die SQL Datei mit den Credentials gleich in die Datenbank “geschossen”

Ebenso könnt Ihr via Shell die Datenbank abfragen. Meldet euch dazu zuerst an der MariaDB mit

mysql -u Benutzername -p Passwort

an. Danach werdet Ihr (vermutlich) nochmals nach einem Passwort gefragt.

Jetzt könnte Ihr folgendes SQL Statement kopieren und in die Shell einfügen. Bitte ersetzt dabei den Platzhalter %abba% durch z.B. %new york%, halt den String, den Ihr in der Datenbank finden wollt. Bitte die beiden “%” Zeichen vor und nach dem String dran lassen!

SET @search='%abba%';SELECT TracK.* FROM TracK LEFT JOIN ArtisT ON TK_AT_id = AT_id LEFT JOIN AlbuM ON TK_AM_id = AM_id WHERE TK_Name LIKE @search OR TK_Comment LIKE @search OR AT_Name LIKE @search OR AM_Name LIKE @search;

Mit der Tastenkombination

Ctrl + C

kommt Ihr wieder auf die normale Shell zurück

An dieser Stelle werde ich jetzt erst mal nicht mehr weiter schreiben, da es mehr Sinn macht, auf Fragen von Dir / Euch zu antworten und diese dann weiter in die Anleitung einfließen zu lassen.

Schreibt bitte auch gerne in die Kommentare, was euch gut gefällt oder auch was euch gar nicht gefällt, bzw. was Ihr noch vermisst, damit wir diese Anleitung immer besser machen.

Update:

Die oben stehende Anleitung hat bei mir gut funktioniert, jedoch bin ich von meiner QNAP NAS abgekommen.  Meine Daten liegen zu auf der pCloud, sodass ich das Konzept der obigen Anleitung nicht mehr verfolge und betreibe. Von daher bitte ich um Abstand mit Fragen zu halten, da ich einfach nicht mehr im Thema bin.