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

[Samson71]

@Int17
Du musst auch noch eine Instanz dazu anlegen/installieren. Oben rechts die 3 Punkte und dann auf das +

[Leonie]

Hi,
Du musst auch eine Instanz hinzufügen, das passiert bei der Installation über Github nicht automatisch.

Die Raspberry Pi Sats sind im Grunde ganz normale Raspberry Pi 3b mit Debian Trixie. Wahlweise mit USB-Mikrofon und Klinken-Lautsprecher oder mit spezialisierter Hardware wie den Seeed Respeaker (2) HATs. Der Pi-Satellit ist ein einges Pythonscript das quasi überall und mit allem läuft, getestet aber nur mit dem was ich beschrieben habe.

Mein ESP-Aufbau ist schon recht weit und aktuell passiert viel an der Firmware-Entwicklung. Der PoC-Stand ist erfolgreich abgeschlossen und die Software funktioniert, da finden aktuell noch ein paar Feature-erweiterungen statt. Auch meine eigene Platine mit ESP, Peripherie und Sensoren ist bereits fertig geplant und befindet sich derzeit in Produktion. Wenn ich die habe, kann ich testen ob mein Plan funktioniert oder ob ich eine Menge Geld in den Sand gesetzt habe :D
Die Schaltpläne für die Platine ist allerdings nicht OpenSource.

Liebe Grüße
Leonie

[Leonie]

Status zum ESP:

May 09 17:24:49 psrvhva01 hannah-proxy[21119]: 2026/05/09 17:24:49 INFO audio session complete device=wohnzimmer-esp bytes=203200
May 09 17:24:49 psrvhva01 hannah-proxy[21119]: 2026/05/09 17:24:49 INFO speaker identified device=wohnzimmer-esp roomie_id=leonie
May 09 17:24:52 psrvhva01 hannah-proxy[21119]: 2026/05/09 17:24:52 INFO pipeline result device=wohnzimmer-esp transcript="Schlafzimmer, Licht aus." intent=TurnOff answer="OK, 6 Gerät(e) geschaltet." tts_bytes=123600 speaker=leonie
May 09 17:24:52 psrvhva01 hannah-proxy[21119]: 2026/05/09 17:24:52 INFO TTS sent device=wohnzimmer-esp bytes=123600 sample_rate=16000

[Leonie]

Hii,

Ich gebe dann mal wieder ein Update.

Hannah selbst hat im letzten Monat einige Updates bekommen, die Integration in den ioBroker wurde verbessert, ebenso kamen neue Features dazu. Die ESP-Firmware ist quasi fertig. Diese hat mittlerweile einige Versionen bekommen, so kann sie bspw. mit Sensoren wie dem BMP280 und AHT20 (oder nur einem davon) betrieben werden, oder auch mit einem BME680. Die Wakeworderkennung ist abgeschlossen, es wurde Support eingebaut um Audio-Samples für das Wakewordtraining über die Mikrofone des ESPs aufzunehmen um auf diese Weise authentische Trainingsdaten zu bekommen.
Die ESP-Firmware hat darüber hinaus eine OTA-Komponente erhalten und kann sich somit selbstständig updaten. Vor einem Update fragt der ESP aktiv bei Hannah nach einem "ok", erst wenn Hannah den Request bestätigt, führt der ESP das Update aus. Dies ist notwendig, damit der Satellit nicht bspw. mitten im Gespräch neustartet.
Auch für alle weiteren Hannah-Komponenten gibt es einen Update Service, dieser nennt sich dort AutoDeploy. AutoDeploy bedient sich an der selben OTA-Infrastuktur wie die ESP-Firmware, lädt die neuen Komponenten-Files runter und startet die betroffenen Services neu.
Das läuft über einen eigenen Microservice den ich Hannah Update Server genannt habe. Bei Bedarf kann ich dessen API gerne offen legen. Das gleiche gilt für eine weitere neue Komponente: Den Assetserver. Dieser stellt bspw. Jingles und/oder einfache Töne bereit, die dann von Hannah oder den Satelliten abgespielt werden können. Auch dessen API kann ich bei Bedarf offen legen.

Zu der ESP-Firmware: Größtenteils halte ich die mittlerweile für abgeschlossen. Sicher kommen da zukünftig noch weitere Features oder Bugfixe rein, aber aktuell ist diese für mich vollständig und komplett konfigurierbar.

Außerdem hat die ESP-Firmware mittlerweile auch ein WiFi-Provsioning. Nach dem Flashen oder wenn man den "geheimen" Reset-Knopf gefunden hat, öffnet der ESP einen AccessPoint und gibt sich selbst die IP-Adresse 192.168.4.1. Über diese Adresse kann man ihn dann konfigurieren und bspw. die WiFi-Credentials eintragen. Seine WebUI ist auch im normalen Betrieb verfügbar. Dort lässt sich bspw. das Wakeword an- und ausschalten, der Name oder die Raumzuordnung ändern.
Quasi nebenbei hat Hannah über die Satelliten auch einen BLE-Tracker bekommen, sie kann nun also BLE-Devices im Haus "orten".

Selbstverständlich werden alle Satellitendaten in den ioBroker gebracht.

Weiterhin wurde die Integration in ein LLM verbessert. Wird nun ein LLM verwendet, das Tools unterstützt, werden mehrere Tools an das LLM übergeben. So kann auch im Smalltalk-Modus der ioBroker gesteuert werden und das LLM arbeitet an manchen Stellen besser/exakter als die regelbasierte NLU. So hat als Beispiel Whipser den Satz "Fritteuse an" als "Fritus a" transkribiert, worauf die regelbasierte NLU keinen Match hatte und das folgerichtig als Smalltalk in das LLM geleitet hat. Das LLM hat dann korrekt "Fritteuse an" verstanden/geschlossen und tat genau das.

Außerdem gibt es in ioBroker gleich drei States, die in etwa den gleichen Zweck haben, aber anders sind:

announcement

Diese Texte gehen direkt ans TTS und werden über die Satelliten ausgespielt

announcementSsml

Quasi das gleiche wie das vorherige, aber mit SSML-Support

announcementRephrase

Diese Texte gehen einen kleinen "Umweg" über das LLM mit der Ansage: Formuliere das in deinen Worten neu und flechte deine Persönlichkeit ein. So kommt in relativ starre Texte die man in ioBroker bspw. über Javascript generiert ein wenig Variation.

Von meinem eigenen PCB befindet sich gerade Revision 4 auf dem Weg zu mir. Revision 1 wurde nie gebaut und die Revsion 2 und 3 haben dumme Fehler, die nie hätten passieren dürfen :D

Alles zusammen, also ein sehr produktiver Monat, nach meiner Git-History hat Hannah in dieser Zeit 56 Releases gehabt.

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