Monatsrückblick Juli / August 2026 ist online!

[Leonie]

Ich sag mal so, wenn du eine Lösung findest, wie man aus dem Audio heraus die Sprache erkennen kann und das ganze ohne Cloud Service und phne exzentrische Hardware, dann her damit :D

Ich könnte mir vorstellen das es eine Schnittstelle gibt, ich nenne sie mal "getLanguage", diese wird von Core vor der NLU aufgerufen und soll die korrekte Sprache oder NULL melden, dann wird die beschriebene Logik genommen. An diese Schnittstelle könnte man dann irgendein System anschließen. Würde vmtl. auch über gRPC laufen, liefert den rohen PCM-Stream, vielleicht den User, wenn der bekannt ist, und erwartet einen String.

Das ist noch ferne Zukunft, ehe die pluggable NLU programmiert ist, ergibt das gar keinen Sinn. Spannend dürfte es schon sein deutsche Dialekte zu parsen, bisher ist die bewusste Programmierung auf "Hochdeutsch" ausgelegt, bewusst weil das die Sprache ist, die bei uns hier im Gesetz steht :D

[OliverIO]

@Leonie
könnte man das nicht, wie bereits erwähnt an das aktivierungswort hängen?
also unterschiedliche namen, sind dann unterschiedliche wahl der spracherkennungsmodelle und ausgabesprachen

[Leonie]

Eher nicht, Core hat keine Ahnung vom Wakeword und die Satelliten interessieren sich nicht für irgendwas anderes. Aktuell läuft es so:
Wakeword erkannt -> Audio-Kanal zum Core wird geöffnet -> Audio wird von den Mikrofonen so lange gestreamt bis Stille erkannt wird -> Audio Kanal wird geschlossen. Der Audio-Kanal wird aber auch geschlossen, falls Core erkennt, das es nichts für ihn ist. Die Satelliten sind bewusst dumm. Ob überhaupt mehrere Wakewords möglich sind, kann ich aktuell gar nicht beantworten, die Ressourcen von so einem ESP sind schon eher begrenzt. Und dann noch die Wakeworderkennung parallel für x Sprachen laufen lassen, das ist ne Menge Arbeit, das kann ich mir aktuell nicht vorstellen.

[PackElend]

@Leonie sagte:

Ich sag mal so, wenn du eine Lösung findest, wie man aus dem Audio heraus die Sprache erkennen kann und das ganze ohne Cloud Service und phne exzentrische Hardware, dann her damit :D

Scheint whisper kann dies https://openai-whisper.mintlify.app/guides/language-detection#automatic-detection

Automatic Detection
​>
CLI
By default, Whisper automatically detects the language when specified

futo.org bietet auch mutli language an

Aber die warten immer bis der Text gesprochen wurde und fangen dann an zu transkribieren. Da leidet wohl UX.

Wenn ich mal wieder eine ruhige Minute habe kann ich mal mal schauen wo hier die Anstrengungensi bzgl Dialekt Sprachmodellen. Ich weiss es wird daran gearbeitet, bin diesem aber nicht mehr gefolgt

[OliverIO]

@PackElend
whisper kann bidirektional nicht.
das wird aktuell über ein neues modell eingeführt. api noch nicht verfügbar
https://openai.com/de-DE/index/introducing-gpt-live/

aber hier geht es ja um komplett alles offline ohne irgendeine externe api

[WolfgangD]

Gibts zur Motivation irgendwo eine kleine Audio Demo von Hannah als MP3 zum Anhören?

[Leonie]

Hannah nutzt im Standard eine beliebige Piper-kompatible Stimme. Schau mal hier, da kannst du dir ein paar Beispiele anhören:
Hugging Face – Piper Voices (de_DE)

Du kannst natürlich auch andere Stimmen einbinden oder sogar deine eigene trainieren.

Da ich hier keinen zentralen Cloud-Dienst beschreibe, sondern eine Sprachassistenz, die lokal in deinem eigenen Haus „wohnt“ und über die du die volle Hoheit hast, gibt es schlicht nicht „die eine Stimme“ – wie man es von Amazon Alexa oder Google Gemini kennt.
Es gibt lediglich die Kernanforderung, das sämtliches Audio in 16 kHz Mono vorliegen muss.

Hinweis zur Transparenz:
Ich bin für mich persönlich leicht vom strikten No-Cloud-Ansatz abgewichen und nutze aktuell die Azure Speech Synthese. Grund dafür war die überschaubare Auswahl an wirklich guten, hochqualitativen Piper-Stimmen auf Deutsch und meine fehlende Lust, ewig nach Alternativen zu suchen. Azure bietet mir zufällig genau die Stimme, die ich mir für Hannah vorgestellt habe – und das in meinem Rahmen vollkommen kostenlos.

Dennoch: Die lokale Piper-Synthese ist vollwertig supported und wird standardmäßig präferiert. Sämtliche Funktionen werden von mir primär gegen Piper entwickelt und getestet.

Kurzer Nachtrag zum Thema Hardware-Bestellungen:

Damit hier keine falschen Erwartungen entstehen: Ich werde keine fertigen Platinen oder Hardware verkaufen – das kann und möchte ich weder logistisch noch privat leisten. Mein Fokus liegt rein auf der Software- und Hardware-Entwicklung.

Ich stelle euch selbstverständlich alle Fertigungsdateien (Gerber, BOM, Centroid/CPL) komplett Open Source zur Verfügung, sodass sich jeder die Platinen direkt beim Hersteller der Wahl (z. B. JLCPCB oder PCBWay) bestellen und bestücken lassen kann.

Idee für die Community:
Da der Stückpreis bei SMT-Bestückungen mit steigender Menge extrem fällt (Rüstkosten teilen sich auf), könnt ihr euch hier im Forum super zusammenschließen und eine kleine Sammelbestellung organisieren. Ich vernetze Interessierte da gerne untereinander!

[tve]

Tolles Projekt, Leonie! Ich würde gerne das Ganze mal ausprobieren aber es scheint im Moment unmöglich zu sein da es nur mit Deinen Satelliten geht und die nicht erhältlich sind. Ich sehe einige "AIot" Dinger im Angebot die ESP32, Lautsprecher, und Mikrophon haben, die sind auch meist von ESPHome unterstützt. Der Seeed reTerminal Sticky ist ein Beispiel (https://www.seeedstudio.com/reTerminal-Sticky-p-6861.html). Wie schwierig wäre es die Hauptsache der Satellitenapp an ESPHome anzupassen damit andere viele verschiedene Geräte benutzen können?

[Leonie]

Hi,

vielen Dank für das Feedback!

Eigentlich wollte ich die Hardware-Pläne schon vor zwei Wochen veröffentlichen, damit sich jeder die Platinen selbst bestellen kann. Mir ist allerdings etwas dazwischengekommen – gebt mir bitte noch ein klein wenig Zeit, das kommt auf jeden Fall.

Zu ESPHome: Das wird es so nicht geben. Die Audio-Pipeline (vor allem das Wakeword-Handling und das Streaming-Protokoll) ist einfach zu speziell dafür. Es bleibt also bei der eigenen ESP-IDF-Firmware. Die läuft grundsätzlich aber auch auf anderer ESP32-Hardware und ist nicht starr an meine Platinen gebunden.

Was die Hardware mitbringen muss:

ESP32-S3 mit Octal-PSRAM: Das Wakeword-Modell braucht den Speicher zwingend.
Lautsprecher: Ohne Speaker fällt ein Board als vollwertiger Satellit raus – Audioausgabe gehört einfach fest zum Konzept.

Konfiguration & Mikrofone: Die Firmware ist da recht flexibel. Ich unterstütze I2S-Mikrofone, direkte PDM-Mikrofone und PDM über TDM-Wandler. Das lässt sich alles sauber per menuconfig bzw. sdkconfig anpassen. Im Repo liegen dafür auch schon fertige Defaults:

sdkconfig.defaults.devkit für I2S-Mikrofone
sdkconfig.defaults.rev3 / rev4 für PDM-Mikrofone
sdkconfig.defaults.rev5 für PDM→TDM-Wandler

Der Speaker läuft immer über I2S. Dazu kommen noch vier Buttons (Mute, PTT, Vol+, Vol-) sowie optional I2C für Sensoren (unterstützt werden BME680, BMP280, AHT20) und SPI für eine SD-Karte. Die GPIOs dafür kannst du völlig frei belegen. Wenn du Sensoren, SD-Karte oder Bluetooth nicht brauchst, deaktivierst du es einfach.

Der Haken in der Praxis: Es ist halt kein Plug&Play über eine einfache ESPHome-YAML. Du musst das Projekt einmalig selbst mit der ESP-IDF bauen und per UART flashen. Sobald das erledigt ist, laufen spätere OTA-Updates aber ganz normal über meinen Update-Server mit.

Viele Grüße

[manne01]

Hallo Leonie,

mit Spannung habe ich dieses Projekt hier gefunden - nachdem ich im Grunde genau sowas bei mir einrichten und nutzen will was Du damit anvisierst. Auch ich hatte schonmal in Richtung Homeassistant geschaut.

Vorab also erstmal ein riesen Dankeschön für die ganze Arbeit hier und das so selbstverständliche teilen. Das ist ganz großartig, möge es Dir mit viel positiver Rückmeldung, Freude und Mitstreitenden belohnt werden!

Meine Rückfragen:

1. Bezüglich Selbstbau-Platine für die Satelliten - dazu wurde ja schon was geschrieben, da will ich mich anschließen. Auch ich habe aber im Zuge meiner kleinen laienhaften Recherchen (entlang Home Assistant Voice) bei großen Online Händlern fertige ESP32-S3 Boards gefunden, z.B. sowas wie Artikelnummer B0FP5QYZM9. Ich glaube da gibt es noch mehr. Könnte man nicht zur Vereinfachung für ein/mehrere Geräte eine unverbindliche Empfehlung aussprechen und diese Hardware dann mit Deiner Satelliten-Software ausstatten?

2. Edit: Vor dem Hintergrund dass geeignete Satelliten derzeit noch nicht verfügbar sind tritt doch die Telegram Sprachnachricht zumindest vorübergehend in den Vordergrund.
   Kannst du fürs vorläufige Arbeiten/Testen mit Telegram Sprachnachrichten noch weitere Infos/einen guten Link bereitstellen wie man da einsteigt/vorgeht?
   Oder gibt es Alternativ die Möglichkeit ein Mini Web Frontend für die noch einfachere Sprachkommunikation im Browser (Desktop/Mobil) zu schaffen? Grade noch den iobroker Datenpunkt hannah/commands/textcommand entdeckt, damit sollte das ja erstmal erledigt sein.

3. Ich (und sicher auch andere) betreibe iobroker als Docker-Container zusammen mit anderen Containern auf meinem Home-NAS.
   Ich kann/möchte möglichst keine Software ohne Isolierung installieren und fände es auch einfacher oder für mich beherrschbarer.
   Könntest Du, oder jemand der das im Gegensatz zu mir kann, für die Hannah-Core Module und WebUI ein Docker-Image und Docker-Konfiguration bereitstellen? Ist das möglich oder zuviel Arbeit?
   Denn so oder so wäre das ganze doch auch isoliert und kompakt für Docker Anwender installierbar. Ich denke das würde Hürden senken und vielleicht sogar Reichweite schaffen.
   Oder gibt es technische Gründe warum es nativ laufen muss? Oder ist es noch zu früh dafür?

4. Exkurs zur KI-Hardware: Für ollama (und dann auch den faster-whisper-server) betreibe ich noch einen zusätzlichen PC mit AMD Strix Halo iGPU, ich hoffe das passt dann auch ohne Nvidia/Apple Silikon?
   AMD Strix Halo erscheint mir preislich und platz-/energiebilanzmäßig attraktiv zu sein grade für KI im doch eher noch als leichtgewichtiger zu bezeichnenden Home-Automation- und Home-Assistenz-Bereich, ich hoffe das passt. Geht da jemand mit?

So, falls ich irgendwas im existierenden Verlauf überlesen habe oder sich nach der Installation total offensichtlich ergibt, gerne sagen, dann gehe ich natürlich diesen Weg sobald ich kann.

Schöne Grüße!

[Leonie]

Hallo,

vielen Dank für die lieben Worte, das freut mich wirklich sehr! 🙂 Und gerne der Reihe nach zu deinen Fragen:

Selbstbau-Platine vs. fertige ESP32-S3-Boards

Kurze Ehrlichkeit vorweg: Ein x-beliebiges fertiges ESP32-S3-Board von Amazon "out of the box" wird nicht funktionieren — die Firmware braucht zwingend zwei I2S-Mikrofone und einen I2S-Verstärker samt Lautsprecher, und die sind auf so einem nackten Devkit schlicht nicht drauf.

Was aber tatsächlich schon länger als offizieller Entwicklungspfad existiert: Ein ESP32-S3-DevKitC-1, dazu zwei INMP441-Mikrofon-Breakouts und ein MAX98357A-Verstärker-Breakout extern angeschlossen. Dafür gibt's im Repo ein eigenes Kconfig-Profil und eine Schritt-für-Schritt-Anleitung zum Flashen über USB-C. Das ist also eine echte, unverbindliche Empfehlung, die ich guten Gewissens geben kann — nur eben nicht "ein Board, fertig", sondern "ein Devkit + zwei Mic-Breakouts + ein Amp-Breakout, verkabelt". Als Status-LED gibt's dabei nur die eine onboard WS2812 (statt des LED-Rings meiner Platine), das mmWave-Radar (LD2410) ist auf keiner Variante aktuell mit Firmware unterstützt.

Falls du auf so einer Basis experimentieren willst, meld dich gerne nochmal - ich helfe dir beim Einstieg.

Zwar hatte ich mir vorab auch Platinen wie den Satellite 1 von Futureproof Home angeschaut, aber den Preis dafür finde ich im direkten Vergleich zum Selbstdesign zu hoch. Außerdem kann ich so Hardware und Firmware aufeinander abstimmen.

Telegram-Sprachnachrichten als Übergangslösung

Guter Punkt, das ist aktuell tatsächlich untererklärt. Was du brauchst:

1. Einen Bot-Token von @BotFather in Telegram (dafür hab ich noch keine eigene Anleitung verlinkt, hol ich nach — kurz gesagt: /newbot an @BotFather schicken, Namen vergeben, Token bekommen).
2. Den Telegram-Bot-Dienst installieren und mit dem Token + der Adresse deiner Hannah-Core-Instanz konfigurieren.
3. Deinen Telegram-Account einmalig mit deinem Hannah-Nutzerprofil verknüpfen — das läuft über die WebUI, /start beim Bot zeigt dir dafür den Link an, wenn dein Account noch nicht verknüpft ist.

Danach gehen Sprachnachrichten direkt an die gleiche STT/NLU-Pipeline wie ein Satellit. Ich ergänze dazu die fehlende Anleitung im Repo.

Mini-Web-Frontend für Text/Sprache

Du hast tatsächlich schon selbst den richtigen Datenpunkt gefunden: textCommand auf der iobroker.hannah-Adapterinstanz — den einfach per Vis-Widget (oder sonstwie) mit ack=false beschreiben, und der Text geht direkt in dieselbe Pipeline wie Satellit/Telegram, inklusive NLU und Antwort. Das funktioniert schon jetzt, ganz ohne zusätzliches Frontend.

Ein Hinweis dazu aber: Die WebUI ist trotzdem kein rein optionales Extra, sondern faktisch Pflicht — Einstellungen, Nutzerverwaltung und auch die Telegram-Kontoverknüpfung laufen ausschließlich darüber. Für die reine Sprach-/Textsteuerung im Alltag brauchst du sie nicht ständig offen, aber zum Einrichten kommst du nicht drumrum.

Die WebUI selbst bringt außerdem schon ein Dockerfile im Repo mit — fertige Images stelle ich aktuell nicht bereit, aber du kannst sie dir selbst bauen.

Docker für Core / Telegram / VoiceID

Ehrliche Antwort: Aktuell gibt's das nicht, alle drei laufen nativ per systemd-Skript (install.sh + Service-Unit), kein Docker-Image existiert bisher. Und bei Core bin ich mir ehrlich gesagt selbst nicht sicher, wie unkompliziert das würde — Core will ja auch lokal faster-whisper und Piper nutzen können, und das sind keine reinen HTTP-Backends wie Ollama, sondern lokale Modelle/Binaries, teils mit GPU-Bezug. Das lässt sich in Docker sicher lösen (Modelle als Volume, GPU-Passthrough), aber ich hab's ehrlich gesagt noch nicht ausprobiert und kann dir nicht seriös versprechen, dass es reibungslos läuft. Wenn du remote STT (faster-whisper-server) und Cloud-TTS (Azure/Polly) statt der lokalen Varianten nutzt, sollte es deutlich einfacher sein, weil dann auch Core nur noch HTTP-Backends anspricht. Ich schau's mir an, kann aber noch nichts Konkretes zusagen.

AMD Strix Halo für Ollama/faster-whisper-server

Aus Hannah-Core-Sicht: völlig egal, welche GPU dahintersteckt. Ollama wird nur per HTTP angesprochen, faster-whisper-server (wenn remote betrieben) ebenso — beides sind für Core reine HTTP-Backends, ohne CUDA/Metal-spezifischen Code auf meiner Seite. Die "Apple Silicon / NVIDIA"-Empfehlung im Vorstellungspost ist rein informell (bessere STT-Erfahrungswerte), keine harte Einschränkung. Ob ROCm/Vulkan auf Strix Halo für Ollama und faster-whisper-server selbst gut performt, müsstest du bei den jeweiligen Projekten nachlesen — aber technisch spricht von meiner Seite nichts dagegen, das würde ich auch gern von dir hören, falls du's ausprobierst!

Danke nochmal fürs genaue Hinschauen und die guten Fragen — genau sowas hilft mir, die Doku an den richtigen Stellen nachzuschärfen.

Liebe Grüße
Leonie

[Leonie]

Hallo zusammen,

seit meinem letzten Update Ende Juni ist einiges passiert, hier ein kurzer Überblick:

✨ Neue Funktionen

• Ein Activity Log: Hannah protokolliert jetzt, was wann über welchen Kanal erkannt und getan wurde, inklusive Sprachaufnahme — abrufbar über eine neue "Verlauf"-Seite in der WebUI.
• Eine Nachrichten-Mailbox: Nutzer können sich gegenseitig Nachrichten hinterlassen, die beim nächsten Gespräch abgespielt werden, inklusive Antwortfunktion — auch dafür gibt's jetzt eine eigene Seite in der WebUI.
• Wecker und Timer wurden grundlegend überarbeitet (volle Sprachsteuerung: setzen, löschen, abfragen, stoppen).
• Die alten "Routinen" sind jetzt komplett in die Trigger-Engine aufgegangen — ein Konzept weniger, dafür flexibler (auch per Sprachphrase auslösbar, direkt im Trigger-Builder der WebUI).

🖥️ WebUI
Hat sich seit der letzten Vorstellung nochmal deutlich weiterentwickelt:

• Berechtigungssystem — Zugriff richtet sich jetzt nach Trust-Level, Admin-Bereiche (User-/Gruppenverwaltung) sind wirklich abgeschottet statt nur versteckt.
• Self-Service-Seite (/me) — jeder kann ohne Admin-Rechte sein Passwort ändern, Telegram verknüpfen und eigene Wecker verwalten.
• BLE-Tags und Fahrzeuge haben jetzt eigene Verwaltungsseiten statt rohem JSON in den Settings.
• No-Code-Editor für Trigger/Settings verbessert — Geräte/Zustände per Dropdown statt ioBroker-State-ID von Hand eintippen.
• Satelliten-Seite zeigt jetzt Firmware-Version, hat einen Update-Button und einen Toggle fürs automatische Weiterzuhören nach Smalltalk.
• Responsive/Mobile — Listenseiten laufen jetzt als Karten-Layout auf dem Handy statt seitlich scrollender Tabellen.
• PWA-Support — lässt sich wie eine App installieren (Add to Home Screen/Desktop).

🔧 Hardware
Die Satelliten-Platine ist jetzt in Revision 5 unterwegs: vier Mikrofone statt zwei (für Beamforming), externe Antenne, überarbeitetes Routing. Beim Bringup gab's einiges an Mikrofon-Ärger — falsches Clock-Timing, DMA-Limits, Verstärkungsprobleme — am Ende musste ich Beamforming vorerst wieder zugunsten von sauberem Audio bei 16kHz zurückstellen. Nicht mein schönster Monat, aber die Satelliten laufen jetzt stabil im Alltag.

🎙️ Wake-Word-Qualität
Ein größerer Debugging-Marathon: Falsche Quantisierungs-Skalierung im Modell (Faktor 5 daneben!) und ein durch ein IDF-Update kaputtes Rauschunterdrückungs-Modul haben lange für schlechte Erkennung gesorgt. Beides gefunden und behoben, dazu ordentliches On-Device-Debug-Tooling gebaut, um sowas beim nächsten Mal schneller zu finden.

🛡️ Stabilität
Diverse Speicher-/Absturz-Themen bei den Satelliten behoben (Heap-Erschöpfung durch falsche RAM-Zuordnung, hängende OTA-Updates in bestimmten Zuständen) sowie ein Paket-Reihenfolge-Bug im Proxy, der zu Audio-Artefakten führen konnte.

🗣️ Zuletzt
Die Sprechererkennung (Voice-ID) läuft jetzt direkt in Hannah Core statt nur über den optionalen Proxy — damit funktioniert sie jetzt auch ohne Proxy zuverlässig, und das bisher tote Voice-Enrollment per gRPC ist jetzt tatsächlich nutzbar.

📚 Doku
Sowohl im Hauptrepo (README, jetzt je Komponente ein eigenes) als auch in der WebUI (README + Nutzungsanleitung je Seite) wurde die Dokumentation deutlich überarbeitet und war teils ziemlich veraltet — sollte jetzt wieder verlässlicher sein.

Insgesamt viel unter der Haube, aber auch einiges, das man direkt merkt. Fragen wie immer gerne hier im Thread!

Liebe Grüße
Leonie