ElatoAI: Speech-to-Speech auf dem ESP32, mit Deno Edge Functions als Vermittler

Ein ESP32, der nicht selbst denkt

Das Problem, das ElatoAI adressiert, ist die Lücke zwischen einem Mikrocontroller und einem Realtime-Sprachmodell. Ein ESP32 kann Audio aufnehmen, komprimieren und über WLAN senden. Er kann kein Speech-to-Speech-Modell lokal ausführen, jedenfalls nicht in der hier beschriebenen Bauform. ElatoAI schiebt die gesamte Modellverarbeitung auf einen Server und lässt den ESP32 als Endpunkt für Mikrofon, Lautsprecher, Taste und WLAN-Konfiguration zurück. Die Zielgruppe sind damit weniger Embedded-Entwickler als Personen, die ein physisches Gerät mit einer gehosteten Stimme ausstatten wollen: Spielzeug, Companion-Geräte, Sprachassistenten ohne Cloud-SDK des jeweiligen Anbieters. Das README nennt Kickstarter und ein AI-DevKit, was die Ausrichtung auf ein Produkt statt auf eine reine Bibliothek erklärt.

Sechs Realtime-Modelle auf der Edge, drei Serverpfade

Die Architektur ist in drei austauschbare Backends gegliedert, die jeweils unter server/ liegen. Der Deno-Pfad enthält pro Anbieter ein eigenes Verzeichnis: server/deno/models/openai, server/deno/models/gemini, server/deno/models/grok, server/deno/models/elevenlabs, server/deno/models/hume sowie die Einzeldatei server/deno/models/boson.ts für Boson Higgs Realtime. Diese Modelle sind speech-to-speech, das heißt, die Vermittlungsschicht reicht Audio durch und muss selbst keine STT- und TTS-Schritte orchestrieren. Der Cloudflare-Workers-Pfad arbeitet anders: Laut Release-Hinweis vom 17. April 2026 liefert Workers AI Deepgram STT und TTS nativ, sodass nur ein LLM-API-Key mitgebracht werden muss. Hier entsteht die Pipeline also aus getrennten Stufen, nicht aus einem einzigen Realtime-Endpunkt. Der dritte Pfad ist ein FastAPI-Server, der laut README über 100 Modelle aus derselben Liste kombinierbar macht. Diese Dreiteilung ist der eigentliche Inhalt des Projekts: dieselbe Firmware, drei verschiedene Annahmen darüber, wo die Sprachverarbeitung stattfindet.

WebSocket statt WebRTC auf dem Gerät

Bemerkenswert ist die Trennung der Transportwege. Die NextJS-Webapp spricht laut Feature-Liste per WebRTC mit dem Modell, der ESP32 dagegen per WebSocket. Das ist keine Inkonsistenz, sondern eine Folge der Plattform: WebRTC auf einem ESP32 im Arduino-Framework ist aufwendig, ein Secure WebSocket mit Opus-komprimiertem Audio ist es nicht. Das README nennt Secure WebSockets und Opus Audio Compression als eigene Punkte, was darauf hindeutet, dass der Bandbreitenbedarf bewusst niedrig gehalten wird. Die Turn-Erkennung läuft über Server VAD, also nicht auf dem Gerät. Der ESP32 sendet kontinuierlich oder in Blöcken, der Server entscheidet, wann der Nutzer fertig gesprochen hat. Das verschiebt Latenz und Rechenlast vom Gerät weg, macht aber die Qualität der Gesprächsführung von der Serverstrecke abhängig. Für mehr als 20 Minuten ununterbrochene Gespräche nennt das README Edge Functions und Secure WebSockets als Voraussetzung, ohne zu erklären, welcher Mechanismus genau das Zeitfenster begrenzt.

Supabase als stiller Bestandteil des Stacks

Wer ElatoAI als reine Firmware liest, übersieht einen Punkt: Transkripte landen in der Supabase-Datenbank, Nutzer werden authentifiziert, Geräte registriert und verwaltet. Das README listet Conversation History, Device Management and Authentication, User Authentication und OAuth für den Webclient. Damit ist Supabase keine optionale Ergänzung, sondern Voraussetzung für den im Repository beschriebenen Funktionsumfang. Wer nur die Sprachschleife will, muss diesen Teil entweder nachbauen oder akzeptieren, dass die Webapp-Funktionen wie Lautstärkeregelung, Factory Reset und OTA-Update an ein Konto gebunden sind. Das ist eine Designentscheidung mit Konsequenz für den Datenschutz: Gesprächsinhalte und Transkripte liegen in einer externen Datenbank, nicht auf dem Gerät.

Inbetriebnahme: PlatformIO, Arduino IDE, Captive Portal

Das README verweist für den Einstieg auf drei Dokumentationsseiten: elatoai.com/docs/quickstart, /docs/platformio und /docs/arduino. Konkrete Befehle oder Config-Keys stehen im Repository-Text selbst nicht, deshalb lässt sich hier kein pio run oder vergleichbarer Aufruf belegen. Gesichert ist nur der Ablauf: Firmware über PlatformIO oder die Arduino IDE bauen, WLAN über ein Captive Portal auf dem Gerät konfigurieren, Gerät im Webclient registrieren, Modell und Stimme für den Agenten auswählen. Für mehrere Geräte existiert eine eigene Anleitung unter /docs/blog/multiple-devices, für die globale Verteilung eine unter /docs/blog/deploying-globally. Updates laufen laut Feature-Liste per OTA. Wer den Cloudflare-Pfad wählt, braucht zusätzlich einen LLM-API-Key, weil STT und TTS über Workers AI abgedeckt sind. Wer den Deno-Pfad wählt, braucht den Key des jeweiligen Realtime-Anbieters. Diese Verteilung der Zugangsdaten ist beim Kostenvergleich wichtiger als die Modellanzahl.

Wo die Grenzen liegen

Die wichtigste Einschränkung steht implizit im Repository selbst: Es gibt keine Releases. Der Abschnitt Recent releases ist leer, das Projekt wird über den main-Branch ausgeliefert. Für ein Produkt, das auf Kickstarter beworben wird, bedeutet das, dass Firmware und Servercode gemeinsam aus einem beweglichen Stand kommen. Wer ElatoAI in ein eigenes Gerät einbaut, übernimmt damit die Pflege des gesamten Stacks. Ein zweiter Punkt: Die Firmware ist auf ein Modell pro Verbindung ausgelegt, der Wechsel zwischen Anbietern läuft über das Backend, nicht über das Gerät. Und der Hinweis No PSRAM Required ist eine Aussage über den Speicherbedarf, keine über die Audioqualität. Ob ein ESP32 ohne PSRAM bei Opus und Server VAD über 20 Minuten stabil bleibt, lässt sich aus dem Material nicht ableiten. Wer Latenz messen will, muss das selbst tun. Schließlich: Das Repository trägt die Lizenzkennung NOASSERTION. Welche Bedingungen tatsächlich gelten, ist aus der Angabe nicht ableitbar, und das ist vor einer kommerziellen Nutzung zu klären.

Pipecat und der Unterschied im Ansatz

Der naheliegende Vergleich ist der FastAPI-Pfad, den dasselbe Repository mitliefert, aber auch Pipecat, das im Release-Hinweis vom 15. April 2026 ausdrücklich als Grundlage für über 100 STT-, LLM- und TTS-Pipelines genannt wird. Der Unterschied liegt nicht im Umfang, sondern in der Zuständigkeit. ElatoAI liefert ein fertiges Gerät samt Firmware, Webapp, Authentifizierung und Datenbank und legt die Modellwahl in sechs vorbereitete Deno-Verzeichnisse. Pipecat liefert Frameworks für Pipelines, in denen STT, LLM und TTS getrennt konfiguriert und verbunden werden. Wer die Stufen einzeln austauschen, eigene VAD-Logik einsetzen oder einen Anbieter nutzen will, der nicht in server/deno/models liegt, ist mit einem Pipeline-Framework besser bedient. Wer dagegen ein Gerät braucht, das nach dem Flashen mit einem bestehenden Konto spricht, spart mit ElatoAI den größten Teil der Integrationsarbeit. Interessant ist, dass ElatoAI beide Welten im selben Repository anbietet: den fertigen Weg über Deno und den offenen Weg über FastAPI.

Wartung, Kosten und Lizenz

Die Wartungslast verteilt sich auf drei bewegliche Teile: die Firmware, die Edge Functions und die Modell-APIs. Ändert ein Anbieter sein Realtime-Protokoll, betrifft das genau ein Verzeichnis unter server/deno/models, sofern die Änderung nicht die gemeinsame Vermittlungsschicht berührt. Das ist ein Vorteil der Aufteilung. Auf der Kostenseite fallen mindestens drei Posten an: die Modell-API des gewählten Anbieters, das Hosting der Edge Functions und Supabase. Beim Cloudflare-Pfad kommen Workers AI für STT und TTS hinzu, dafür entfällt der separate STT- und TTS-Anbieter. Zahlen nennt das README nicht, und ohne Releases lässt sich auch kein Versionsstand benennen, auf den man sich für Upgrades beziehen könnte. Zur Lizenz: Die Kennung NOASSERTION bedeutet, dass GitHub keine Standardlizenz erkannt hat. Ob und unter welchen Bedingungen der Code weiterverwendet werden darf, ist damit offen und muss im Repository selbst geprüft werden. Das ist keine rechtliche Beratung, sondern der Hinweis, dass diese Frage vor einer Produktentscheidung offen ist.

Redaktionelles Fazit

Wer einen ESP32 mit einem gehosteten Realtime-Sprachmodell verbinden will und bereit ist, Deno Deploy, Supabase und die Modell-API-Keys selbst zu betreiben, findet hier eine vollständige Referenzimplementierung inklusive Firmware, Webapp und OTA-Pfad. Wer eine lokal laufende Pipeline ohne Cloud-Zwang braucht, sollte zuerst die FastAPI-Variante und das verlinkte Projekt local-ai-toys prüfen, denn der Deno-Pfad setzt Edge Functions und einen Supabase-Backend voraus. Vor dem Kauf von Hardware ist zu klären, ob die Firmware ohne PSRAM mit dem gewählten Modell und der gewünschten Gesprächsdauer stabil läuft, da das README diese Kombination nur als Eigenschaft nennt, nicht mit Messwerten belegt.

Offizielle Quellen

1. akdeb/ElatoAI on GitHub
2. Issues
3. Project website
4. README