Hannah — Open Source Smart-Home-Sprachassistentin

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:

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?
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.
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?
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:

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).
Den Telegram-Bot-Dienst installieren und mit dem Token + der Adresse deiner Hannah-Core-Instanz konfigurieren.
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

Walter.O.

Gibt es eigentlich eine bestimmte Reihenfolge wie zu Installieren ist.?
Bei mir Funktioniert es nicht, bei Hanna.0 ist die Instanz ohne Inhalt

Leonie

Du brauchst den Adapter im ioBroker und den Core irgendwo anders, theoretisch auch auf dem ioBroker. Mehr nicht.
Dann im Adapter die Adresse vom Core eingeben und fertig.

Walter.O.

@Leonie
https://github.com/NurPech/ioBroker.hannah.git
Installation Adapter gibt folgende Fehlermeldung

$ iobroker url https://github.com/NurPech/ioBroker.hannah.git --host Mini-pc-Master --debug

install NurPech/ioBroker.hannah#8f3c2d4d24f57bf7e1c9556e164c4ef2d20cba03

Installing NurPech/ioBroker.hannah#8f3c2d4d24f57bf7e1c9556e164c4ef2d20cba03... (System call)

npm warn skipping integrity check for git dependency ssh://git@github.com/NurPech/ioBroker.hannah.git

npm warn deprecated npmlog@4.1.2: This package is no longer supported.

npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported

npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported

npm warn deprecated gauge@2.7.4: This package is no longer supported.

> usocket@0.3.0 install> node-gyp rebuild

gyp info it worked if it ends with ok

gyp info using node-gyp@7.1.2

gyp info using node@22.23.2 | linux | x64

(node:1145312) [DEP0060] DeprecationWarning: The `util._extend` API is deprecated. Please use Object.assign() instead.(Use `node --trace-deprecation ...` to show where the warning was created)

gyp info find Python using Python version 3.14.4 found at "/usr/bin/python3"

gyp ERR! UNCAUGHT EXCEPTION

gyp ERR! stack TypeError: Cannot assign to read only property 'cflags' of object '#<Object>'gyp ERR! stack at createConfigFile (/opt/iobroker/node_modules/usocket/node_modules/node-gyp/lib/configure.js:117:21)gyp ERR! stack at /opt/iobroker/node_modules/usocket/node_modules/node-gyp/lib/configure.js:84:9

gyp ERR! System Linux 7.0.0-30-genericgyp ERR! command "/usr/bin/node" "/opt/iobroker/node_modules/usocket/node_modules/.bin/node-gyp" "rebuild"gyp ERR! cwd /opt/iobroker/node_modules/usocketgyp ERR! node -v v22.23.2gyp ERR! node-gyp -v v7.1.2gyp ERR! Node-gyp failed to build your package.gyp ERR! Try to update npm and/or node-gyp and if it does not help file an issue with the package author.

added 5 packages in 1m398 packages are looking for funding run `npm fund` for details

upload [5] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/blockly.js blockly.js application/javascript

upload [4] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/hannah.png hannah.png image/png

upload [3] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/index.html index.html text/html

upload [2] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/index_m.html index_m.html text/html

upload [1] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/style.css style.css text/css

upload [0] hannah.admin /opt/iobroker/node_modules/iobroker.hannah/admin/tab.html tab.html text/html

Updating objects from io-package.json for adapter "hannah" with version "1.0.2"

Process exited with code 0

Wenn ich dann eine Instanz installiere, ist die Seite wo die Einstellungen sein sollten leider komplett Leer.
System:
Ubuntu 26.04.1 LTS
Plattform: linux
NPM: 10.9.8
Freier Festplattenspeicher: 56.7 GB
Aktive Instanzen: 51
Pfad: /opt/iobroker/
Betriebssystem: linux
Architektur: x64
CPUs: 4
Geschwindigkeit: 800 MHz
Modell: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz
RAM: 15 GB
Node.js: v22.23.2
NPM: 10.9.8
Pfad: /opt/iobroker/

Core und Adapter im selbem System.
Kann man Testen ob der Core Läuft?

Leonie

Hallo,

danke fürs Melden! Ich hab mir den Log genauer angeschaut — das ist mit hoher Wahrscheinlichkeit kein Hannah-Problem, sondern etwas, das rein zufällig im selben Log-Ausschnitt auftaucht:

Der gyp-Fehler betrifft usocket unter /opt/iobroker/node_modules/usocket/ — das liegt auf der Root-Ebene deiner ioBroker-Installation, nicht unter node_modules/iobroker.hannah/. usocket ist keine Abhängigkeit des Hannah-Adapters (hab package.json/package-lock.json geprüft), sondern eine optionale Abhängigkeit von iobroker.js-controller selbst, die npm zufällig beim selben Installationslauf mitbaut.

Der eigentliche Fehler (Cannot assign to read only property 'cflags') ist ein bekanntes Kompatibilitätsproblem zwischen dem in usocket gebundelten alten node-gyp (v7.1.2) und neueren Node.js-Versionen — bei dir Node.js v22.23.2, damit kommt dieser node-gyp nicht klar.

Wichtig: Trotz des Fehlers lief die eigentliche Hannah-Installation danach sauber durch — Admin-Dateien hochgeladen, Objekte aktualisiert, Exit-Code 0. usocket hat vermutlich einen reinen JS-Fallback, falls der native Build scheitert, das ist nur ein optionaler Performance-Baustein.

Kannst du kurz bestätigen, dass die Hannah-Instanz bei dir tatsächlich läuft (grüner Haken in der Instanzen-Übersicht, keine Fehler im Log der Instanz selbst)? Falls ja, kannst du die gyp-Meldung getrost ignorieren.

Zur leeren Einstellungsseite: Welchen Admin (Version) verwendest du?

Test ob der Core läuft, mit systemctl status hannah-core

Liebe Grüße
Leonie

Walter.O.

Admin Version 7.8.23
systemctl status hannah-core
Unit hannah-core.service could not be found.
Hanna.0 ist komplett Rot

manne01

@Leonie Danke für Deine Rückmeldungen an mich in #43 die ich gut nachvollziehen kann!

Zum Satellite: Ich möchte keine Sonderwege anfangen und warte lieber bzw. beteilige mich gerne an dem von Dir vorgeschlagenen Weg.

Telegram: ... kriege ich dann hoffentlich erstmal hin. Geht evtl. wohl auch im Browser, also ohne native Mobile App und damit auch auf meinem Wandtablet bzw. allen browserfähigen Geräten im Haushalt - das wäre ja schonmal etwas universeller nutzbar?

iobroker.hannah Adapter: Ich habe im Beta Repo geschaut aber den noch nicht gefunden. Kann man schon abschätzen wann der dort kommen kann?

WebUI: Das habe ich schonmal per Docker installiert bekommen. Die WebUI wartet nun erstmal auf eine Core.

Docker-Container für die 4 Backendservices Core / Telegram / VoiceID / Proxy :
Meine "Standardumgebung" für allerlei Container ist derzeit mein Synology NAS. Ich weiß schon darüber kann man streiten... Und meine Synology hat keine GPU (bzw. nur einen durchgereichten USB-Coral für Frigate Container). Daneben existiert der Strix Halo "KI-Server", den ich eigentlich nur als HTTP-Server für KI-Workloads und nicht als erweiterten Anwendungs- oder Docker-Host verwenden wollte.

Leonie: "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 möchte alles lokal im Heimnetz betreiben und hatte gehofft, dass die Hannah-Backendservices eigentlich keine "größeren" GPU-Anforderungen haben weil alles lokal passiert (und meine CPU hoffentlich ausreicht) und dass ich das in einem Container unterbringen kann. Oder dass ich alle KI-Dienste wie ollama, faster-whisper und piper auch per HTTP einbinden könnte.

Nun habe ich heute mal eine Docker Compose gebaut, um den WebUI und einen "Backendservices" Container aufzubauen. Mein Ansatz war einfach alle 4 Backendservices in einem Docker-Container laufen zu lassen. Ehrlich gesagt würde ich gerne auch die WebUI noch im selben Container mitbetreiben wollen solange es keinen guten z.B. Grund (Performance, Releasezyklus etc.) für die Auslagerung gibt damit das Ganze zumindest zu Beginn kompakter wird und man später skalieren kann. Beim Bauen des Containers (oder nach dem Start) wollte ich die 4 Backend-Installscripte laden und ausführen. Aber mit dem ganzen Vorhaben bin ich grundsätzlich leider erstmal ziemlich stecken geblieben.

Erstes Problem war, dass die install.sh beim Download abgebrochen ist. Nach Debugging ergab sich eine Rückmeldung vom Repo 429 too many requests. Würde mich wundern, wenn ich in ein echtes Rate limit gelaufen wäre, aber vllt. war hier die Curl-Clientangabe aus dem Container leer oder verdächtig oder sowas. Jedenfalls hat es mit einem anderen vorgegebenen Header dann sofort geklappt:

curl -sf \
    -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
    "${AUTH_HEADER[@]}" \
    -o "$TMPFILE" \
    "${UPDATE_SERVER_URL}/releases/${LATEST_VERSION}?channel=${CORE_CHANNEL}"

Der Aufruf install.sh gab nur den Fehlercode 22 zurück. @Leonie Vielleicht kannst Du in dem Bereich die install-Scripte noch Client-durchgängiger oder ansonsten gesprächiger machen für Download-Fehler?

Nun zum Hauptproblem - dass mir erst klar wurde als der Download gelöst war ...
Ich habe auf meinem Synology NAS Host garkein systemd das ich in Containern nutzen könnte - und es ist mir auch nicht gelungen das irgendwie in Containern trotzdem hinzurkriegen. Könnte lösbar sein, aber so tief bin ich einfach nicht drin.
Aber dann passen auch dazu die install-Scripte nicht richtig, weil Build/Install und Run dort nicht getrennt ist.
Nun müsste ich mir also 4 eigene Installscripte schreiben und pflegen etc. aber das möchte ich natürlich vermeiden und irgendwie trotzdem eine Dockerinstallation hinbekommen.

Daher will ich das erstmal hier zur Diskussion stellen: Ist es denkbar auch mit den Hannah-Backendservices in Container zu kommen? Vielleicht bin ich da verwöhnt oder verzogen, aber es geht damit halt so Richtung "Lego"

Freue mich auf Rückmeldungen!

Leonie

Hi

@manne01 sagte:

Telegram: ... kriege ich dann hoffentlich erstmal hin. Geht evtl. wohl auch im Browser, also ohne native Mobile App und damit auch auf meinem Wandtablet bzw. allen browserfähigen Geräten im Haushalt - das wäre ja schonmal etwas universeller nutzbar?

Klar, du verbindest ja deinen Telegramaccount, egal wo oder wie du den nutzt. Letzendlich läuft das über die Backendserver von Telegram

@manne01 sagte:

iobroker.hannah Adapter: Ich habe im Beta Repo geschaut aber den noch nicht gefunden. Kann man schon abschätzen wann der dort kommen kann?

Der ist eigentlich im Beta-Repository. Ich kann das nicht nachvollziehen. Gerade eben konnte ich den Adapter auch über das Beta-Repository in einem frischen ioBroker installieren.

@manne01 sagte:

Ich möchte alles lokal im Heimnetz betreiben und hatte gehofft, dass die Hannah-Backendservices eigentlich keine "größeren" GPU-Anforderungen haben weil alles lokal passiert (und meine CPU hoffentlich ausreicht) und dass ich das in einem Container unterbringen kann. Oder dass ich alle KI-Dienste wie ollama, faster-whisper und piper auch per HTTP einbinden könnte.

Mit "Remote" war gemeint, außerhalb von Core. Ob das nun bei dir im Heimnetz oder irgendeiner Cloud läuft ist dabei egal, sorry falls das verwirrend war. Whisper funktioniert mit reiner CPU schon ziemlich gut, aber TTS will lieber GPUs nutzen. Du kannst es ja einfach auf deiner CPU-Hardware testen, entweder bist du mit der Qualität von Piper zu Frieden oder nicht. Ich bin es mit der CPU von einem Raspberry Pi 5 nicht und weil ich keine Lust hatte mir großartig bessere Hardware zu suchen, habe ich einfach die Azure Speech Services eingebaut. Purer Pragmatismus. Tut mir leid wenn ich dir an der Stelle nichts "besseres" sagen kann.

@manne01 sagte:

Erstes Problem war, dass die install.sh beim Download abgebrochen ist.

Das kann sein, weil die Installscripte die Daten eben nicht aus dem github laden, sondern von meinem Server. Der steht bei mir zu Hause. Naturgemäß kann ich da keinen SLA bieten und ich kann nicht sicher stellen das der Service 24/7 zur Verfügung steht.

@manne01 sagte:

u in dem Bereich die install-Scripte noch Client-durchgängiger oder ansonsten gesprächiger machen für Download-Fehler?

Ja, steht auf der ToDo, wenn vielleicht auch etwas anders als du geschrieben hast.

@manne01 sagte:

Aber dann passen auch dazu die install-Scripte nicht richtig, weil Build/Install und Run dort nicht getrennt ist.

Korrekt, die Install-Scripte decken das nicht ab. Offensiv gefragt, warum sollten sie es auch? Die Install-Scripte laden die Tar-Balls und Binaries von meinem Server runter. Erstellen die systemd-Files und geben im Optimalfall eine Kurzanleitung was zu tun ist. Da bin ich mir aber grade selbst nicht mehr so sicher. Was du machen müsstest, ist es den Download selbst auszuführen und dann in ein Image zu packen. Bisher habe ich noch nicht versucht die Software in Container zu stecken, ich kann es mal versuchen, aber versprechen kann ich nichts.

@Walter.O. sagte:

systemctl status hannah-core
Unit hannah-core.service could not be found.

~~Wie hast du Core installiert? Kannst du mir das sagen?~~ Das war eine Fehlinformation von mir. Die Unit heißt einfach nur "hannah". Bitte also systemctl status hannah

@Walter.O. sagte:

Admin Version 7.8.23

~~Ich fürchte das geht auf meine Kappe. Ich denke Admin 7.8.23 ist zu alt und es wird Admin 7.9 gebraucht. Aber ich habe wohl nie das Requirement angepasst. Ich brauche ein wenig Zeit für einen Test.~~
Das alleine ist nicht das Problem. Der Adapter läuft in einer frischen ioBroker Installation mit admin 7.8.23 problemlos. Da ist irgendwas bei dir falsch, sorry das ich so vage bin. Wenn du die Einstellungen öffnest, hast du dann Fehler in der Browserkonsole?
Ich denke ich habe es gelöst. Du hast laut Log versucht den Adapter von Github zu installieren? Das ist eigentlich gar nicht supported. Deinstalliere den Adapter bitte wieder und installiere ihn über das Beta-Repository oder meintwegen noch über NPM, aber nicht über Github.

@Walter.O. sagte:

Hanna.0 ist komplett Rot

Ok, passt. War blöd von mir ausgedrückt. Wenn du nicht in den Admin kommst, kannst du keine Konfiguration erstellen und ohne Konfiguration startet der nicht.

Ich hoffe ich habe alles beantwortet :D

Liebe Grüße
Leonie

Walter.O. · Admin Version 7.8.23

@Leonie hanna
Admin auf 7.9 Aktualisiert
Hanna.0 Läuft
Core Installation:

curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh
#!/usr/bin/env bash
# install.sh — Hannah Core installer / updater
#
# Downloads Hannah Core from the Update Server and installs it as a systemd service.
#
# Usage:
#   ./install.sh              # install or update
#   ./install.sh --uninstall  # remove service (keeps config)
#
# Env vars:
#   UPDATE_SERVER_URL    Base URL of the Hannah Update Server
#   UPDATE_SERVER_TOKEN  Bearer token for the Update Server (optional, only required for non-public channels)
#   CORE_CHANNEL         Channel to install from (default: core-stable)
#
set -euo pipefail

# ── CONFIG ────────────────────────────────────────────────────────────────────
UPDATE_SERVER_URL="${UPDATE_SERVER_URL:-https://hannah-update.sgessinger.de}"
UPDATE_SERVER_TOKEN="${UPDATE_SERVER_TOKEN:-}"
CORE_CHANNEL="${CORE_CHANNEL:-core-stable}"
INSTALL_DIR="/opt/hannah/core"
CONFIG_DIR="/etc/hannah"
SERVICE_NAME="hannah"
SERVICE_FILE="/etc/systemd/system/${SERVICE_NAME}.service"
SERVICE_USER="hannah"
# ──────────────────────────────────────────────────────────────────────────────

info()  { echo "[INFO]  $*"; }
ok()    { echo "[OK]    $*"; }
err()   { echo "[ERROR] $*" >&2; exit 1; }

need() { command -v "$1" &>/dev/null || err "Required tool not found: $1"; }
need python3
need curl
need systemctl

[[ $EUID -eq 0 ]] || err "This script must be run as root (try: sudo bash)."

# ── Uninstall ─────────────────────────────────────────────────────────────────
uninstall() {
   info "Stopping and disabling ${SERVICE_NAME} ..."
   systemctl stop    "${SERVICE_NAME}" 2>/dev/null || true
   systemctl disable "${SERVICE_NAME}" 2>/dev/null || true
   rm -f "${SERVICE_FILE}"
   systemctl daemon-reload
   rm -rf "${INSTALL_DIR}"
   ok "Uninstalled. Config in ${CONFIG_DIR} was kept."
}

[[ "${1:-}" == "--uninstall" ]] && { uninstall; exit 0; }

# ── Download latest release from Update Server ────────────────────────────────
AUTH_HEADER=()
[[ -n "$UPDATE_SERVER_TOKEN" ]] && AUTH_HEADER=(-H "Authorization: Bearer ${UPDATE_SERVER_TOKEN}")

info "Fetching latest core release from ${UPDATE_SERVER_URL} (channel: ${CORE_CHANNEL}) ..."
LATEST_JSON=$(curl -sf \
   "${AUTH_HEADER[@]}" \
   "${UPDATE_SERVER_URL}/latest?channel=${CORE_CHANNEL}")
LATEST_VERSION=$(echo "$LATEST_JSON" | python3 -c "import sys,json; print(json.load(sys.stdin)['version'])")
info "Latest version: ${LATEST_VERSION}"

TMPFILE=$(mktemp /tmp/hannah-core-XXXXXX.tar.gz)
trap 'rm -f "$TMPFILE"' EXIT

curl -sf \
   "${AUTH_HEADER[@]}" \
   -o "$TMPFILE" \
   "${UPDATE_SERVER_URL}/releases/${LATEST_VERSION}?channel=${CORE_CHANNEL}"
ok "Downloaded ${LATEST_VERSION}."

# ── Extract to install dir ────────────────────────────────────────────────────
mkdir -p "${INSTALL_DIR}"
tar -xzf "$TMPFILE" -C "${INSTALL_DIR}"
ok "Extracted to ${INSTALL_DIR}."

# ── Python venv ───────────────────────────────────────────────────────────────
VENV="${INSTALL_DIR}/venv"
if [[ ! -d "$VENV" ]]; then
   info "Creating Python venv ..."
   python3 -m venv "$VENV"
fi

info "Installing Python dependencies ..."
"${VENV}/bin/pip" install --upgrade pip --quiet
"${VENV}/bin/pip" install --quiet -r "${INSTALL_DIR}/requirements.txt"
ok "Python dependencies installed."

# ── Service user ──────────────────────────────────────────────────────────────
if ! id "$SERVICE_USER" &>/dev/null; then
   info "Creating system user '${SERVICE_USER}' ..."
   useradd -r -s /sbin/nologin "$SERVICE_USER"
fi
chown -R "${SERVICE_USER}:${SERVICE_USER}" "${INSTALL_DIR}"

# ── Config directory ──────────────────────────────────────────────────────────
if [[ ! -d "$CONFIG_DIR" ]]; then
   mkdir -p "$CONFIG_DIR"
   chown "${SERVICE_USER}:${SERVICE_USER}" "$CONFIG_DIR"
   info "Created ${CONFIG_DIR} — place your config.yaml there."
fi

# ── systemd unit ──────────────────────────────────────────────────────────────
install -m 644 "${INSTALL_DIR}/deploy/hannah.service" "$SERVICE_FILE"
ok "Service unit installed."

systemctl daemon-reload

# ── Start / Restart ───────────────────────────────────────────────────────────
if [[ ! -f "${CONFIG_DIR}/config.yaml" ]]; then
   ok "Installed ${LATEST_VERSION}. Place config.yaml in ${CONFIG_DIR} and run:"
   ok "  systemctl enable --now ${SERVICE_NAME}"
   exit 0
fi

if systemctl is-enabled --quiet "${SERVICE_NAME}" 2>/dev/null; then
   info "Restarting ${SERVICE_NAME} ..."
   systemctl restart "${SERVICE_NAME}"https://github.com/NurPech/Hannah.git
else
   info "Enabling and starting ${SERVICE_NAME} ..."
   systemctl enable --now "${SERVICE_NAME}"
fi

ok "${SERVICE_NAME} is running (${LATEST_VERSION})."
systemctl status "${SERVICE_NAME}" --no-pager -l || true

OliverIO

@manne01 sagte:

Ich habe auf meinem Synology NAS Host garkein systemd das ich in Containern nutzen könnte - und es ist mir auch nicht gelungen das irgendwie in Containern trotzdem hinzurkriegen. Könnte lösbar sein, aber so tief bin ich einfach nicht drin.

container sind eigentlich isoliert. warum solltest du systemd des host betriebssystem nutzen? das ist nicht im sinne des containerkonzepts
Dein image betriebssystem (wenn man das richtige wählt) bringt doch sein eigenes systemd mit.

erstelle dein dockerfile so, wie wenn du es auf einem rechner installierst.
das image ist ja nix anderes als das dateisystem für ein rechner, das bei der erstellung dynamisch zusammengebaut wird.
habe jetzt nicht im kopf was du mit systemd machen willst? aber ich vermute du willst die hannah teile als service registrieren. also genau so wie wenn du es auf einem rechner machen willst.
wenn nicht alles durch erstellen von dateien am richtigen ort erfolgen kann (bei der imageersellung läuft das containerbetriebssystem ja noch nicht) musst du ggfs startskripte erstellen, die das dann nach containerstart erledigen. docker bringt aber ein paar befehle mit
den iobroker buanet container kannst du mal anschauen, da werden diese ganzen methodiken eingesetzt
https://github.com/buanet/ioBroker.docker/blob/main/debian12/Dockerfile
https://github.com/buanet/ioBroker.docker/tree/main/debian12/scripts

für startskript siehe im dockerfile unter entrypoint

manne01

Es tut mir leid - ich hab wohl einfach nach dem Repo umschalten nicht Refresh gedrückt. Ist mir glaub ich schonmal passiert... [[kann/sollte der Refresh nicht nach dem Speichern schon ausgelöst werden?]]
Ich bin auf ioBroker v7.8.23 und konnte den Hannah Adapter aus dem Beta Repo vollkommen reibungslos installieren.

@Leonie sagte:

Korrekt, die Install-Scripte decken das nicht ab. Offensiv gefragt, warum sollten sie es auch?

Ja, ganz klar, das war auch keine Erwartung oder sowas, sondern wirklich nur meine Erkenntnis nach dem ganzen Rumprobieren. Hatte irgendwie gedacht ich könnte es aus den Bestandteilen zusammensetzen.

@OliverIO sagte:
habe jetzt nicht im kopf was du mit systemd machen willst? aber ich vermute du willst die hannah teile als service registrieren. also genau so wie wenn du es auf einem rechner machen willst.

Genau, ich möchte quasi die bisher angedachte systemd-Struktur im Container nachbilden und die Backendservices als systemd Services laufen lassen. Ist mir aber eben nicht gelungen und wahrscheinlich macht das auch keinen Sinn, weil ich dann die Konzepte vermische.

Ganz eigene Start-Scripte möchte bzw. kann ich ehrlich gesagt nicht schreiben, ich glaube das übersteigt einfach meine Fähigkeiten und muss ja auch gepflegt werden.

Leonie

theoretisch müsstest du die Install-Scripte beim Dockerbuild ausführen können. also im Dockerfile entsprechende RUN Deklarationen.

OliverIO

@Leonie

ich habe gerade mal deine installationsanweisungen in die ki geworfen.
ki empfiehlt verschiedene images zu bauen.

hier mal copy/paste der antwort

aus sicherheitssicht gibt es ebenfalls noch einen hinweis zu UPDATE_SERVER_TOKEN weiter unten

xxx---xxx

Ja. Auf Basis der aktuellen Installer würde ich Hannah nicht als einen einzigen Container mit systemd betreiben, sondern jede Komponente als eigenen Container. Das passt deutlich besser zu Docker und bildet die vorhandene Architektur sauber ab.

Die offiziellen Services starten Core mit python main.py -c /etc/hannah/config.yaml, Proxy mit hannah-proxy --config ..., Telegram entsprechend mit main.py --config ... und Voice-ID mit app.py --config ....

Empfohlene Verzeichnisstruktur

hannah-docker/
├── docker-compose.yml
├── .env
│
├── core/
│   ├── Dockerfile
│   └── config/
│       └── config.yaml
│
├── proxy/
│   ├── Dockerfile
│   └── config/
│       └── config.yaml
│
├── telegram/
│   ├── Dockerfile
│   └── config/
│       └── config.yaml
│
├── voiceid/
│   ├── Dockerfile
│   ├── config/
│   │   └── config.yaml
│   └── voice_profiles/
│
└── data/
    └── core/

Dabei würde ich AutoDeploy zunächst weglassen. Der vorhandene AutoDeploy-Service ist darauf ausgelegt, andere systemd-Services auf dem Host zu verwalten. Das passt konzeptionell nicht gut zu Docker; Updates sollte dann Docker/Compose übernehmen.

1. Core

Da das Release vom Hannah-Update-Server kommt, bauen wir das Image ähnlich wie der Installer – nur ohne systemd.

core/Dockerfile:

FROM python:3.11-slim

ARG UPDATE_SERVER_URL=https://hannah-update.sgessinger.de
ARG CORE_CHANNEL=core-stable
ARG UPDATE_SERVER_TOKEN=""

ENV PYTHONUNBUFFERED=1
ENV HOME=/opt/hannah/core

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        ca-certificates \
        tar \
        portaudio19-dev \
        build-essential \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /opt/hannah/core

RUN set -eux; \
    AUTH=""; \
    if [ -n "$UPDATE_SERVER_TOKEN" ]; then \
        AUTH="-H Authorization:\ Bearer\ $UPDATE_SERVER_TOKEN"; \
    fi; \
    LATEST_JSON="$(curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/latest?channel=${CORE_CHANNEL}")"; \
    VERSION="$(printf '%s' "$LATEST_JSON" \
        | python -c 'import json,sys; print(json.load(sys.stdin)["version"])')"; \
    echo "Installing Hannah Core ${VERSION}"; \
    curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/releases/${VERSION}?channel=${CORE_CHANNEL}" \
        -o /tmp/hannah-core.tar.gz; \
    tar -xzf /tmp/hannah-core.tar.gz -C /opt/hannah/core; \
    rm /tmp/hannah-core.tar.gz

RUN pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r requirements.txt

RUN useradd --system \
        --home-dir /opt/hannah/core \
        --shell /usr/sbin/nologin \
        hannah \
    && chown -R hannah:hannah /opt/hannah/core

USER hannah

EXPOSE 50051
EXPOSE 7775/udp

CMD ["python", "main.py", "-c", "/etc/hannah/config.yaml"]

Der Core-Installer verwendet aktuell den Channel core-stable und installiert nach /opt/hannah/core; genau daran orientiert sich dieses Image.

2. Proxy

Beim Proxy ist etwas Besonderes zu beachten: Das Release unterscheidet zwischen amd64 und arm64. Das macht auch der Originalinstaller automatisch.

proxy/Dockerfile:

FROM debian:bookworm-slim

ARG UPDATE_SERVER_URL=https://hannah-update.sgessinger.de
ARG PROXY_CHANNEL=proxy-stable
ARG UPDATE_SERVER_TOKEN=""
ARG TARGETARCH

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        ca-certificates \
        tar \
        file \
        python3 \
    && rm -rf /var/lib/apt/lists/*

RUN set -eux; \
    case "${TARGETARCH}" in \
        amd64) ARCH="amd64" ;; \
        arm64) ARCH="arm64" ;; \
        *) echo "Unsupported architecture: ${TARGETARCH}"; exit 1 ;; \
    esac; \
    CHANNEL="${PROXY_CHANNEL}-${ARCH}"; \
    AUTH=""; \
    if [ -n "$UPDATE_SERVER_TOKEN" ]; then \
        AUTH="-H Authorization:\ Bearer\ $UPDATE_SERVER_TOKEN"; \
    fi; \
    LATEST_JSON="$(curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/latest?channel=${CHANNEL}")"; \
    VERSION="$(printf '%s' "$LATEST_JSON" \
        | python3 -c 'import json,sys; print(json.load(sys.stdin)["version"])')"; \
    echo "Installing Hannah Proxy ${VERSION} (${ARCH})"; \
    curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/releases/${VERSION}?channel=${CHANNEL}" \
        -o /tmp/hannah-proxy.tar.gz; \
    mkdir /tmp/hannah-proxy; \
    tar -xzf /tmp/hannah-proxy.tar.gz -C /tmp/hannah-proxy; \
    install -m 755 /tmp/hannah-proxy/hannah-proxy /usr/local/bin/hannah-proxy; \
    rm -rf /tmp/hannah-proxy /tmp/hannah-proxy.tar.gz

RUN useradd --system \
    --no-create-home \
    --shell /usr/sbin/nologin \
    hannah

USER hannah

EXPOSE 7775/udp

CMD ["hannah-proxy", "--config", "/etc/hannah-proxy/config.yaml"]

3. Telegram

telegram/Dockerfile:

FROM python:3.11-slim

ARG UPDATE_SERVER_URL=https://hannah-update.sgessinger.de
ARG TELEGRAM_CHANNEL=telegram-stable
ARG UPDATE_SERVER_TOKEN=""

ENV PYTHONUNBUFFERED=1
ENV HOME=/opt/hannah/telegram

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        ca-certificates \
        tar \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /opt/hannah/telegram

RUN set -eux; \
    AUTH=""; \
    if [ -n "$UPDATE_SERVER_TOKEN" ]; then \
        AUTH="-H Authorization:\ Bearer\ $UPDATE_SERVER_TOKEN"; \
    fi; \
    LATEST_JSON="$(curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/latest?channel=${TELEGRAM_CHANNEL}")"; \
    VERSION="$(printf '%s' "$LATEST_JSON" \
        | python -c 'import json,sys; print(json.load(sys.stdin)["version"])')"; \
    echo "Installing Hannah Telegram ${VERSION}"; \
    curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/releases/${VERSION}?channel=${TELEGRAM_CHANNEL}" \
        -o /tmp/hannah-telegram.tar.gz; \
    tar -xzf /tmp/hannah-telegram.tar.gz -C /opt/hannah/telegram; \
    rm /tmp/hannah-telegram.tar.gz

RUN pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r requirements.txt

RUN useradd --system \
        --home-dir /opt/hannah/telegram \
        --shell /usr/sbin/nologin \
        hannah \
    && chown -R hannah:hannah /opt/hannah/telegram

USER hannah

CMD ["python", "main.py", "--config", "/etc/hannah-telegram/config.yaml"]

Das entspricht dem aktuellen systemd-Startkommando des Telegram-Bots.

4. Voice-ID

Voice-ID benötigt laut Installer PyTorch, Torchaudio und SpeechBrain. Außerdem nutzt die normale Installation /mnt/hannah_mem als 128-MB-RAM-Disk. In Compose können wir das viel eleganter über tmpfs lösen.

voiceid/Dockerfile:

FROM python:3.11-slim

ARG UPDATE_SERVER_URL=https://hannah-update.sgessinger.de
ARG VOICEID_CHANNEL=voiceid-stable
ARG UPDATE_SERVER_TOKEN=""

ENV PYTHONUNBUFFERED=1
ENV HOME=/opt/hannah/voiceid

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        ca-certificates \
        tar \
        libsndfile1 \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /opt/hannah/voiceid

RUN set -eux; \
    AUTH=""; \
    if [ -n "$UPDATE_SERVER_TOKEN" ]; then \
        AUTH="-H Authorization:\ Bearer\ $UPDATE_SERVER_TOKEN"; \
    fi; \
    LATEST_JSON="$(curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/latest?channel=${VOICEID_CHANNEL}")"; \
    VERSION="$(printf '%s' "$LATEST_JSON" \
        | python -c 'import json,sys; print(json.load(sys.stdin)["version"])')"; \
    echo "Installing Hannah Voice-ID ${VERSION}"; \
    curl -fsSL $AUTH \
        "${UPDATE_SERVER_URL}/releases/${VERSION}?channel=${VOICEID_CHANNEL}" \
        -o /tmp/hannah-voiceid.tar.gz; \
    tar -xzf /tmp/hannah-voiceid.tar.gz -C /opt/hannah/voiceid; \
    rm /tmp/hannah-voiceid.tar.gz

RUN pip install --no-cache-dir --upgrade pip

RUN pip install --no-cache-dir \
        fastapi \
        uvicorn \
        python-multipart \
        pyyaml \
        torch \
        torchaudio \
        --index-url https://download.pytorch.org/whl/cpu

RUN pip install --no-cache-dir speechbrain

RUN useradd --system \
        --home-dir /opt/hannah/voiceid \
        --shell /usr/sbin/nologin \
        hannah \
    && mkdir -p /mnt/hannah_mem /opt/hannah/voiceid/voice_profiles \
    && chown -R hannah:hannah \
        /mnt/hannah_mem \
        /opt/hannah/voiceid

USER hannah

EXPOSE 8080

CMD ["python", "app.py", "--config", "/etc/hannah-voiceid/config.yaml"]

5. docker-compose.yml

Hier kommt alles zusammen:

services:

  hannah-core:
    build:
      context: ./core
      args:
        UPDATE_SERVER_URL: ${UPDATE_SERVER_URL:-https://hannah-update.sgessinger.de}
        UPDATE_SERVER_TOKEN: ${UPDATE_SERVER_TOKEN}
        CORE_CHANNEL: ${CORE_CHANNEL:-core-stable}

    container_name: hannah-core
    restart: unless-stopped

    volumes:
      - ./core/config/config.yaml:/etc/hannah/config.yaml:ro
      - ./data/core:/opt/hannah/core/.tts_cache

    ports:
      - "50051:50051"
      # Nur aktivieren, wenn Satelliten DIREKT mit Core sprechen:
      # - "7775:7775/udp"

    networks:
      - hannah


  hannah-proxy:
    build:
      context: ./proxy
      args:
        UPDATE_SERVER_URL: ${UPDATE_SERVER_URL:-https://hannah-update.sgessinger.de}
        UPDATE_SERVER_TOKEN: ${UPDATE_SERVER_TOKEN}
        PROXY_CHANNEL: ${PROXY_CHANNEL:-proxy-stable}

    container_name: hannah-proxy
    restart: unless-stopped

    depends_on:
      - hannah-core

    volumes:
      - ./proxy/config/config.yaml:/etc/hannah-proxy/config.yaml:ro

    ports:
      - "7775:7775/udp"

    networks:
      - hannah


  hannah-telegram:
    build:
      context: ./telegram
      args:
        UPDATE_SERVER_URL: ${UPDATE_SERVER_URL:-https://hannah-update.sgessinger.de}
        UPDATE_SERVER_TOKEN: ${UPDATE_SERVER_TOKEN}
        TELEGRAM_CHANNEL: ${TELEGRAM_CHANNEL:-telegram-stable}

    container_name: hannah-telegram
    restart: unless-stopped

    depends_on:
      - hannah-core

    volumes:
      - ./telegram/config/config.yaml:/etc/hannah-telegram/config.yaml:ro

    networks:
      - hannah


  hannah-voiceid:
    build:
      context: ./voiceid
      args:
        UPDATE_SERVER_URL: ${UPDATE_SERVER_URL:-https://hannah-update.sgessinger.de}
        UPDATE_SERVER_TOKEN: ${UPDATE_SERVER_TOKEN}
        VOICEID_CHANNEL: ${VOICEID_CHANNEL:-voiceid-stable}

    container_name: hannah-voiceid
    restart: unless-stopped

    volumes:
      - ./voiceid/config/config.yaml:/etc/hannah-voiceid/config.yaml:ro
      - ./voiceid/voice_profiles:/opt/hannah/voiceid/voice_profiles

    tmpfs:
      - /mnt/hannah_mem:size=128m,mode=1777

    expose:
      - "8080"

    networks:
      - hannah


networks:
  hannah:
    driver: bridge

Ganz wichtig: interne Hostnamen

In deinen Configs darfst du bei Docker für die Kommunikation zwischen Containern nicht mehr 127.0.0.1 verwenden.

Für proxy/config/config.yaml also beispielsweise:

proxy_id: hannah-proxy

hannah:
  address: "hannah-core:50051"

udp:
  listen_addr: ":7775"

  # Hier muss die IP des Docker-HOSTS hinein,
  # die deine Satelliten erreichen können.
  advertise_host: "192.168.8.15"

voice_id:
  enabled: true
  base_url: "http://hannah-voiceid:8080"
  timeout_sec: 3.0
  min_confidence: 0.45

Das ist besonders wichtig beim advertise_host: Hier darf nicht hannah-proxy stehen. Die Satelliten befinden sich außerhalb des Docker-Netzes und müssen deshalb die LAN-IP deines Docker-Hosts bekommen.

Für Telegram:

telegram:
  token: "DEIN_BOT_TOKEN"
  allowed_users:
    - 123456789

hannah:
  address: "hannah-core:50051"

`.env`

Im Hauptverzeichnis:

UPDATE_SERVER_URL=https://hannah-update.sgessinger.de

UPDATE_SERVER_TOKEN=DEIN_UPDATE_SERVER_TOKEN

CORE_CHANNEL=core-stable
PROXY_CHANNEL=proxy-stable
TELEGRAM_CHANNEL=telegram-stable
VOICEID_CHANNEL=voiceid-stable

Dann:

docker compose build
docker compose up -d

Logs:

docker compose logs -f hannah-core

Oder alle:

docker compose logs -f

Status:

docker compose ps

Ein Punkt, den ich noch ändern würde

Das Beispiel oben funktioniert, hat aber bei UPDATE_SERVER_TOKEN einen Docker-spezifischen Schönheitsfehler: Ein Token als ARG kann unter Umständen in Build-Metadaten landen.

Für ein dauerhaftes Produktionssetup würde ich deshalb Docker BuildKit Secrets verwenden:

RUN --mount=type=secret,id=update_token \
    UPDATE_SERVER_TOKEN="$(cat /run/secrets/update_token)" \
    ...

und dann in Compose:

build:
  secrets:
    - update_token

Das ist deutlich sauberer als ein Token über ARG.

WebUI

Die WebUI würde ich ebenfalls als eigenen Container integrieren. Da sie laut Projekt ohnehin explizit Docker unterstützt, würde ich dafür möglichst das dort vorgesehene Image/Dockerfile verwenden und sie dann einfach in dasselbe hannah-Netz hängen.

Ich würde also am Ende ungefähr diese Architektur fahren:

                         ┌───────────────────┐
Satelliten ── UDP 7775 ─▶│   hannah-proxy    │
                         └───────┬───────────┘
                                 │ gRPC
                                 ▼
                         ┌───────────────────┐
                         │    hannah-core     │
                         │       :50051       │
                         └─────┬────────┬─────┘
                               │        │
                   gRPC        │        │ MQTT / ioBroker
                               │        │
              ┌────────────────┘        └───────────▶ LAN
              │
      ┌───────▼──────────┐
      │ hannah-telegram   │
      └──────────────────┘

      ┌──────────────────┐
      │ hannah-voiceid    │◀──── HTTP ─── hannah-proxy
      │      :8080        │
      └──────────────────┘

      ┌──────────────────┐
      │ hannah-webui      │
      └──────────────────┘

Diese Variante würde ich gegenüber einem riesigen Hannah-All-in-One-Dockerfile klar bevorzugen. Sie trennt Core, Proxy, Voice-ID und Telegram, ermöglicht unabhängige Neustarts/Updates und ersetzt die bisherigen systemd-Aufgaben durch Docker Compose. Die originale Hannah-Dokumentation bestätigt auch die Rollen von Core, Proxy, Telegram und Voice-ID sowie die Ports 50051, 7775/UDP und 8080. (GitHub)

Ein weiterer Vorteil: Der Core aktiviert laut Hannah-Architektur seinen eigenen UDP-Server wieder, wenn der Proxy wegfällt. Wenn du in Docker konsequent den Proxy verwendest, würde ich deshalb nur Proxy 7775/udp nach außen publishen und beim Core den Port nicht auf den Host mappen. (GitHub)

Leonie

Klar, wenn dann eh ein Image pro Komponente. Dafür ist Docker gedacht. Ich habe auch mal eben ein Image für Core gebaut: Dockerfile

Das erwartet die Sourcefiles in src/

Starten kann man es dann so:
PS D:\hannah-test\core> docker run -it --rm -v "D:\hannah-test\core\activity_audio:/app/activity_audio" -v "D:\hannah-test\core\audio_dumps:/app/audio_dumps" -v "D:\hannah-test\core\config.yaml:/etc/hannah/config.yaml:ro" --name hannah-core hannah-core:latest
15:41:50 [INFO] hannah.main: Hannah Core dev

=======================================================
First-run: admin account created
Username : admin
Password : Q0PmWjbR4AOerEjL9cfW8g
Please change the password after first login!

Analog würde ich es für die anderen Komponeten auch machen.

Walter.O.

systemctl status hannah
Unit hannah.service could not be found.

#52

Leonie

Bei deinem Install-Befehl fehlt am Ende das "| bash", nur dann wird die Datei auch ausgeführt.

for all: Ich bin gerade an einer CI-Pipeline dran die die Images baut und dann aber auf quay.io hochlädt.

Community Forum

NEWS

Hannah — Open Source Smart-Home-Sprachassistentin

Selbstbau-Platine vs. fertige ESP32-S3-Boards

Telegram-Sprachnachrichten als Übergangslösung

Mini-Web-Frontend für Text/Sprache

Docker für Core / Telegram / VoiceID

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

Selbstbau-Platine vs. fertige ESP32-S3-Boards

Telegram-Sprachnachrichten als Übergangslösung

Mini-Web-Frontend für Text/Sprache

Docker für Core / Telegram / VoiceID

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

Empfohlene Verzeichnisstruktur

1. Core

2. Proxy

3. Telegram

4. Voice-ID

5. docker-compose.yml

Ganz wichtig: interne Hostnamen

`.env`

Ein Punkt, den ich noch ändern würde

WebUI

=======================================================
First-run: admin account created
Username : admin
Password : Q0PmWjbR4AOerEjL9cfW8g
Please change the password after first login!

Support us

154

33.0k

83.7k

1.3m

Community Forum

NEWS

Hannah — Open Source Smart-Home-Sprachassistentin

Selbstbau-Platine vs. fertige ESP32-S3-Boards

Telegram-Sprachnachrichten als Übergangslösung

Mini-Web-Frontend für Text/Sprache

Docker für Core / Telegram / VoiceID

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

Selbstbau-Platine vs. fertige ESP32-S3-Boards

Telegram-Sprachnachrichten als Übergangslösung

Mini-Web-Frontend für Text/Sprache

Docker für Core / Telegram / VoiceID

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

Empfohlene Verzeichnisstruktur

1. Core

2. Proxy

3. Telegram

4. Voice-ID

5. docker-compose.yml

Ganz wichtig: interne Hostnamen

.env

Ein Punkt, den ich noch ändern würde

WebUI

======================================================= First-run: admin account created Username : admin Password : Q0PmWjbR4AOerEjL9cfW8g Please change the password after first login!

Support us

154

33.0k

83.7k

1.3m

`.env`

=======================================================
First-run: admin account created
Username : admin
Password : Q0PmWjbR4AOerEjL9cfW8g
Please change the password after first login!