EchoMuse, Teil 2: Echo Dot entsperren, flashen und provisionieren

Ausgangslage

In Teil 1 ging es um alles, was vor dem ersten Flash stehen muss: die Assist-Pipeline in Home Assistant, der EchoMuse-Controller auf dem NUC und das Dashboard per HTTPS hinter Traefik. Jetzt geht es ans Gerät.

Ich habe das zweimal gemacht. Der erste Dot lief nach ein paar Umwegen, der zweite entstand für diesen Artikel - die Bilder stammen von diesem zweiten Durchgang. Wo sich die beiden unterscheiden, steht es dabei.

Vorab zur Versionsfrage, weil sie mich am Anfang am meisten Zeit gekostet hat: Die EchoMuse-Doku ist hier widersprüchlich. Rooting-Anleitung und emOS-README verlangen noch amonet v1.1.0 und FireOS 5, das Haupt-README sagt, beide Versionen funktionieren. Laut r/echomuse ist die Doku veraltet, und der Provisioning-Wizard hat amonet v2.0.0 mit FireOS 6 bei mir ausdrücklich erkannt und unterstützt. Im XDA-Thread ist ohnehin nur noch v2.0.0 angehängt.

v2.0.0 bringt einen echten Vorteil mit: einen USBDL-Notfallmodus (Mute-Taste beim Einstecken halten), mit dem sich ein verbastelter Dot retten lässt, ohne das Gehäuse zu öffnen. Wichtig ist aber auch die Kehrseite: Nach v2.0.0 nie zurück auf FireOS 5 oder ein älteres amonet. Das kann den Dot endgültig bricken.

Umsetzung

Unlock mit amonet-biscuit

Der Unlock läuft unter Ubuntu über Fastboot (Option 1 im XDA-Thread), ohne das Gehäuse zu öffnen. Vorbereitung am Laptop:

sudo apt install adb fastboot python3 python3-serial dos2unix
sudo usermod -aG dialout $USER
sudo systemctl stop ModemManager
echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend

Dazu drei Rahmenbedingungen: Laptop am Netzteil, Kabel direkt am Laptop (kein Hub) und ein echtes Datenkabel, kein reines Ladekabel.

Der Ablauf:

1. ./fastbrick.sh im entpackten amonet-Ordner starten.
2. Am Dot: Strom ab, Aktionstaste (•) halten, USB-Kabel vom Laptop einstecken und halten, bis die LED grün leuchtet.
3. YES eingeben. Nach der 10-Sekunden-Gnadenfrist nichts mehr anfassen.
4. Nach etwa einer Minute: LED wieder grün, Neustart, weißes Licht bedeutet TWRP.

Zur Kontrolle zeigt adb devices den Dot jetzt als recovery:

Bei beiden Dots ging der Unlock im ersten Anlauf durch.

FireOS 6 in beide Slots

Nach dem Unlock braucht der Dot ein bootfähiges FireOS 6, und zwar in beiden A/B-Slots. Ich habe Fire OS 6574.1 (NS65741/8146) verwendet, Metadaten auf FTVDB, Download direkt von Amazons CDN. Vor dem Flashen die Prüfsumme vergleichen - das kostet Sekunden und erspart Ratespiele:

md5sum update.zip
# erwartet: 8ca06ee4ef2806c974d2944b7fadd543

Die Slot-Falle aus dem ersten Durchgang: Beim ersten Dot habe ich die Befehlsfolge aus dem XDA-Thread übernommen - und zweimal Slot A beschrieben. Beide Installationen meldeten:

Flashing A/B zip to inactive slot: A

Der zweite Durchgang hat die Ursache sauber gezeigt: TWRP flasht immer in den inaktiven Slot und setzt ihn danach selbst aktiv. Der bcbtool-Umschaltbefehl aus dem Thread dreht das wieder zurück - und TWRP nimmt beim nächsten Mal denselben Slot noch einmal. Umschalten ist gar nicht nötig. Ein Neustart der Recovery reicht für den zweiten Slot:

adb shell twrp wipe cache
adb shell twrp wipe data
adb push update.zip /sdcard/update.zip
adb shell bcbtool get_active                # a
adb shell twrp install /sdcard/update.zip   # → inactive slot: B
adb shell bcbtool get_active                # b
adb reboot recovery
adb shell bcbtool get_active                # b
adb shell twrp install /sdcard/update.zip   # → inactive slot: A

Beim zweiten Dot wurde also zuerst Slot B beschrieben, danach A:

Direkt nach adb reboot recovery war adb devices kurz leer - nach ein paar Sekunden ist der Dot wieder da. Mein Tipp: Nach jeder Installation die Zeile inactive slot: ... lesen, nicht nur auf „Done“ achten. Am Ende müssen A und B je einmal vorkommen. Die boot-root.zip aus dem Thread wird für EchoMuse übrigens nicht gebraucht.

Provisioning-Wizard auf emOS

Den Rest erledigt der Wizard im Dashboard, ausgehend vom Dot in TWRP. Gewählt habe ich emOS - für FireOS 6 der einzige Weg.

Zwei Dinge vorher am Laptop:

• adb kill-server ausführen. Sonst hält der lokale ADB-Dienst die USB-Verbindung fest, und die USB-Auswahl im Wizard bleibt leer.
• Chrome oder Edge verwenden. Firefox hat kein WebUSB und meldet irreführend „USB is blocked … not a secure address“.

Der Wizard arbeitet sich in neun Schritten durch:

Schritt	Was passiert
1 Connect Device	Dot „Echo“ in der USB-Auswahl, erkennt amonet v2 und FireOS 6
2 Connect to TWRP	Verbindung wird wiederverwendet
3 Escrow Boot Image	Prüft beide Slots, sichert Slot A (16 MB) als Datei auf den Laptop
4 Install EchoMuse	Firmware von GitHub auf /data, dazu bereits die TLS-Zugangsdaten
5 Wake Word Assets	ONNX-Runtime und Modelle (~15 MB)
6 Build emOS	Controller baut emOS aus dem eigenen Kernel
7 Flash and Verify	emOS in Slot A, zurückgelesen und geprüft
8 Reboot and Watch	emOS v0.10 bootet, Kontrolle über die serielle Konsole
9 Configure WiFi	WLAN-Scan, Verbindung, Registrierung beim Controller

Schritt 3 verdient besondere Aufmerksamkeit. Die Escrow-Datei ist der Rückweg: Zurückspielen dauert etwa zehn Sekunden, und der zweite Slot behält zusätzlich ein unberührtes FireOS 6. Interessant beim Vergleich: Die Escrow-Dateien beider Dots sind byte-gleich, die MD5 ist identisch. Bei gleichem FireOS-Build ist das Boot-Image offenbar dasselbe. Ich sichere sie trotzdem pro Dot (escrow-dot1.img, escrow-dot2.img) und lege sie sofort an zwei Orten ab.

Auch der aktive Slot ist dem Wizard egal: Beim zweiten Dot stand er nach dem FireOS-Flash auf B. Der Wizard schreibt emOS trotzdem in Slot A und stellt danach selbst auf A um.

In Schritt 8 bin ich beim zweiten Dot über meine Ungeduld gestolpert: „Failed to open serial port“. Der Dot erscheint erst als „emOS“ in der Port-Auswahl, wenn sich der Bootring zu füllen beginnt. Also warten, bis der Ring läuft, dann verbinden.

Einbindung in Home Assistant

Nach dem Wizard taucht der Dot im Dashboard auf und muss einmal freigegeben werden (Approve).

In Home Assistant wird der Dot über die eingebaute ESPHome-Integration hinzugefügt. Er wird automatisch entdeckt, sonst manuell mit der Controller-IP und dem Port des Dots (beim ersten Dot 192.168.1.10, Port 16001). Danach die Pipeline „Local Assistant“ zuweisen. Als Wake Word läuft „Hey Jarvis“ mit der Schwelle 0,5.

HIer die Schritte der Einrichtung:

Konsolen-Passwort

emOS stellt am USB-Port eine Root-Shell bereit - ohne Passwort. Beim ersten Dot habe ich das nachgezogen, und zwar fleet-weit über das Dashboard: Zahnrad → Config → Advanced → USB console. Der Controller hasht das Passwort und schiebt es an alle verbundenen Dots, also auch an künftige. Das Passwort selbst liegt in Vaultwarden und wird nirgends sonst verwendet.

Beim zweiten Dot zeigt sich, wie das im Detail abläuft: Wizard-Schritt 4 löscht ein vorhandenes Konsolen-Passwort, und der Controller setzt es nach der Freigabe neu. Die Konsolen-Shell entsteht aber schon während des Wizards in Schritt 8 - also bevor das Passwort nachgeschoben wird. Sie bleibt ungeschützt, bis sie beendet wird oder der Dot neu startet. Bei beiden Dots kam die Passwortabfrage deshalb erst nach einem exit.

Mein Tipp: Nach dem Einrichten einmal exit in der Konsole oder den Dot neu starten. Erst dann ist die Shell wirklich geschützt.

Getestet wird am Laptop mit dem Dot per USB:

picocom /dev/ttyACM0

picocom ist hier das richtige Werkzeug, weil es die Verbindung roh und ohne Echo öffnet. Laut emOS-Doku scheint die Konsole mit Echo zu funktionieren, führt aber nichts aus. Die angezeigte Baudrate spielt bei der USB-Konsole keine Rolle.

Ein Aussperr-Risiko gibt es nicht: Falsche Eingaben verlangsamen nur, eine echte Sperre gibt es bewusst nicht, und über TWRP lässt sich die Passwortdatei jederzeit löschen. Geschützt ist nur die Shell, Boot-Meldungen bleiben lesbar.

Ergebnis

Beide Dots laufen als Sprachsatelliten in Home Assistant, mit emOS v0.10 und Firmware v2.17.0.

Für den ersten Dot gibt es inzwischen etwas Alltagserfahrung. Der Activity-Tab zeigt 33 Durchgänge mit einer Erfolgsquote von 67 % und einer medianen Antwortzeit von 3,8 Sekunden vom Wake Word bis zur fertigen Antwort - mit Spracherkennung und Sprachausgabe über die Cloud. Near-Misses oder Audio-Aussetzer gab es keine.

Auffällig sind fünf Einträge „NO SPEECH“, vier davon nachts zwischen drei und halb sieben. Das Wake Word hat ausgelöst, gesprochen wurde nichts, nach rund 5,4 Sekunden hat sich die Pipeline selbst beendet. Das sind echte Fehlauslösungen. Die Schwelle steht aktuell auf 0,5 - da ist noch Feintuning nötig.

Zum Abschluss habe ich die Verbindung zwischen Dots und Controller abgesichert. Seit Schritt 4 des Wizards haben die Dots TLS-Zugangsdaten, und beide zeigen im Dashboard „wss (TLS)“. Damit kann der Controller unverschlüsselte Verbindungen ablehnen:

sed -i 's/^REQUIRE_DEVICE_TLS=.*/REQUIRE_DEVICE_TLS=1/' .env
docker compose -f docker-compose.deploy.yml up -d --force-recreate

Beide Dots verbinden sich danach weiterhin, unverschlüsselte Verbindungen werden abgewiesen.

Fazit

Amazon ist komplett draußen: kein Konto, kein Alexa, keine Amazon-Software auf den Dots. Das Wake Word läuft lokal im Controller auf dem NUC, die Gerätesteuerung lokal im Konversationsagenten von Home Assistant.

Komplett cloud-unabhängig ist das Setup aber noch nicht. Spracherkennung und Sprachausgabe laufen über Home Assistant Cloud - alles, was nach „Hey Jarvis“ gesprochen wird, geht zur Verarbeitung an Nabu Casa. Die nächtlichen Fehlauslösungen machen das zusätzlich zu einer Datenschutzfrage. Für die Inbetriebnahme war die Cloud-Pipeline bewusst gewählt, weil sie eine bekannte Größe ist. Der Umstieg auf eine vollständig lokale Pipeline mit Whisper und Piper ist ein eigenes Thema für später.

Der zweite Dot ging deutlich glatter als der erste - fast alles, was ich dabei anders gemacht habe, steckt in der Box unten.

Stolpersteine

Stolperstein	Symptom	Lösung
Widersprüchliche Doku zu amonet	v1.1.0 vs. v2.0.0, FireOS 5 vs. 6	Community fragen (r/echomuse, Discord), der Wizard prüft selbst
Slot-Falle beim FireOS-Flash	zweimal „inactive slot: A“	nicht mit bcbtool umschalten, zwischen den Installationen nur adb reboot recovery
Dot nach Recovery-Neustart weg	adb devices kurz leer	ein paar Sekunden warten
Firefox	„USB is blocked … not a secure address“	Chrome oder Edge verwenden
ADB-Dienst läuft noch	USB-Auswahl im Wizard leer	adb kill-server
Wizard Schritt 8 zu früh	„Failed to open serial port“	warten, bis der Bootring sich füllt und „emOS“ in der Port-Auswahl erscheint
Konsole belegt	„Device or resource busy“ bei /dev/ttyACM0	Dashboard-Tab schließen, sudo fuser -v /dev/ttyACM0 zeigt, wer sie hält
Keine Passwortabfrage	Shell stammt noch aus dem Wizard	exit oder Dot neu starten