Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Leonie]

Hi zusammen!

Es ist wieder Zeit für ein kleines monatliches Wrap-Up zu meiner Offline-Sprachassistentin Hannah. Im Juni habe ich unter der Haube und vor allem an der Oberfläche extrem viel getan! Wer das Projekt bisher verfolgt hat, wird wissen, dass es einige Einstellungen gab, die man mühsam in YAML-Dateien bearbeiten musste. Damit ist jetzt Schluss, denn genau dafür gibt es nun die neue WebUI.

Hier sind die wichtigsten Highlights aus dem Entwicklungszyklus der letzten Wochen:

🌟 Die neue WebUI: Tschüss YAML, hallo No-Code!

Die größte Neuerung ist mein Web-Interface. Um künftige Versionskonflikte mit dem Core-System komplett zu vermeiden und die Entwicklung sauber zu trennen, läuft die WebUI als eigenständige Standalone-Anwendung in einem separaten Repository (und ist dort direkt mit der Version 1.0.0+ gestartet).

• Flexibler Microservice: Ich habe die WebUI als echten Microservice konzipiert. Sie kann entweder auf demselben Host wie Hannah selbst laufen oder auf einem völlig anderen Server in eurem Netzwerk. Auch ein Deployment über Docker wird voll unterstützt. Ein passendes Dockerfile liegt im Repository bei, sodass ihr euch das Image ganz einfach selbst bauen könnt.
• Neues Gewand (Tailwind CSS): Das alte Bootstrap-Design fliegt nach und nach raus. Große Teile wie die Raum-, Satelliten- und Einstellungsseiten erstrahlen bereits in einem schicken, einheitlichen Dark-Theme auf Tailwind-Basis – perfekt für das Dashboard-Tablet an der Wand.
• Komfortabler Trigger-Editor: Im Trigger-Editor müsst ihr die Wochentage für Uhrzeit-Bedingungen nicht mehr mühsam als Text (durch Kommas getrennt) eintippen. Das lässt sich jetzt ganz entspannt über eine saubere Checkbox-Auswahl zusammenklicken.
• Ausblick – Responsive Design: Damit das Interface auch auf dem Smartphone knackig aussieht, habe ich bereits eine Responsive-Design-Initiative für das Projekt gestartet. Eine echte Optimierung für mobile Endgeräte steht also als Nächstes auf meinem Zettel!

Hier geht es direkt zum neuen Repository:
🔗 WebUI-Repository

🧠 Core-Updates & Stabilisierung

Auch im Core (aktuell bei Version 0.48.1) habe ich massive Fortschritte bei der Strukturierung der Datenmodelle gemacht:

• Lösen von der strikten ioBroker Integration zur Unterstützung einer stärkeren Bindung und Stabilität: Unter der Haube habe ich die BLE-Indoor-Lokalisierung und die Benutzerverwaltung unabhängiger auf eigene Beine gestellt. Statt starr auf asynchrone Snapshots des Adapters zu warten, lädt Hannah Nutzerdaten nun direkt synchron aus einer lokalen SQLite-Datenbank. Das verhindert Race-Conditions nach Server-Neustarts komplett. Keine Sorge: Sobald der ioBroker-Adapter connected, pusht Hannah den aktuellen Anwesenheitsstatus ("Wer ist zuhause") sofort sauber rüber!
• Routinen & Trigger im No-Code-Editor: Über die neue Oberfläche lassen sich Routinen und komplexe Trigger-Bedingungen (Wenn-Und-Außer-Wenn-Dann) völlig ohne Programmieraufwand direkt in der UI zusammenklicken.
• Personalisierte Satelliten: Satelliten lassen sich jetzt nicht mehr nur festen Räumen zuweisen, sondern können im System direkt einer konkreten "Person" (Besitzer) zugeordnet werden. Das legt den Grundstein für zukünftige, personalisierte Ansagen, die genau da landen, wo sich der jeweilige Nutzer aufhält.
• Dynamische Satelliten-Verwaltung: Über das Web-Interface kann ich Satelliten nun endlich vollständig administrieren und bei Bedarf über einen neuen "Löschen"-Button inklusive gRPC-Event-Verteilung direkt sauber aus der DB und dem ioBroker-Objektbaum entfernen. Leichen im System gehören damit der Vergangenheit an.

🔌 ioBroker-Adapter & Hardware-Verbindung

• ioBroker-Adapter: Natürlich wurde der Adapter nicht vergessen und hat in der Zeit ebenso eine Menge Updates erhalten. So kann man nun neue Satelliten direkt über den ioBroker-Admin flashen, die Objektdatenbank wurde bereinigt und dutzende Bugs wurden durch Stabilitätsupdates gefixt.

🔊 Performance-Schub für Ankündigungen (Proxy-Fix)

Wer mehrere Satelliten im Einsatz hat, kennt das vielleicht: Bisher liefen Audio-Ankündigungen (Announcements) an mehrere Geräte sequentiell ab. Wenn ein Satellit noch streamte, blockierte das die restlichen Geräte.

Das habe ich komplett überarbeitet: Ein neuer paralleler Dispatcher verteilt die Audio-Chunks nun pro Geräte-ID auf eigene Worker-Goroutinen. Die Ausgabe auf verschiedenen Satelliten erfolgt ab sofort absolut gleichzeitig und parallel, ohne dass sich die Geräte gegenseitig ausbremsen.

---

Das war es auch schon für diesen Monat von meiner Seite! Die Entkopplung der WebUI macht den Weg frei für ein noch modulareres Setup.

Wie sieht's bei euch aus? Habt ihr Wünsche für den No-Code-Trigger-Editor, die generelle WebUI oder das ganze Projekt? Lasst es mich in den Kommentaren wissen!

Egal ob hier im Forum über diesen Thread, per privater Nachricht oder direkt auf GitHub – ich bin hör-bereit.

Das waren nun in diesem Monat ganze 84 Releases, in meinen Augen spricht das für ein lebendes Projekt.

Viele Grüße,
Leonie

[michael.langer]

Moment bin ich am umziehen meines proxmox Server und hab jetzt dan ordentlich Leistung zu Verfügung.
Eigentlich war mein Plan die sprachsteuerung von homeassistant zu testen, aber ehrlich gesagt hört sich das ganze besser an.

Ich werd das ganze so schnell wie es geht mal testen.

Für ein dauerhaftes Produktives einsetzen in der Zukunft, hätte ich nur etwas bedenken wo das Projekt so hin geht.

Gibt es da schon Pläne?

Gruß Michael

[Leonie]

Hey,
Was meinst du mit "wo es hin geht"?

Von meiner Seite aus gibt es aktuell keine Pläne das Projekt einzustellen, täglich arbeite ich daran, füge neue Dinge hinzu, löse Fehler oder entferne Dinge die nicht mehr gebraucht werden.

Bisher ist es eine "One-Woman-Show", um aber genau das abzusichern und der Community die Möglichkeit zu geben, das Projekt weiter zu führen, wenn ich mal nicht mehr kann, keine Lust mehr habe oder anderweitig verhindert bin, gibt es die Version auf Github. Die ist tatsächlich Bit-Aktuell mit meiner eigenen Version. In dem Github-Repo von Hannah fehlt nichts was für den Betrieb oder die Entwicklung notwendig ist.
Auch die anderen Komponenten, wie bspw. die verwendeten gRPC-Protofiles und die in der Firmware verwendete AudioLib, liegt auf Github, und beide liegen auch auf entsprechenden Paketrepositories, die Protofiles sogar auf pypi, npmjs und github.
Bei bedarf kann man also die Rohdaten dieser Komponenten lesen, verändern und nutzen. Wäre nur nett, die Veränderungen an den Files auch mir wieder zu geben, damit sie den Weg in die von mir gewartete Version finden.
Der ioBroker-Adapter liegt sowieso auf GitHub und ist primär OpenSource. Eine Beantragung in das latest-Repo wurde gestellt, wurde noch nicht angenommen. In der Zeit in der ich gezwungen bin zu warten, programmiere ich einfach weiter.

Ich kann dir/euch auch einen kleinen Ausblick geben, offen ist bei mir aktuell unter anderem:

• Ein Skill-System (Alexa-artig), damit neue Fähigkeiten nachrüstbar werden, ohne den Core anzufassen
• Kameraerkennung an der Haustür, Music-Assistant-Anbindung, ein Teams-Bot als Android-Auto-Brücke
• Proaktives Verhalten + ein Stimmungs-/Beziehungs-System, damit Hannah nicht nur reagiert, sondern auch einen eigenen "Charakter" gegenüber verschiedenen Leuten hat
• Eine Android-App als virtueller Satellit, eine abgespeckte Satelliten-Variante nur mit Sensoren (ohne Mikro/Lautsprecher), Magic-Mirror-Anbindung
• Absicherung der internen Schnittstellen und eine zentrale Verwaltung, falls man mehrere Geräte/Installationen betreibt
• Mehrsprachigkeit — aktuell ist alles hart auf Deutsch ausgelegt

Und das ist wirklich nur ein Ausschnitt, es steht noch einiges mehr auf der Liste. Das Projekt ist aktiv in Bewegung, kein abgeschlossenes Ding, das nur noch gepflegt wird.

[Leonie]

Hallo zusammen,

ich habe die Install-Routinen für Hannah kurzfristig wieder fit gemacht und bei der Gelegenheit direkt ein bisschen aufpoliert.

Die Installation der einzelnen Komponenten läuft ab sofort super simpel über einen einzigen Befehl. Für das Core-Modul sieht das beispielhaft so aus:

curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash

Das Ganze funktioniert für die anderen Komponenten ganz analog (einfach den Pfad im Befehl entsprechend anpassen). Das Skript zieht sich dann jeweils das aktuellste Release von meinem Update-Server und wirft es direkt auf eure Maschine. Analog gilt das auch für die WebUI, wobei man die auch per Docker betreiben kann.

Ein kleiner, aber wichtiger Disclaimer dazu: Für den Update-Server kann ich natürlich keine garantierte SLA bieten – das Ganze läuft auf reiner Best-Effort-Basis. Die Images dort werden direkt von meiner CI gefüttert.

Falls ihr Fragen zum Deployment oder zu Hannah allgemein habt: immer her damit!

Ansonsten wurden bisher einige Bugs gefixt und die Trigger-Engine wurde grundlegend überarbeitet.

Viele Grüße
Leonie

[jerzimeik]

@Leonie sagte:

Hallo zusammen,

ich habe die Install-Routinen für Hannah kurzfristig wieder fit gemacht und bei der Gelegenheit direkt ein bisschen aufpoliert.

Die Installation der einzelnen Komponenten läuft ab sofort super simpel über einen einzigen Befehl. Für das Core-Modul sieht das beispielhaft so aus:

curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash

Hallo,
für mich als "Dummy" nur kurz:

Ich habe einen Proxmox-Server laufen. Auf dem kann ich einen Debian- oder Ubuntu-Container laufen lassen und den Befehl oben zur Installation nutzen?

Für die Satelliten überlege ich mir dann noch, ob Raspberry oder ESP 😉

VG, Meik

[Leonie]

Hi,

Im Grunde ja. Es wird ein Linux-Betriebssystem benötigt, ob das nun Bare Metal. virtuell oder sonst wo ist, spielt da keine Rolle. Einfach den Befehl den ich gepostet habe ausführen, bzw. andere anderen, gewünschten Komponente anpassen.

Zu den Satelliten: Es ist so, das ich die Pip-Satelliten gar nicht mehr supporte. Der Code für die wurde vor einigen Monaten "eingefroren" (naja, eher nicht mehr weiterverfolgt) und ist seit dem unverändert. Der ist nur noch im Repository vorhanden, weil ich noch keine Lust hatte den zu entfernen. Der dürfte mit der aktuellen Core-Version auch nicht mehr lauffähig sein, dafür hat sich in der Zeit zu viel in der Kommunikation geändert.
Seit ein paar Monaten verfolge ich nur noch die ESP-Entwicklung, die befindet sich auf dem aktuellen Stand.

Viele Grüße
Leonie

[PackElend]

Blöde frage von der einem gelegentlich Leser, was ist der Unterschied zwischen Satelliten und eap? Es geht doch in beiden Fällen um abgesetzte Mikrofon, Lautsprecher?

[Leonie]

Ich nehme an, du meinst den Vergleich zwischen einem ESP und einem Raspberry Pi als Satellit?

Das Wort Satellit beschreibt erst einmal nur die Rolle bzw. Kategorie des Geräts: Es ist eine abgesetzte Hardware-Einheit im Raum, die Audiosignale (Mikrofon) aufnimmt, an den Server schickt und Antworten (Lautsprecher) wiedergibt. Ein Satellit braucht also Mikrofone, Lautsprecher, einen Audio-Verstärker und einen Prozessor, der die Logik steuert.

Der Unterschied liegt in der Hardware-Basis:

Ein Raspberry Pi ist ein vollwertiger Single-Board-Computer (SBC).
Ein ESP (wie der ESP32) ist ein Mikrocontroller (MCU) bzw. ein Embedded System.

Auch wenn beide am Ende Software ausführen, unterscheiden sie sich fundamental im Aufbau und in der Funktionsweise:

1. Betriebssystem vs. Bare-Metal

• Raspberry Pi: Nutzt eine klassische 3-Schicht-Architektur (Hardware -> Betriebssystem (Linux/Debian) -> Software). Dadurch hast du ein vollwertiges System mit SSH, Dateisystem, Multi-User-Verwaltung und freier Auswahl bei den Programmiersprachen (Python, Node.js, Go usw.).
• ESP32: Läuft im Grunde auf 2 Schichten (Hardware -> Software/Firmware). Es gibt kein klassisches Betriebssystem. Stattdessen läuft der Code direkt auf der Hardware („Bare-Metal“), meist unterstützt durch ein schlankes Echtzeit-Betriebssystem wie FreeRTOS. Programmiert wird das in der Regel in C oder C++.

2. Ressourcen & Effizienz

Ein Raspberry Pi ist dafür gebaut, möglichst universell einsetzbar zu sein. Ein ESP ist extrem spezialisiert: Er tut genau eine Sache, diese dafür aber sofort nach dem Einschalten, hocheffizient und ohne Bootzeit.

• Stromverbrauch & Abwärme: Ein Raspberry Pi 5 braucht unter Last gerne mal ein 3-A-Netzteil (15 Watt) und eine aktive Kühlung. Ein ESP-Satellit begnügt sich mit maximal ~0,8 A (unter 4 Watt), wird nicht einmal spürbar warm und ist nach dem Anstecken in Bruchteilen einer Sekunde betriebsbereit.

3. Kosten & Fertigung (Pi vs. ESP Custom-PCB)

Auch finanziell und im Aufwand unterscheiden sich die Ansätze gewaltig:

• Raspberry Pi: Ein Pi selbst kostet selten unter 70 €. Zusammen mit Mikrofonen, Lautsprechern, Gehäuse und Netzteil landet man schnell bei über 100 € pro Satellit – und muss am Ende trotzdem noch mehrere Einzelkomponenten zusammenstöpseln.
• ESP Custom-PCB: Ein reiner ESP kostet gerade mal ~4 $. Da die Hardware aber auf einer maßgeschneiderten Platine sitzt, schlagen hier aktuell natürlich die allgemeinen Bauteilpreise und die Bestückung im Werk zu. Wenn ich mir bei JLCPCB eine Kleinserie von 5 Platinen inklusive industrieller SMT-Bestückung (PCBA) fertigen und löten lasse, liege ich bei ca. 300 € Gesamtkosten – also rund 60 € pro betriebsbereitem Satellit.
• Skalierung & Flexibilität: Wie gewohnt in der PCB-Fertigung sinkt der Stückpreis mit steigender Abnahmemenge natürlich drastisch, da Fixkosten wie Rüstgebühren dann nicht mehr so stark ins Gewicht fallen. Die BOM (Bill of Materials) ist öffentlich einsehbar und universell – ihr könnt euch also die Bauteilliste schnappen und jederzeit beim Bestücker oder Händler eures Vertrauens eigene Angebote einholen. Wer in der Lage ist, SMT-Bauteile komplett selbst zu löten, drückt den reinen Platinenpreis bei der Fabrik sogar auf ca. 5 € pro Stück (zzgl. Bauteile).

Im Ergebnis habe ich bei der ESP-Variante selbst bei einer Mini-Auflage für ~60 € eine fertige, professionell bestückte All-in-One-Platine auf dem Tisch, während man beim Pi für deutlich mehr Geld ein Sammelsurium an Einzelteilen zusammenbaut.

---

Fazit & Status bei Hannah:
Die Einstiegshürde bei einer eigenen ESP-Platine ist für Anwender natürlich höher als beim Zusammenstecken von Fertigmodulen. Ich überlege derzeit auch noch, wie ich euch mein PCB-Design am besten zur Verfügung stellen kann (JLCPCB bietet leider keine Shared Projects an, weshalb ich dafür aktuell PCBWay evaluiere).

Dennoch habe ich die Pi-Satelliten komplett abgekündigt. Der Pi ist für diesen Einsatzzweck im Grunde eine völlig überdimensionierte Hardware. Der alte Code für die Pi-Satelliten wird seit Monaten nicht mehr gepflegt und ist mit dem aktuellen Core auch gar nicht mehr kompatibel.

Ich setze für Hannah daher heute ausschließlich auf die ESP-Plattform – das ist die schlanke, maßgeschneiderte Embedded-Hardware, die exakt für diesen Job gebaut ist.

[zahnheinrich]

Dann könntest du deinen Eingangspost entsprechend abändern.

[Leonie]

Ich habe den Eingangspost angepasst.

[WolfgangD]

Na dann: Wo kann ich mich auf die Bestelliste für ESP-Satelliten setzen lassen?

[PackElend]

Andere Frage, ist das System erweiterbar mit anderen Sprachen (nicht sprachmodellen). Unser Haushalt ist mehrsprachig, und ich bin mit Deutsch eigentlich in der Minderheit

[Leonie]

@WolfgangD sagte:

Na dann: Wo kann ich mich auf die Bestelliste für ESP-Satelliten setzen lassen?

ich melde mich per PN bei dir.

@PackElend sagte:

Andere Frage, ist das System erweiterbar mit anderen Sprachen (nicht sprachmodellen). Unser Haushalt ist mehrsprachig, und ich bin mit Deutsch eigentlich in der Minderheit

Aktuell nicht, es steht aber auf meiner Roadmap. Ich zitiere aus dem Issue:

The current NLU and all response text generation are hardcoded German, spread across nlu.py and iobroker.py. Language-specific logic includes:


        
      nlu.py: room name matching, umlaut normalization, device aliases, intent keywords

        
      iobroker.py: _UMLAUT_MAP, _normalize_umlauts, _camel_to_words (device key normalization), _CATEGORY_LABELS / _category_label(), hardcoded "de" language code for room_names lookup, and all of answer_query() + _summarize() + _answer_global() + _describe_category() + _MODE_LABELS

The goal is a LanguagePack interface that bundles both concerns, so:


        
      German stays the only maintained implementation

        
      A contributor can build an English (or any other) pack without touching core logic

        
      Per-room language binding becomes possible in config

Eventuell mache ich englisch auch selbst, muss ich mal schauen.

[micklafisch]

ich verfolge den Thread aufmerksam. Gibt es bereits Fotos der Satelliten?

Da ich softwareseitig mit meinen Echo dots nicht zufrieden bin (Hardware und Klang ist i.O., nur die "Intelligenz" ist mehr als fragwürdig. Mein insgeheimer Plan wäre die Amazon Hardware wie Mikrofone, Lautsprecher und Gehäuse zu verwenden und nur den ESP einzusetzen, allerdings hab ich bislang die Kiste noch nicht geöffnet und weiß nicht was mich da erwartet.

[PackElend]

@Leonie sagte:

englisch

Bei uns ist die Haussprache (ausser mir) französisch, ist dann wohl irgendwie machbar.

Eine Frage dazu noch, können Sprachen parallel laufen, sprich wird die Sprache erkannt oder müsste ich mit unterschiedlichen Signalwörter, andere Namen, arbeiten.
Beispiel
de Hannah
En Elizabeth
Fr Pauline

[Leonie]

@micklafisch Hier ein Bild von dem PCB aus der Planung

Es handelt sich um eine 4 Layer Platine, beidseitig bestückt. Orientiert habe ich mich an zwei Systemen: Alexa und Satellite 1. Weil ich vor allem aber die Alexa-Platinen nicht nachbauen kann und auch in der exakten Größe Probleme habe, ist meine etwas größer: Durchmesser 88mm.

Hier noch ein Bild von dem fertigen Gehäuse:

Die Buttons oben sind Vol+, Vol-, Mute und PTT, auch der LED-Diffusor ist gut zu sehen.

@packelend Geplant ist es, irgendwie. Das wird aber wohl eher mit einer Personenzuordnung laufen. Das also jeder "Hannah-User" ein Language-Setting bekommt. Jeder Nutzer muss dann einmal über VoiceID seine Stimme bekannt geben. Wird dann in der normalen Nutzung ein Nutzer erkannt, wird auf die passende Sprach-NLU gewechselt. Im Fallback wäre es ein globaler, das könnte bei dir dann bspw. französich sein.

[PackElend]

@Leonie sagte:

Wird dann in der normalen Nutzung ein Nutzer erkannt, wird auf die passende Sprach-NLU gewechselt.

Bei unserem Sohn wird das spannend, er spricht deutsch, französisch und Züritüütsch😁

[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.