Alexa zickt rum und will selbst programierten Skill nicht mehr finden

Ich habe in einem anderen Artikel ja bereits beschrieben, wie ich einen eigenen Alexa-Skill für mein Always-On-Display programmiert habe, um mir damit Wetter oder Börsendaten vorlesen zu lassen oder meine 433-Mhz-Funksteckdosen zu schalten.

Für das Schalten der Funksteckdosen benutze ich ja zudem Fauxmo auf dem Raspberry Pi Zero meines Always On Displays.

Seit einigen Tagen zickt Alexa aufs Übelste und gibt mir nur patzige Antworten auf meine Befehle:
(eigener Skill)
Alexa, sage Display Wetter.

Der angeforderte Skill gab eine ungültige Antwort
(Fauxmo)
Alexa, schalte Schlafzimmerlicht an.

Ich kann kein Gerät Schlafzimerlicht in Olivers Profil finden.
Das, was Alexa da antwortet, ist nicht sehr vielsagend. Von heute auf morgen funktioniert der Skill und auch das Schlafzimmerlicht (Fauxmo auf dem Raspi) nicht mehr.

Alexa trägt ihren Namen zu Recht

Da hat Alexa schon fast menschliche Züge (im übertragenden Sinn) und auch der weibliche Vorname passt. Fast wie bei einer Frau muss man behutsam nachfragen, was der kleinen Prinzessin denn nicht passt und kriegt nur patzige und zickige Antworten, bis man genau die richtige Frage, die Zauberformel, stellt:
 
Schatz, ist irgendwas? Du redest nicht mehr mit mir.

Nein, es ist nichts.

Ach komm, irgendwas ist doch...
Schatz?
Schatzilein?
Was hast du denn, mein Schnuffelhäschen, irgendwas bedrückt dich doch?


Ich habe nichts.

Bitte sag mir doch, was du hast. Ich will dir doch nur helfen. Bitte sag mir, was dich bedrückt. Bitte, bitte bitte, mit bunten Zuckerstreuseln oben drauf...

Naja, eine Kleinigkeit wäre da schon. Ach nee, doch nicht. Vergiss es! (dreht den Kopf weg)

...
und so weiter und so fort, bis man dann zufällig die richtigen Worte gefunden hat und Prinzessin Tausendschön gnädigerweise mit einer Winzigkeit an Antwort herausrückt, mit dessen man sich einen Millimeter in Richtung Lösung bewegen kann.

Fast genauso nervig ist Alexa und der erste Schritt für mehr Informationen ist die Seite https://alexa.amazon.de/spa/index.html#cards. Da bekomme ich schon ein bisschen mehr Infos: Protocol Violation raspi Request Identifier: amzn1.echo-api.request.1a3a25d4-85a2-4814-b244-b519e23d90a5 The application response did not conform to the specification. Please ensure that you are using the latest client library and that your responses comply with the Application Service Interface. Über das Schlafzimmerlicht schweigt sich die Seite aus. Dazu finde ich keine Meldung. Und die Meldung zum raspi-Skill ist jetzt auch nicht unbedingt zielführend.

Da Prinzesschen Alexa uns keine weiteren Hinweise gibt, was sie denn bedrückt, müssen wir ihre Umgebung checken, ob es da vielleicht irgendetwas geben könnte, das ihr missfällt, über das sie uns aber nichts sagt.

Und für wahr: nach ein paar angestrengten Überlegungen fällt mir auf, dass mit meinen DynDNS-Domain irgendetwas nicht stimmt, denn meine gebuchte Subdomain geht nicht auf die IP dea AOD, sondern auf eine ganz andere.

Also versuche ich, die IP per script zu aktualisieren. Was nicht ging. Also auf die Website des DynDNS-Providers. Und die ist off. Ich beschließe, für heute Schluss zu machen.

Im Laufe des nächsten Tages läuft die Seite des DynDNS-Providers wieder. Die First-Level-Domain, die ich für meinen DDNS-Service benutze, wurde wohl zurückgenommen und jetzt läuft irgendetwas anderes auf der Domain. Bescheid gesagt hat mir da natürlich niemand, ist ja schließlich ein kostenloser Service.

Ursache: DynDNS-Domain funktioniert nicht mehr

Alle Anfragen von meiner Alexa an mein AOD gehen jetzt also nicht mehr an mein AOD, sondern an irgendjemand anders. Der könnte sich jetzt übrigens für die Dyn-Domain ein SSL-Zertifikat ausstellen lassen und dann alles mitlesen, was für meine AOD bestimmt ist. Was mal wieder beweist, dass alles auf SSL laufen zu lassen nicht vor Abhören schützt, wenn das DNS-System für Sicherheitslücken sorgen kann. Aber das ist ein anderes Thema.

Alexa bekommt für ihre Anfragen also momentan nur irgendeine Standard-HTML-Seite eines Fremden zurück und kann damit nichts anfangen. Also brauche ich eine neue Dyn-Domain und dafür wieder ein neues Zertifikat (wie dieses Zwangs-SSL nervt und zusätzliche Arbeit verursacht!).

Ich überlege mir kurz, einen eigenen DynDNS-Service für meinem Webserver im Internet zu schreiben, finde das dann doch ein bisschen viel Arbeit und beschließe dem DynDNS-Provider noch eine Chance zu geben. Genügend andere First-Level-Domains, für die man eine Subdomain bekommen kann, sind ja vorhanden. Hoffentlich hält die jetzt ausgesuchte lange durch, sonst lohnt sich doch das eigene DynDNS-System.

Aber ich beschließe eine Sub-Domains einer meiner eigenen First-Level-Domains zu benutzen und diese dann auf die Subdomain des DDNS-Service per CNAME-Eintrag in meinem DNS-Server umzuleiten. So muss ich dann wenigstens nicht jedesmal das Zertifikat ändern (denn der Hostname bleibt ja gleich), sondern nur den CNAME-Eintrag.

Nachdem ich meinen DNS-Server und den Endpoint-Eintrag für meinen Skill bei Amazon Developer angepasst habe und sich der DNS-Eintrag so langsam im globalen DNS-Netzwerk ausbreitet, warte ich darauf, dass die Aktualisierung auf bei den Amazon-DNS-Servern angekommen ist und diese auf die neue IP verbinden. Das würde ich daran merken, dass mein Skill wieder funktioniert.

So einfach macht es mir Alexa nicht...

Tatsächlich ändert sich etwas, allerdings funktioniert es immer noch nicht. Jetzt heißt es:
(eigener Skill)
Alexa, sage Display Wetter.

Ich kann den angeforderten Skill nicht erreichen.
Ich pinge meine DynDNS-Domain von meiner Heimrechner an und er verbindet korrekt auf meine IP. Ich pinge von meinem Webserver aus und auch er verbindet auf die korrekte IP. Braucht amazon länger, um die DNS-Änderung mitzubekommen? Obwohl: dann wäre doch die Fehlermeldung noch die alte.

Wieder hilft https://alexa.amazon.de/spa/index.html#cards ein bisschen weiter... SSL handshake failed raspi Request Identifier: amzn1.echo-api.request.a5885a30-a13a-4bd8-a619-38d0b29333f9 The SSL handshake to endpoint Resource [https://dyn.cool-web.de/alexa-skill.php], Type [HTTP], Region [DEFAULT] failed. Please check that your java keystore is correctly configured Aha, Alexa findet meinen Skill schon, aber das SSL-Zertifikat gefällt ihr nicht. Mein Java-Schlüsselspeicher soll nicht richtig konfiguriert sein oder sowas. Aber ich setze doch gar kein Java ein. Hört sich für mich an, als sei die Fehlermeldung von einem Entwickler geschrieben worden, der außer Java nichts kennt und sich nicht vorstellen kann, dass es auch noch andere Programmiersprachen gibt, in denen der Skill geschrieben sein könnte. Wobei das ja eigentlich mit dem Skill nichts zu tun hat, sondern mit dem Webserver auf dem der Skill läuft bzw. dessen SSL-Modul und das hat eigentlich nichts mit Java zu tun. Naja, vielleicht geht er auch davon aus, dass alle die amazon-Webserver gegen Entgelt benutzen und die werden mit Java programmiert?

Mich beschleicht ja der Verdacht, dass hier amazon extra Steine in den (offenen) HTTPS-Weg legt, damit man den amazon-Service benutzt, an dem amazon dann noch einmal extra verdient.

Fairness gegenüber dem Kunden verliert ja allgemein immer mehr Bedeutung in Relation zur Profitmaximierung - die berüchtigten Sternchentexte (eine fabrikneuen Mercedes S-Klasse im Wert von 89.990€ bei jedem Kauf* kostenlos dazu; *außer werk-, sonn- oder feiertags, nur bei Sonnenschein und Regenbogen, nur am einem 30. eines jeden Februars) kennen wir ja alle.

Wieder kann ich wieder nur wild rumspekulieren, wie die Fehlermeldung zustande kam. An "Java" kann es auf jeden Fall nicht liegen. Aber SSL ist schon mal eine heiße Spur.

Ich probiere noch einmal so einiges wie weitere SSL-Zertifikate, die auch die Subdomain meines DynDNS-Providers einschließen, zahlreiche Tests zur Gültigkeit des SSL-Zertifikats über den Browser, aber komme nicht weiter. Die Logs von meinem Apache2-Webserver schweigen sich auch aus. Die Suche nach der Nadel im dichten Nebel im morrigen Sumpf.

Ich gehe erneut frustriert ins Bett und überlege mir, ob die Nürnberg Ice Tigers meine Echo Dots nicht vielleicht als Übungs-Pucks gebrauchen könnten. Hinter der Plexiglasscheibe würde ich den Anblick genießen, wie diese kleinen Nervtöter in 1000 Teile zerspringen würden, wenn sie voll Stoff gegen die Bande gescheppert werden.

Am nächsten Morgen ist mein Blutdruck halbwegs wieder auf Normalniveau und ich Selbstkasteiung kann fortgeführt werden...

Irgendwann stoße ich dann im unerträglich langsam ladenden Entwicklerforum von Amazon auf jemanden, der das gleiche Problem hat und eine Antwort von derkallevombau, der wohl eine Lösung hat, die für ihn funktioniert.

Die Lösung

Bei einer Anfrage an einen SSL-Server kann der Anfragende mitschicken, wie er denn gerne sein Protokoll konfiguriert hätte, also welche asymmetrische Verschlüsselungsmethode (z. B. RSA), welchen Hash-Algorithmus (z. B. SHA-256) und welche symmetrische Verschlüsselungsmethode (z. B. AES mit 128 Bit).

Die Kombination wird mit einer Textfolge wie ECDHE-RSA-AES128-SHA256 beschrieben. Und genau dieses ECDHE-RSA-AES128-SHA256 ist auch, was der Alexa-Webserver bei Amazon haben möchte. Und beherrscht mein Webserver dieses Protokoll, dann geht es mit dieser gewählten Methode verschlüsselt weiter. Und beherrscht mein Webserver dieses Protokoll, dann sagt er nur "kann ich nicht" und die Verbindung wird erst gar nicht fortgeführt. Was letztdendlich zu dieser komischen Java-Fehlermeldung von Alexa führt.

Ich weiß jetzt nicht, ob LetsEncrypt etwas geändert hat und ECDHE-RSA-AES128-SHA256 bei sich rausgeschmissen hat oder Alexa auf einmal eine Nicht-Standard-Verschlüsselungsmethode will - meine Hochachtung übrigens an derkallevombau, der sich die Mühe gemacht hat, das detektivisch auseinanderzuklamüsern - aber wir können dem Apache-Webserver (der auf meinem Raspi läuft) die gefragte Methode beibringen, indem wir die Datei /etc/letsencrypt/options-ssl-apache.conf ändern und danach den Webserver mit sudo service apache2 restart neustarten: /etc/letsencrypt/options-ssl-apache.conf # This file contains important security parameters. If you modify this file # manually, Certbot will be unable to automatically provide future security # updates. Instead, Certbot will print and log an error message with a path to # the up-to-date file that you will need to refer to when manually updating # this file. SSLEngine on # Intermediate configuration, tweak to your needs SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256 SSLHonorCipherOrder on SSLSessionTickets off SSLOptions +StrictRequire # Add vhost name to log entries: LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common Danach kann der Webserver auch das exotische Protokoll und der Skill funktioniert wieder.

Was ein Aufwand! Da frage ich mich doch: Wozu überhaupt dieser SSL-Zwang? Warum nicht einfach per HTTP übertragen? Warum wird mir als Skill-Entwickler nicht die Wahl gelassen? Warum muss ich mir diesen Klotz SSL unbedingt ans Bein binden? Warum kann ich nicht einfach wählen? Was ist mit dem Fall "Ich möchte das ohne SSL-Zertifikat und das ganze Brimborium. Mein Skil überträgt nur das Miaue von Minka. Das muss nicht geschützt werden."?

Aber ich kann es mir denken. Das wird den selben Grund haben, warum auch Google HTTPS-Seiten besser rankt als normale HTTP-Seiten. Da stellt sich auch wieder die Frage: warum muss ich einen Lexikoneintrag von Wikipedia, der der ganzen Welt schon seit Jahrzehnten bekannt ist, verschlüsselt übertragen? Was soll der Quatsch? Warum der ganze Overhead? Das kostet doch nur CPU-Zeit und erzeugt Wärme aus Strom, steigert den CO2 Ausstoß und schadet der Umwelt.

Achja, stimmt, das hatte ich heute ja schon einmal: Fairness gegenüber dem Kunden (und der Umwelt und den Mitarbeitern übrigens auch) verliert ja allgemein immer mehr Bedeutung in Relation zur Profitmaximierung.

Denn Amazon und Google (oder deren Ableger) verkaufen natürlich SSL-Zertifikate zu komplett überteuerten Preisen. Denn so ein SSL-Zertifikat-Verkauf sind im Prinzip nur ein paar Zufalszahlen mit einem virtuellen Stempel drunter und das kostet im Prinzip nichts und ist damit so gut wie eine Gelddruckmaschine. Da ist es doch nur von Interesse, wenn überall SSL benutzt wird - auch, wenn es gar nicht nötig ist.

Und bei Amazon zahlt sich das gleich zweimal aus: frustrierte Kunden, die am eigenen Spezial-SSL-Zertifikat scheitern, können ja ganz einfach zu den Amazon Webservices wechseln. Da gibt es solche Probleme natürlich nicht. Alles aus einem Guss, alles vom Hersteller selbst. Rundum-Sorglos-Paket, funktioniert einfach, kostet dafür natürlich auch.

Aber ich würde Amazon natürlich niemals unterstellen, dass die das absichtlich machen, vielleicht supporten die auch einfach die Dinge mehr, für die bezahlt wird.

Fauxmo funktioniert auch wieder

Was mich fast noch mehr wundert, ist, das Fauxmo (also mein Schlafzimmerlicht an der Funksteckdose) plötzlich wieder funktioniert.

Scheinbar fragt auch hier Alexa nach einem SSL-Zertifikat und da das jetzt wieder zu passen scheint, funktioniert wohl auch wieder das Ein- und Ausschalten der Steckdose.

Ich dachte ja bisher, dass das SimpleHTTPPlugin von FauxMo auf HTTP und nicht HTTPS geht, aber jetzt habe ich noch einmal in der Apache-Konfiguration nachgeschaut, und obwohl ich beim letzten mal beim certbot angegeben habe, dass ich keine automatische HTTP -> HTTPS Umleitung wünsche, steht da trotzdem noch in /etc/spacje2/sites-enabled/000-default.conf drin /etc/spacje2/sites-enabled/000-default.conf ... RewriteEngine on RewriteCond %{SERVER_NAME} =dyn.cool-web.de RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] Mein Webserver sagt dem Alexa-Server also, er soll SSL benutzen und der will dann wieder dieses eigentümliche Protokoll, was mein Webserver ja dann seit neuestem auch unterstützt.

Ich habe das jetzt mal auskommentiert. SSL im lokalen Netzwerk macht ja nicht unbedingt so viel Sinn. Wer sollte da schon mithören? Und was ist die Information wert, wann ich mein Schlafzimmerlicht an oder ausmache? Ohne die HTTPS-Umleitung funktioniert mein Licht dann höchstwahrscheinlich auch noch, wenn die nächste SSL-Zertifikat-Eskapade zuschlägt.

Ist es das wert?

Wenn ich mal so überschlage, wieviel Arbeit mir Alexa abgenommen hat und wieviel Zeit und Nerven mich Alexa inzwischen schon gekostet hat, dann muss ich mich fragen: Ist das Fortschritt oder Rückschritt?

Heute habe ich z. B. etwa 50 Skills manuell gelöscht (was unanständig zeitraubend ist, weil jeder einzelne Skill angewählt und deaktiviert werden muss, Absicht?), die Alexa im Laufe der Zeit installiert hat, weil sie mal wieder etwas falsch verstanden hat. Manche Skills, von denen ich noch nie etwas gehört habe und mich echt frage, wie die da reinkommen.

Und von der Entwicklung von eigenen Skills kann ich eigentlich nur abraten: das ist den Aufwand nicht wert. Die Entwicklungsumgebung (also die Webseiten) sind irgendwie durcheinandergewürfelt und haben keine Struktur. Selbst das Neu-Komplieren wird zu einer Sucherei, wo man denn jetzt klicken muss. Einfach nur schlecht gemacht. Und zwar so schlecht gemacht, dass man sich fragen muss: ist das mit Absicht so? Das kriegt man doch nur mit einem Plan so chaotisch hin?

Auch hat Alexa nicht dazugelernt und ist genau so dumm wie eh und je. Nur ist sie jetzt noch nerviger. Wenn ihr sage "Alexa, Uhrzeit" wünscht sie mir jetzt auch einen "angenehmen Mittwochabend" oder so etwas. Habe ich danach gefragt? Diese Pseudo-Höflichkeit finde ich unangenehm und penetrant. Das passt nicht zu einer Maschine und hört sich einfach nur unehrlich an.

Und dieses ständige Skill-Vorgeschlage, wenn sie mal wieder eine einfache Frage nicht verstanden hat. Ich habe das Gefühl, dann wird irgendein Skill vorgeschlagen, der sich irgendwie entfernt nach einem gesagtem Wort anhört. Und dann muss man ganz genau darauf achten, klar und deutlich Nein zu sagen, sonst hat man noch einen Skill, den man nicht will, an der Backe.

Zum Ein- und Ausschalten von Geräten, ohne Aufstehen zu müssen, taugt Alexa. Auch für einfache Rechenaufgaben und Musik hören (obwohl die Werbung da auch sehr zunimmt: zwei Songs, 2x Werbung im Wechsel hatte ich auch schon. Und Amazon Music Unlimited finde ich unverschämt teuer). Ein Hörbuch vorlesen lassen, wunderbar.

Aber man sollte Prinzesschen Alexa wirklich nicht zuviel zumuten, sonst zickt sie nämlich nur rum.